[Mesa-dev] Old toys [DRI1 drivers] .....

[Alex Deucher]

On Sat, Sep 25, 2010 at 11:48 AM,  <randrianasulu at gmail.com> wrote:
>
>
> Ok, it seems very few people want to have them in working state from
> developers side of fence. Corbin simply can't boot them, others are busy with
> new radeon/nouveau/intel.
>
> So, first  I will list drivers, as far as i understand them, please correct:
>
> i810 - Old Intel, 16-bit only rendering, IIRC.
> mach64 - used in  at least some notebooks, so hard to upgrade. Has little VRAM
> (4-8mb often), but due to this can benefit from private backbuffers in DRI2.
> mga - G200-G450 (?) , has some unique features, like dropping depth
> renderbuffer into AGP space.
> r128 - as everyone know, can be folded into radeon .....
> savage - again, notebook owners still forced to use them.
> sis - only small part of SiS video family supported, I remeber kernel part is
> not fun even as-is.
> tdfx - usually tied to glide.
> unichrome/openchrome - i hope this one will have active devs?
>
> Well, most of drivers listed were written with common template during
> Mesa-4.0-5.0 era, because of this and because they will need total rewrite
> for KMS anyway ... I think i have idea.
>
> Can freedesktop/X.org organise something like Google summer (winter?) of Code,
> with some tasks, need for moving those drivers forward? Good documentation
> about _today_ mesa's internals and interfaces  hopefully will speed up
> process?
>
> Hint: Intel, as  BIG corp, can organise something for i810 :}
>
> Sometimes, i thin gfx/3D programming world is like Unix for windows users,
> friendly but only for some (few).
>
> But, main idea here ... this is NOT neccesary to make it harder for people who
> want (and can) enter. Most devs played with old, fixed-function chipsets
> 10-15 years ago, so now they simply not interested in making same steps
> again.
>
> But i think other people may want  to start from something simple, too. Not
> from latest 200W air heater from ATI/NVIDIA.
>
> And .... as  the last word. I think (bad habit, yes) what  simply removing
> something is not equal to creating even simple driver ... rm is always
> simpler than edit, but "easy ways" lead to easy fails in the future.
>
> There is not so much X/3D  (low-level) programmers, but i fear hw/sw
> complexity is only PART of reason .... Core devs haven't time for teaching
> students (and newcomers in general), but should i note - we all are not
> endless?

Part of the problem is that most of this hardware is ~12-15 years old.
 There's little interest in either the developer or user community to
keep developing drivers for it.  While I'll agree that the older,
simpler hardware may be a bit easier to new developers to start
looking at, the problem in this case is that I'm not sure these
drivers even work any more.  We keep them compiling, but I really
doubt anyone has tested them in ages.  So for someone getting into
driver development, the simplicity of older hardware is easily
out-weighed by the broken state of the old drivers.  It's hard to
start playing with the driver if it doesn't even work.  The other
thing is that most of this does not support the bare minimum of useful
features for basic modern 3D use cases (I'm not talking advanced games
here -- basic stuff like multi-texture and rectangular textures).

In a certain sense, the hardware and driver has gotten simpler.
Rather than having to deal with lots of strange interfaces for
uploading transform matrices and setting the right state bits to
enable their use, we now have shaders which are not only more
powerful, but also easier to understand.  It's easier to look at a
little program that you can read and understand rather than a complex
set of state, upload interfaces, and data munging.

Alex

> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>