good to know.
Remember that it's not just us doing the work. Our developers are supposed to be "a small part of a much larger community".
I reallistically can't see outside devs bringing a full-featured driver for a just-released hardware. And I can't see AMD releasing specs way before the hardware is selling.
So community work will always be good for infrastructure, porting and debugging, but the core work has to be done by insiders if it's meant to be on time (not years after the hardware is on the shelves).
Depends what you mean by "core work". I agree that our time is generally best spent adding support for new GPUs, since that is the one area where access to inside information can speed up understanding and troubleshooting even if the inside information can't be released.
That said, there are also a few places where pitching in a bit of effort might be able to "push something over the hump" and make it possible for community developers to make progress on other parts of the stack. That's how I see the 3xx-5xx Gallium3D driver, and why I think it's worthy of some time.
Last edited by bridgman; 09-02-2009 at 12:41 PM.
Hopefully basic 3d accel and KMS for r600+ will make it to Fedora 12
Exactely. r300g is both infrastructure (looking to improving Gallium3D) and porting work, so it's best done by the community but can be done only on that kind of hardware: many years old (r300 is 7 years old) and well-known by people outside AMD.
Originally Posted by bridgman
But an r800g driver could only be made by AMD (otherwise it'd be ready in 2016), that's why I hope you'll manage to get it out on time.
I expect that the first step for Evergreen 3D will be adding support to the classic Mesa driver - that will get functionality into users hands much more quickly.
Once support has been added to the classic mesa driver, anyone in the community can write "r800g".
I have to say that the plans outlined by bridgman are all very reasonable, and I agree that it's the Right Thing for going forward.
We've had a short discussion about r300 vs. r300g on IRC without any real conclusion. Obviously, the long term focus will be on r300g, there's no doubt about it; the question is whether classic Mesa will get OpenGL 2.0 support.
Personally, I increasingly side towards not adding OpenGL 2.0 to the classic driver. Better to stabilize it at an OpenGL 1.5 level for the conservative folk, and then focus on getting up to OpenGL 2.1 for Gallium.
Yep. Once r300g gets a bit further it will (hopefully) become a lot easier to decide where each new feature should be implemented, and at that point it seems likely that anything more than low-hanging fruit will go into r300g. Right now there's a strong temptation to add functionality to r300 "because it is there".
If we can continue to share the shader compiler between r300 and r300g (thank you !!) I guess it's possible that r300 may end up as "1.5 plus GLSL" but there may be other driver enhancements required to support GLSL that I haven't realized yet. I have no ideal how GLSL arrays are implemented, for example
Last edited by bridgman; 09-02-2009 at 04:10 PM.
Tags for this Thread