yes - but this gives me nothing
i do not use deprecated api, opengl does not generate any error conditions - that's all the gdebugger can tell me
gdebugger with glexpert for nvidia is a powerfull tool - but without glexpert it is just another fancy tooll to view glerrors - and that tells you nothing about internal guts of the driver (and possibly software fallbacks / unnesesary swizzling's, etc. etc.).
Any other sugestions (besides switching to dx10 ? (with i cant do couse i must stay windows/mac-os/linux compatible)).
I've just read your post dar1243, and logged in to express my extreme anger and frustration with this particular topic.
I've been a loyal fan of ATI for well over 8 years now, ever since the 8500 was released. In all that time I haven't paid NVidia a cent, i haven't even touched their SDKs with a ten foot pole.
Now what's my end of the deal? How do things look at my side today? Well, lemme put it straight - they look pretty bad. Like dar1243, I too am programming in OpenGL. I get
- no GPU profiling;
- no shader debugging - glslDevil doesn't work on ATI.
Some of my friends who also work in the game development field and are in a position to force certain decisions have already switched to NVidia; from their point of view, a company which doesn't show any respect to the people working with its products doesn't deserve any kind of loyalty.
Developer drift, unlike the drift of clientele, cannot be directly measured in money; but the former ultimately leads to the latter.
I currently have an X1950 on board. When the time for the next update comes, I ain't choosing an ATI card anymore.
Unfortunately the gl profiler tools are no longer available. gDebugger used to have some support and there was another tool that was available on the AMD GPU Tools website.
We are currently working to address these issues.
In the mean time, try downloading GPUShaderAnalyzer to see if the shaders are non-optimal or if they are being compiled differently on 4800 hardware and this is causing slower performance.
What formats are you using in your FBOs ?
There are several things you can try on your own - if the shaders do not seem complex according to GPUShaderAnalyzer, try changing FBO formats, try to stick to a basic 4-channel 8 bit texture. Are you using multisampling or antialiasing? Is this app a typical "graphics" application, or is the app more GPGPU? If it is GPGPU, you may have poor ALU/Tex ratio (which ShaderAnalyzer should find and highlight in red).
Tell us a little more about your app and maybe we can offer more specific suggestions.
I'm already using gpuShaderAnalyzer
I'm outputing to 4 RGBA8 color attachments (1024x1024 without AA)
I' sampling from 8 RGBA8 textures (1024x1024 each), and yes its GPGPU
after some hacking and slaching and reordering functions and instructions in glsl it finaly works as fast as on nvidia ... so it turns out that glsl compiller does somethin stupid :/ (and gpuShaderAnalyzer does it its own way)
there realy should be some extension in opengl to query COMPILED assembly from compiled and LINKED GLSL program.
Anyway tools like glexpert really should be top ten priority for AMD_ATI to ease the life of developers
Those formats shouldn't be particularly slow. Although it sounds like our app could be bound by texture fetches if ShaderAnalyzer isn't warning you about an imbalanced ALU/Tex ratio. I bet your reorganized code puts a little space between the calls to Texture2D(...), thus allowing operations to have better parallelism.
GPUShaderAnalyzer should be able to show you the output for different cards and perhaps that comparison could show you where the differences are between other ATI cards and the 4800.
The output of GPUShaderAnalyzer is exactly the output of the GLSL compiler after compiling a shader, but not after linking. To clarify, if you input a VS, and your FS uses all of the VS outputs, then the GSA output should match exactly. However, if your FS only uses half of the outputs, then the driver may optimize them out, and will result in different assembly than what GSA outputs. For GSA, we assume that you are using all the inputs / outputs of the supplied shader.
That seems to be the case
I have also complex VS with do low frequency calculations that could be interpolated inside quads (i use 16x16 grid).
and before hack'n'slask not all outputs from VS were used by PS ps
and this IMHO coused driver to do some strange thing.
... and what about the MT openGL on radeons ? (the other dopic here
It is supported ussage pattern ?
I know this thread is a few months old now, but I wanted to make sure everyone knew that GPU PerfStudio 2.1 was made available and now has OpenGL support. The Frame Profiler should help a lot for identifying performance issues, and the Frame Debugger will allow you to access shader code, uniforms, render state, textures, etc.
In regards to the MT question - I'm not sure what the state of the driver's MT support is. I'm also not entirely sure how well GPU PerfStudio will handle MT either. Let me know if you try it!