Dienstag, September 08, 2009

r300: Whither OpenGL 2.0?

As you may know, there are currently two drivers for the Radeon R300-R500 families of GPUs. There is the classic Mesa driver and the r300g Gallium 3D driver.

The classic Mesa driver has obviously been around longer and has therefore seen more bugfixing and general attention. Naturally, r300g is not as mature even though Gallium 3D is where the future is, because the potential of many state trackers is only going to get bigger. Think a unified acceleration logic for the X server, client-side accelerated 2D rendering, OpenCL – the possibilities are endless: Each of these items simply needs a state tracker, and we can then painlessly hook our driver up to support these things without any additional work.

The question is where the cutoff should be. At which point do we "stop caring" about the classic Mesa driver? Here, "stop caring" obviously means stop implementing new features; bugfixing will remain important.

This has become a more important question for me now that I've entered new feature territory again with exploring GLSL. While the shader compiler is shared between classic Mesa and r300g, there will probably be some more required changes. Considering the fact that we also need to support the rest of OpenGL 2.0 to support GLSL well (a lot of applications will only test for OpenGL 2.0 and will not use GLSL otherwise even if the ARB extensions are there), I now have an even bigger incentive to make the break to Gallium.

I believe it's a very viable and sane strategy: Leave the classic Mesa driver at its current OpenGL 1.5 level and let it become a solid base for conservative users (including the next round or two of Linux distributions). In the meantime, get r300g into a good shape, particularly against Piglit, and get cracking on those OpenGL 2.0 features over in Gallium territory.

6 Kommentare:

Søren Hauberg hat gesagt…

From the outside I'd say that this depends on how far away the Gallium driver is. Will it be the recommended solution within one year? Three years? Ten years? This is IMHO crucial when making this decision.

Unknown hat gesagt…

Well if we never shift to work on gallium it won't ready quickly, it's an chicken and egg problem. We need to move to gallium so that it's ready as early as possible. So i am agree with Nicolai :)

Anonym hat gesagt…

I think you should add little features, like performance fixes and stability but thats it. The radeon driver needs to become as stable as possible.

Anonym hat gesagt…

Stopping at 1.5 is probably a good idea since r300g is almost ready. And I think that that the same can be applied to R600/R700 family. Today it supports OpenGL 1.4, so after reaching OGL 1.5 milestone r600g driver can be started.

Alex Wauck hat gesagt…

I think the best bet would be to put the classic Mesa drivers in bugfix-only mode and focus on Gallium. If it looks like OpenGL 2.0 will be supported in the classic Mesa driver within the next few months, then go ahead and do that first, but Gallium really needs to be a priority. I think Intel had the right idea when they decided to drop support for XAA, EXA, and DRI1, userspace mode setting in favor of UXA, DRI2, and KMS. Those who care can keep using the old code.

Nicolai Hähnle hat gesagt…

Another point is that the people working on R600/R700 have indicated that they would like to see a well working r300g before working on r600g, the idea being that with some experience from r300g, one can more easily avoid repeating mistakes - which I believe is a very good strategy.

All the more reason to go ahead with r300g.