A Glide State Tracker For Gallium3D Is Talked About

[phoronix]

Phoronix: A Glide State Tracker For Gallium3D Is Talked About

A student developer has written to the Mesa3D development mailing list about creating a Gallium3D state tracker for the Glide API. Yes, the 3Dfx that hasn't been used in more than a decade...

http://www.phoronix.com/vr.php?view=OTE1Mg

[Plombo]

What a waste of an article. Brian Paul already replied to point out that the fixed-function Glide API doesn't map well at all to the shader-based Gallium. The discussion is pretty much over by now.

[89c51]

Apart from Glide worth being implemented or not (probably the later) mesa devs could make a list of small "easy" projects (if there is such a thing in graphic development) for people looking in to getting involved in mesa/G3D/state trackers/etc.

[Shining Arcanine]

What a waste of an article. Brian Paul already replied to point out that the fixed-function Glide API doesn't map well at all to the shader-based Gallium. The discussion is pretty much over by now.

I agree. This is not news.

[cb88]

So how exactly do gallium drivers support older opengl versions?... in any case a gallium based driver would be better than an opengl wrapper.

[bridgman]

So how exactly do gallium drivers support older opengl versions?... in any case a gallium based driver would be better than an opengl wrapper.

Strictly speaking there is no problem implementing a fixed-function API in a Gallium3D-based state tracker as long as the API can be translated into shader-based draw operations (which is probably the case for Glide) - the problem is more with running on fixed-function *hardware*.

I don't remember if the proposal was to run Glide on new HW (which should be OK) or to run on 3DFX HW (which would be really problematic).

[Veerappan]

Strictly speaking there is no problem implementing a fixed-function API in a Gallium3D-based state tracker as long as the API can be translated into shader-based draw operations (which is probably the case for Glide) - the problem is more with running on fixed-function *hardware*.

I don't remember if the proposal was to run Glide on new HW (which should be OK) or to run on 3DFX HW (which would be really problematic).

It looks like the student was proposing to allow newer gallium-capable hardware to run Glide Apps natively. He points out that there may not actually have been any Glide-based Linux Apps, but that Gallium is capable of running on Windows as well, so it might be useful there.

Of course, I'm pretty sure that many Glide apps were also 16-bit, which wouldn't execute too well on a modern OS without emulation of some sorts anyway. The Glide-OpenGL wrappers that we already have are probably as good as they need to get anyway.

He was mostly looking to get familiar with the Gallium API as a capstone project for his Bachelor's degree, not necessarily to resurrect the Glide API as a viable GPU programming API. He also asks for alternative projects if anyone has any that they can think of.

[cb88]

would it even be a bad thing to resurrect glide?

[WillyThePimp]

Also, why would be there any need to run it natively? Every app that used Glide should run faster than what it was deemed possible when designed/developed, even with a wrapper.

[Plombo]

Strictly speaking there is no problem implementing a fixed-function API in a Gallium3D-based state tracker as long as the API can be translated into shader-based draw operations (which is probably the case for Glide) - the problem is more with running on fixed-function *hardware*.

I don't remember if the proposal was to run Glide on new HW (which should be OK) or to run on 3DFX HW (which would be really problematic).

It was to run it on new hardware. Brian's point was not that it wouldn't be possible; it was that the fixed-function Glide was not a good match for the shader-based Gallium3D.