> 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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]>: > >> 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 <[EMAIL PROTECTED]>: > >>>> 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 <[EMAIL PROTECTED]>: > >>>>>> On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> > >>>>>> 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 > >>>>>> > >>>> > >>>> > >> > >> > >
