While better tools would always help, the key issue right now is not the absence of tools but the fact that the devs are working on making things work in the first place rather than performance-tuning them. If the tools were to magically appear I expect the devs would take them for a spin then go back to making things work for a while longer. Optimizing doesn't really make a lot of sense until the new components have stabilized some more.
Remember that the tools you are describing are probably larger than the open source drivers, so working on tools would take a *lot* of resources away from the driver work; it's not like the proprietary world where you're looking at 100K lines of code for the tools and >10M lines of code for the drivers. One thing we are going to look at for 2010 is the possibility of leveraging some of our proprietary driver tools for use with the open source drivers. No idea yet if that will turn out to be useful, but maybe something will come from it.
The point I was trying to make was that I doubt anyone can say which of those bottlenecks is most relevent to *your* application without doing exactly the kind of analysis work you are describing (which isn't a good use of time right now), and therefore it's hard to say *which* of the upcoming development tasks is going to make the most difference.
From a pure driver development perspective, you are totally right. No disagreements there.
In a larger context, though, as a developer of applications, I can say for sure that I'd rather see better tools in general than a specific set of performance improvements in the drivers. When it comes time to start optimizing, getting truly powerful tools in place (which will swamp the driver size, even in the proprietary world) will take far more work than making some set of optimizations, but will in the long run allow more and better optimizations.
To be blunt, NVIDIA's driver team beats the pants off the ATI driver team, and I can't help but wonder if the reason for that is simply the insanely high quality tools NVIDIA has available. The PIX stuff was originally designed for ATI hardware but is mostly limited to Xbox development, due to the xbox devkit graphics hardware having more advanced debugging facilities than consumer graphics cards. I believe PIX now works on Windows as well, though I do not know to what level of functionality compared to the Xbox. If the newer consumer ATI hardware has the necessary features, I can't express how much I want it exposed, from an application developer perspective, not a driver perspective.
In many cases, the driver isn't even at fault. If the app is doing something dumb, the driver can try to add hacks to make it faster... but it's better to just fix the app. Especially in the Open Source world. But that requires that the app developers have the quality of tools available on OpenGL/Linux that are available on DirectX/Windows.
Wine 1.1.38 added the Mesa vender string for r600.
Here is the specific patch:
So hopefully this means Windows games will start working on r600 better. The first step would be finding out what the hardware is, so you know it's limitations.
Originally Posted by pvtcupcakes
Excellent. Can't wait to test it.
Awesome. I got Counter Strike Source to work. :D
It only works with -dxlevel 70. The menu freezes on DirectX 8 or 9. And I had the settings set to all low; I didn't try anything higher.
Just played on a server with about 20 people and it was really playable. It only lagged a little, but it wasn't too bad.
HD acceleration is crucial to my choice in hardware as I want a very silent low power CPU. As it stands now, the ION platform is the obvious choice (but saving money for summer travels), and any AMD GPU solution is just out of question for that reason, and I believe this is the case for any other person looking at building a HTPC. I don't know if licensing issues will prevent an OSS implementation of VA-API, but a tiny binary blob of this part would be welcomed with open arms by me :)
Originally Posted by bridgman
Sauerbraten is finally working for me.
OpenGL renderer string: Mesa DRI R600 (RS880 9712) 20090101 TCL DRI2
OpenGL version string: 2.0 Mesa 7.8-devel
OpenGL shading language version string: 1.10
This is on a radeon 4200 which I think has 256Mb sideport (gateway NV53 Athlon II M300) I was also emerging in the background so that may have affected the fps. This is on gentoo with mesa-9999 aka git master
strangely glxgears is 840 when idle and 1200 when one cpu core is pegged with something else (ie compiling)
Here is the shot at my native screen res with nearly all effects enabled I did disable refraction as it makes water black
Hi crispy. I just built a HTPC with an ASUS M4A785T-M motherboard (integrated HD4200 gpu) and an AMD Athlon II 235e cpu cooled fanlessy. This system is able to play full HD videos (problably not at Blu-ray bitrates, but who cares?) using only xv acceleration. Of course UVD support would be nice, but everything already works fine for me.
Originally Posted by crispy
Prey works pretty well using the native Icculus port.
I have the settings on like Medium and it runs plenty fast enough.
The only problem I could find was that enabling Shadows would cause rendering errors. So if you don't mind playing with no shadows, it works really well.
I thought of that possibiblity also, but was worried that passive cooling would require a big case and some ventilation etc. How hot does it run while playing HD?
Originally Posted by kbios
Another nice thing about the ION platform though is some of the boards have their own PSU's and being micro itx you can have a tiny tiny case :)