Radeon Gallium3D OpenCL Is Coming Close

**bridgman** · 05-13-2012, 10:12 PM

Originally Posted by benjamin545

so in the linux ecosystem, we have some paid hardcore developers and we have a lot of hobbyists. hobbyists will never ever individualy on their own design a modern graphics driver thats competitive with todays standards, and thats ok. now as we have seen in the linux graphics stack over the past few years, paid hardcore developers have come a long way in creating a very competative graphics stack, but we really want hobbyists to be a part of that too, and while some have, i think a lot of people while willing a possibly able to conribute, still feel overwhelmed with the complexity of it all.

This is one of the interesting tradeoffs. Do you want the driver to be simple and accessible so more people can potentially contribute, or do you want it to be sufficiently sophisticated that it could potentially match the performance of proprietary drivers at the cost of reducing the pool of potential contributors ?

The current open source driver standards seem to be aimed at the knee of the curve, where they're sufficiently complex to allow writing "fairly performant" without becoming "twice as complex for a small increase in performance". Seems like a good compromise, but it's important to understand that it *is* a compromise.

As an example, the open source drivers have a relatively large amount of common code and a relatively small amount of HW-specific code but if you want to get that last 20% of potential performance you generally need to move the line up and have substantially more of the driver stack being hardware-specific. That makes the driver code larger and more complex, which in turn makes it a lot harder for potential developers to contribute.

Originally Posted by benjamin545

getting more the the point i guess, is that if tgsi is a simpler ir to transport between various componants, if i was a newcomer wanting to develop a componant, it would be easier to deal with tgsi. if it is then nessicary to convert it to something more specific to what i am doing, (whitch is what ive been hearing all along is that its too hard to create one all encompasing ir that is perfect for all state trackers and all hardware drivers), then that is what would hae to be done. at least then you could try to make your internal ir something specific to your hardware, for instance, i sure the nvfx/nv30 driver, with its ununified shader cores, is much diferent than the nv50 or nv0c or whatever.

IR is affected both by hardware characteristics and choice of compiler frameworks being used. If everyone settles on a single compiler framework then that IR will probably win -- otherwise TGSI will probably get extended so that it can serve as a common language between the different compiler stacks. The interesting question is whether it will be noticeably faster to convert directly from one structured IR to another, or whether going through a common "flat" IR will be close enough in performance that the benefits outweigh the costs.

Originally Posted by benjamin545

it would be best if other parts of gallium had that same kind of mentality, for instance, memory management is one where initialy gallium was sold as being able to abstract memory management compleatly into the sinsys portion of the driver, but whate ive read before is that a lot of the memory management has been implemented in the hardware drivers usualy due to some feature missing from gallium or it just being easier for whoever is doing it to do it in the driver (im guessing proboobly a lot of that comes from the initial testing and learning stages).

The winsys layer was supposed to *abstract* things like memory management not *implement* them. The implementation was always expected to be in the lower level drivers (eg the kernel driver aka drm)-- the Gallium3D abstractions just provide a standard way to call those functions.

**crazycheese** · 05-14-2012, 06:55 PM

Originally Posted by bridgman

This is one of the interesting tradeoffs. Do you want the driver to be simple and accessible so more people can potentially contribute, or do you want it to be sufficiently sophisticated that it could potentially match the performance of proprietary drivers at the cost of reducing the pool of potential contributors ?

Excuse me for short intervention, but what about complexity of Linux? Was it fatal? Has number of hackers reduced from version 0.01 till recent or increased? We don't get 80% performance, we get 20%. We are missing raw programming resource, everyone knows this. Also, everyone knows we don't achieve this resource by talking it over and over, or by endlessly changing points of view and finding array of arguments. If we are to change something, we are to pick direction and follow it. This will never happen, it is fact. Again, excuse me for interruption.

**bridgman** · 05-14-2012, 08:50 PM