Just in this minute i'm trying to start Plan9 in VMWare :D
2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > 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 <[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 > >>>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
