Okay, that's fine. What I'm saying is that you don't have to write
something from scratch to get something else working. If you actually
do get one of the other OpenGL implementations to work, then porting
Gallium3D is a lot easier.

Either way, you won't need direct hardware manipulation on Plan 9.
Just run it from a virtual machine and see where you go from there.

On Feb 3, 2008, at 11:33 AM, Filipp Andronov wrote:

>> There were many attempts to port OpenGL to Plan 9, none of which I
>> got to work. I started working on a ground-up 3D library but lost it
>> to a faulty Plan 9 partition.

> I have no plan to start serious works about OpenGL porting. I just
> want to play with Plan9, if i port Gallium3D if will be great success.
>
> Actually i have no working Plan9 yet (!), so i just looking around,
> reading documentation and asking about some questions that i have in
> my mind
>
> So my plans is not something serious, i just looking for somethings
> for fun
>
> 2008/2/3, Pietro Gagliardi :
>> There were many attempts to port OpenGL to Plan 9, none of which I
>> got to work. I started working on a ground-up 3D library but lost it
>> to a faulty Plan 9 partition.
>>
>> On Feb 3, 2008, at 10:56 AM, Filipp Andronov wrote:
>>
>>> Some graphics chip, actually i want port OpenGL to Plan9, but DRI
>>> has
>>> ugly architecture and Mesa with X11 are overload by unnecessary
>>> code,
>>> as far as i know it is because of historical reasons.
>>>
>>> I have experience with X11 and OpenGL specifications and device
>>> driver
>>> development, so my plan was port general parts of mesa (not all of
>>> course), but with out DRI on Intel graphics chip (i have that card)
>>> with hardware acceleration.
>>> When i start dig problem i have found DRI replacement known as
>>> Gallium3D, it is completely new project (from Mesa community as
>>> far as
>>> i know) and it small enough for try to port it. Intel chips has very
>>> good documentation and linux driver what i know very well. So plan
>>> was:
>>> 1. Port Gallium3D, pieces by piece
>>> 2. Port some features from Linux Intel driver to Plan9 if necessary
>>> 3. Try to port some pieces Mesa
>>>
>>> Of course it is a very big work, and i know that, but it is
>>> interesting enough to be fun. I have no target to create completely
>>> OpenGL implementation or port of Mesa, i just want to play with
>>> Plan9
>>> kernel, Mesa and Intel card )
>>>
>>> 2008/2/3, Pietro Gagliardi :
>>>> Out of curiosity, what hardware do you need to get working?
>>>>
>>>> On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote:
>>>>
>>>>> I'm not sure that "project fork" is a best way. Because hardware
>>>>> problem is a little piece of work and it's lays it separate
>>>>> module.
>>>>> The biggest part of application is a some computations and some
>>>>> algorithms implementation...As far, as application was port in
>>>>> many
>>>>> different Linux platforms, it's almost impossible to find some
>>>>> function with out #ifdef )
>>>>>
>>>>> Ok, any way, it looks like "project fork" is simplest way to do
>>>>> port,
>>>>> so any other ways is not very interesting. I think that this
>>>>> way is
>>>>> most correct, because in that case i could redesign many parts of
>>>>> this
>>>>> application in "plan9 style", do some soft services like, files
>>>>> for
>>>>> example
>>>>>
>>>>> Thanks to all for your help
>>>>>
>>>>> 2008/2/3, Pietro Gagliardi :
>>>>>> You need to do direct hardware manipulation? Then "project
>>>>>> fork" is
>>>>>> probably best.
>>>>>>
>>>>>> On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote:
>>>>>>
>>>>>>> Heh, i try to "port" my program, and it's really not possible
>>>>>>> in my
>>>>>>> point of view
>>>>>>>
>>>>>>> Actually, i don't have working Plan9 right now, reason is quite
>>>>>>> simple, on my hardware plan9 does do not work (PC emulators
>>>>>>> couldn't
>>>>>>> help because my program should work with some special hardware),
>>>>>>> so i
>>>>>>> try to create PC from "supported hardware" list, but it take
>>>>>>> some
>>>>>>> time to get all pieces, put they together, install, configure
>>>>>>> plan9
>>>>>>> and so on ))
>>>>>>> Ok, i have no Plan9, but i have my application that i want to
>>>>>>> port,
>>>>>>> so i try to remove all autotools macros from it and try to do
>>>>>>> some
>>>>>>> preparations, like new abstraction layer for threads
>>>>>>> creation...and
>>>>>>> i'm completely failed, just because too much autotools stuff in
>>>>>>> sources. And it too complicated to figure out what exactly i
>>>>>>> should
>>>>>>> remove in every case...
>>>>>>> And my application much smaller that mesa for example. Or X11
>>>>>>> (by
>>>>>>> the
>>>>>>> way, how X11 was ported?), and i do not tou¨„h such problems
>>>>>>> like
>>>>>>> different library, kernel interfaces and so, and so...
>>>>>>>
>>>>>>> So it looks like "project fork" is only way
>>>>>>>
>>>>>>> 2008/2/3, Pawe©© Lasek :
>>>>>>>> On Feb 3, 2008 2:55 AM, Pietro Gagliardi
>>>>>>>> wrote:
>>>>>>>>> Circular cause and consequence is funny. Let me add to this
>>>>>>>>> list:
>>>>>>>>> - jpg
>>>>>>>>> - png
>>>>>>>>> - tiff
>>>>>>>>> - PostScript
>>>>>>>>> - TeX (tpic)
>>>>>>>>> - HTML
>>>>>>>>> - Mahjongg, sokoban, sudoku, tetris (games/4s)
>>>>>>>>> - SPARC, MIPS, x64
>>>>>>>>> - MP3, PCM, OGG (PAC was made at Bell Labs)
>>>>>>>>> - SoundBlaster 16
>>>>>>>>>
>>>>>>>>> Let me put it this way:
>>>>>>>>> GNU software is good, except for GNU development
>>>>>>>>> tools,
>>>>>>>>> which,
>>>>>>>>> except for the gcc program itself, are mediocre and break
>>>>>>>>> compatibility (try using a Bell Labs makefile with GNU make).
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'd add to it the fact that autotools source files are hard to
>>>>>>>> make, so
>>>>>>>> many people who are to lazy to do it properly just put the
>>>>>>>> famous
>>>>>>>> (in)sanity check and checks for libs they use. The effect?
>>>>>>>>
>>>>>>>> A simple C program that doesn't rely on anything except for
>>>>>>>> example libpng
>>>>>>>> will check for C, C++, FORTRAN 77 compilers, check if those are
>>>>>>>> from
>>>>>>>> GCC and various other things.
>>>>>>>>
>>>>>>>> Imagine my surprise when I had seen a configure script (for
>>>>>>>> EmacsLisp
>>>>>>>> utility) that only checked for Emacs version
>>>>>>>> and few EmacsLisp files it used - a rare thing IMHO, when
>>>>>>>> >80% of
>>>>>>>> configure running time is for checking for not used
>>>>>>>> software.
>>>>>>>>
>>>>>>>> "CPU cycles are cheap, programmer time is expensive" <--- This
>>>>>>>> doesn't
>>>>>>>> mean that total laziness is appropriate.
>>>>>>>>
>>>>>>>> The best thing about autotools is I think the scheme of running
>>>>>>>> configure - AFAIK mplayer doesn't even use configure for it's
>>>>>>>> script,
>>>>>>>> instead
>>>>>>>> they use their own, which looks the same to end user. And saves
>>>>>>>> a lot
>>>>>>>> of time :-)
>>>>>>>>
>>>>>>>> --
>>>>>>>> Paul Lasek
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>

>>
>>