2008/2/3, Filipp Andronov <[EMAIL PROTECTED]>:
> 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
> > >>>>
> > >>
> > >>
> >
> >
>
