I'm not sure if I got my point across, so I'll spell it out more cleanly.
Originally Posted by plonoma
My understanding is that when a feature is under development, the driver is reporting that feature as available when the user program queries it. I think there should be one of two solutions (or both of them):
a. The feature is never reported as available using the standard API. A new standard or non-standard API is used to query the list of in-progress features. This would allow special programs to be used to test new features without impacting real applications.
b. The feature is not reported as available using the standard API until a standard or non-standard API call is made to inform the driver that it is in testing and evaluation mode. In-progress features are then reported as working. This allows normal applications to be used to test the driver with the feature, with only a small change or wrapper to the application.
The table you linked to has a lot of options, and I'm not sure the complexity of having more states than working/WIP/not working in the drivers and APIs themselves is worth the benefit it would bring. That is definitely the kind of knowledge that I think should be available programmaticly, though.
But talk is cheap, and I'm no X developer, so I may have no idea what I'm talking about.
actually, he made a valid point and testing in mesa mailing list confirms that: most (all?) open drivers pass almost all the tests but just crash ff randomly because of few other bugs.
Originally Posted by RealNC
Originally Posted by schmidtbag
Well, how hard is it to hit a moving target ? 3d code is massively complicated and the IL "intermediate layer" and the assembly compiler are effected by the ever evolving kernel changes.
should it be easy to write code for linux for good 3d performance, on paper yes. Is it viable for companys to chase the roving targets ? likely not. All of these GPU accelerated apps rely on a fiarly consisten API to function properly and becuase the linux API is highly flexiable and in a state of flux, its very hard to target properly.
With gallium drivers and the gallium IL and IL API comming along quickly, we might see a gpu accelerated browser.
People forget alot of the code in the nvidia and ati 3d drivers is likely microsoft code to begin with which is why we all get screwed in the end. New GPU's are very very dedicated to current Direct X standards from the hardware layers up to the drive IL language.
Its not a cut and dry problem.
Well the drivers support many cards from many families, not all are cards equally well supported. In fact Evergreen support in r600g has regressed so badly that it can't even run blender without locking up. I guess that's what you get when everybody hacking on it only test with the cards they have available (probably HD 4xxx series), sigh...
Originally Posted by dfx.
Anyway here's my experience with Firefox + WebGL + latest r600g:
As you can see it's a little more serious than just Firefox crashing. So I can certainly understand why the Firefox devs have disabled WebGL for anything but NVidia blob.
WebGL demo from:
Tags for this Thread