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