One year ago, people here preferred buying a Radeon 9500/9700/9800 (Pro). There were the best cards, ATi was in people’e heart: because NVIDIA lied, and because of the performance results.
Today, the same people changed their mind 
ATI hardware is crapy, misses features, …
hey … life is life, so is marketing. Everybody is lying 
Today, the same people changed their mind
ATI hardware is crapy, misses features, …
I disagree. My programs run about 3 times faster on a X800 than on a Geforce 6800. ATI hardware is not crapy for sure.
Anyway I have problems with the new driver 5.3.
The performance dropped about 10% compared to the 4.12 and there must be a bug in the shader compiler.
Debug output says something like “Driver was not able to install pixel shader” and the D3D debugger says “probably unsupported shader profile”.
That does not make sense. I am using shader 2 profiles only and it used to work in older driver version. And it works on Geforce6.
Anyone similar experiences?
My programs run about 3 times faster on a X800 than on a Geforce 6800. ATI hardware is not crapy for sure.
It depends on how you define “crappy”. If what you care about is performance, ATi makes reasonable hardware. Though your specific case of a 3x performance improvement is probably something that you’re doing that your GeForce doesn’t like.
But, if you care about advanced features, ATi doesn’t make reasonable hardware. Indeed, in the need to support both, ATi is actually slowing the progress of graphics by making feature-incomplete hardware.
I would like to see a list of limitations of each vendors GL implementation instead of discovering them after I have implemented something that uses a particular extension that executes something off the ‘fast’ path.
An good example of the information I like to see were the tables that came with ATIs 9700 devkit that lists exactly which vertex and texture formats were hardware accelerated and amount of cycles it took to execute each arb_fp/arb_vp instruction.
I would like to see information like this for all of ATIs (and Nvidia) cards. I would like to see more details about what features are emulated and which are fully hardware accelarted instead of having to guess if its a driver bug, my code, or its the emulation or my bad usage of the API slowing things down. Stuff like the expected bandwidth for various methods of upload/downloading for textures and vertex data on various cards and on AGP/PCI, so I know what kind of performance speedup I should expect by switching over my uploading to use PBOs (for example).
Btw, does this version of Catalyst support rectangular texture sampling in GLSL? (And I do agree with the other posters, the most anticipated ext is EXT_framebuffer_object)
There isn’t a conformance test application for 2.0 is there?
I know there was some talk about this in last years meeting notes, but I don’t recall anything that came from it.
Hopefully all the ARB members will stop the infighting and get something done in the march meeting.
Hopefully all the ARB members will stop the infighting and get something done in the march meeting.
“Get something done” along what lines? EXT_FBO is finished; it’s not up to the ARB to implement it. Sure, there’s some extra extensions that they need to work on to add a number of different capabilities (selecting texture formats, render to vertex array, etc). However, outside of these, there’s not a whole lot for them to do. If another programmable domain is going to be opened up, such an extension should’t take too much work. Otherwise, there’s just not much left to do.
Originally posted by PsychoLns:
Several of the other GL2 related extensions are not defined in the 5.3 drivers (draw buffers, float textures), but it’s still a 2.0 driver as the core functions are available.
Reading the OpenGL2.0 spec and comparing it with the extension string reported by my new ATI X800 XT the following extensions are missing even though they were promoted to GL2.0:
ARB_texture_non_power_of_two
ARB_draw_buffers
EXT_stencil_two_side
The issue with NPOT textures has already been discussed but I am interested in the issues with the other two.
ARB_draw_buffers is not exposed even though ATI_draw_buffers is. Taking just a quick lock at both specs, one difference that I could spot was that ARB_draw_buffers list ARB_fragment_shader as an additional dependency. So, what does it mean when ARB_draw_buffers is not exposed but ATI_draw_buffers is? Does it mean that there is no hardware support for multiple render targets from a GLSL fragment shader but only from a fragment program?
EXT_stencil_two_side is based on the ATI extension ATI_separate_stencil with additional state. It is not exposed through the extensions string. If I use it through the OpenGL2.0 core functions does it work at reduced speed?
And there is also the ARB_texture_rectangle extension which is not expoded. The spec to this extension says it is identical to EXT_texture_rectangle, which is present in the extension string. Why is then ARB_texture_rectangle missing?
I don’t think there’s any real reason for those extensions not being there yet. But it IS confusing considering the usual way of not exposing extensions that aren’t hw supported.
But afaik those extensions doesn’t really have anything to do with GL2 - GL2 is just incorporating the same functionality as these extensions. And instead of querying the extensions you should simply look for the 2.x version string and then get the function pointers (glDrawBuffers instead of glDrawBuffersARB etc).
Especially EXT_stencil_two_side is not GL2, it’s just nvidia’s “version” of ATI_separate_stencil (why is described in the EXT_ spec), and none of them is exactly the same as the functionality in GL2. Haven’t tried the new one yet instead of the annoying double implementation (no need to yet, as the old version is working and we probably won’t have (official) NV GL2 drivers anytime soon)
EXT_stencil_two_side is slightly more flexible than our hardware. ARB_texture_rectangle and ARB_draw_buffers interact with GLSL whereas EXT_texture_rectangle and ATI_draw_buffers do not. Both should be possible to implement on our hardware though. Rectangles in GLSL hasn’t been implemented yet, not sure why ARB_draw_buffers is missing though as the same functionality should be available through GL2. I guess it could also be a matter of something not being fully implemented yet.