Disclaimer: this may sound more like a rant, but I believe people at ATI should know there’s so much more to 3D graphics than DirectX games.
Personally, I firmly believe ARB vertex and fragment programs are alive and kicking, since they still offer a significant performance gain over GLSL in most situations; that’s why I like to stick with them within my engine.
The following glut application (source is included) has been tested on a Radeon x800 and on a Mobility Radeon 9700, with both 6.14.10.5819 (catalyst 6.5) and 6.14.10.5949 (catalyst 6.7) atioglxx.dll versions: http://www.glexcess.com/temp/ati_bugs.zip
As you can see in the sample I am attaching, vertex and fragment programs expose different behaviours; in particular, light positions are trasferred correctly (eye-space) to VP’s, while FP’s fetch light positions in world space.
I sent various reports about this bug to devrel almost two years ago now, but it never got fixed.
On a different note, I have noticed that the spotlight cutoff parameter is being read correctly by FP’s, but the same is not true in VP’s.
Needless to say, NVidia drivers are not affected at all by any of the afore-mentioned bugs.
Honestly I am fed up patching ATI drawbacks with program parameters, so PLEASE PLEASE PLEASE Emil or anybody who’s in charge of GL driver quality, give us a fix and get aligned with the specs.
Shouldn’t this be possible for any reason, PLEASE PLEASE PLEASE just let me know, I won’t bear anyone a grudge, though I will need to remove support for ATI boards from within my engine and let the users know they won’t be able to run my
applications unless they buy a different graphics board.
P.S. I would also be willing to start a petition in order to get ATI drivers fixed, people who are interested can drop me an email at - support at glexcess d0t c0m -.
Personally, I firmly believe ARB vertex and fragment programs are alive and kicking, since they still offer a significant performance gain over GLSL in most situations
The OpenGL ARB does not agree with you. I’m not just talking about ATi; I mean all (or, at least, 1/3rd) of them.
If you wish to continue using these extensions, you may. But you’re going to be missing out on, well, pretty much everything. Geometry shaders, etc. And if ATi doesn’t want to bother fixing bugs in these extensions (as long as Doom 3 continues to work), that’s their decision. And it’s not that bad of one.
Personally, I think they have more important driver bugs and features to work on.
I am fighting with a lot of bugs in ATI OpenGL drivers too. It is often frustrating to see how simple problems (that should require very little time to fix) keep coming back from versions to versions.
It would be very interesting if someone could find a nice way for all ATI OpenGL developers to submit and share the OpenGL driver bugs that they find. Some moderator mechanism would be needed to filter out false bugs.
It would then serve two different purposes:
Help all ATI OpenGL developers to avoid the pitfalls of already known ATI driver bugs
Show ATI how many problems they have and hope they realize they need to invest in fixing them
I’m not sure if the companies will like it, but you could put it in the Wiki. I recently submited a bug report regarding GLSL to ATI and also had found a simple workaround that doesn’t effect performance for both IHV.
On NV, since they convert GLSL to their own assembly (NV_vertex_program and NV_fragment_program) as is my understanding, they will update them.
On ATI, I doubt that ARB vp and fp have been updated since GLSL. For example, the 3Dlabs skinning animation is working full speed now, while before it was running in software for the vertex shader.
Personally, I firmly believe ARB vertex and fragment programs are alive and kicking, since they still offer a significant performance gain over GLSL in most situations; that’s why I like to stick with them within my engine.
I used to feel the same way, but when I was told that FP and VP were no longer going to be extended, I switched over to GLSL. At first, I saw a signifigant drop in performance (about 20-30%) on NVidia cards.
In almost all situations, I’m fragment bound due to shader complexity (8 texture samples, 40+ instructions in hand coded assembly). That said, it appeared that GLSL fragment shaders were signifigantly slower than asm shaders. What I didn’t realize is that it wasn’t an apples to apples comparison: I was using ARB_precision_hint_fastest in my asm shaders. After modifying my shaders to use the ‘half’ types on NV cards, my performance shot up to the original level.
That said, one thing that seems to be missing from GLSL 1.2 is precision hints. I would like to be able to specify precision hints not just per program, but per variable if possible (perhaps “fast” as a keyword). Doing things like this might allow optimizers to be more aggressive with regards to reordering math. It could also let vendors use their own internal fast types and instructions (IE: NV’s half type). It could potentially be ignored by the implementation if there is no benefit.
Also, is there a reason precision hints were avoided for GLSL? Was there not enough developer interest? Perhaps this is something that won’t be an issue in the future (kinda like how Intel CPUs handle double at the same speed as float in some situations)? Perhaps there is too much complexity in supporting this?
I personally find myself looking at the intermediatary ASM output from high level languages quite a bit to see what the compiler is doing and how I can reorganize my code to give more hints/leeway for the compiler to optimize my shader. So even though I program in a high level shader language, I basically still end up writing/thinking my code in ASM also.
I hope they keep around the ability for the compiler to output some kind of ASM (even if the Cg/GLSL compiler is skipping the ASM intermediatary). Sometimes this offers incredible insights to improving performance - jeez, why is the compiler sticking all those extra MOV operations in there… and I fiddle around, reorganize things a bit, put some swizzles and write masks in and they go away.
I often look at the assembly code for my C++ code and this gives me insight into reorganizing my C++ code so my compiler can do the best job possible… shouldn’t I be able to do the same for my HLSL/Cg/GLSL? Even if ATI/Nvidia defined their own different instruction sets (since they probably don’t think internally in ARB ASM), I can see this being helpful to optimization.
I’d kinda like to see some kind of precision hinting or types in GLSL also. Although, the problem here is some cards only do 24 bit or 32 bit float while others can do both 16/32 bit. Not sure on this. I wish all cards had 16/32 pixel shader modes so we can tradeoff performance/accuracy.
I wish all cards had 16/32 pixel shader modes so we can tradeoff performance/accuracy.
For some cards, there’s no performance tradeoff. That’s why they don’t do 16-bit floats; they can do 32-bit floats just as fast.
Plus it seems to me that part of ARB’s overall strategy with GLSL was to dispense with implementation details, like fp precision and register allocation.
I agree that it would be nice to have finer grained control over these things at times, but perhaps in the long run it’s better this way. The ARB is clearly taking the long view on this one, and given OpenGL’s history it certainly seems like the right thing to do.
I agree that it would be nice to have finer grained control over these things at times, but perhaps in the long run it’s better this way. The ARB is clearly taking the long view on this one, and given OpenGL’s history it certainly seems like the right thing to do.
I’m currently undecided on precision hints. Precision hints could be used to reorder math for better performance by the GL implementation. That said, it seems like there would be benefit to this in the future as well as now. Although I guess this could introduce inconsistancies between implementations in regards to maximum amount of error, etc, that might be difficult to deal with. As far as types and such, they could always be exposed via an extension I would think (unless there are rules against this sort of thing?). Either way, dealing with 32-bit floating point is the way to go in the future, preferrably throughout the entire graphics pipeline.
On the original topic, it seems clear to me that OpenGL divers are difficult to implement for the IHVs. I’m no expert on this, but I imagine each IHV has to take a measured gamble on the resources allocated to various things, like implementing OpenGL, weighed against other money makers for them, like D3D games. As fiercely competitive as consumer graphics is, it should come as no surprise that things might end up a bit lopsided, in one camp or another.
I think the really good news here is that with the proposed version 3.0, OpenGL is going to be much easier to implement, for both Ati and Nvidia, so many of these problems should just go away.
@Korval: I don’t know if I got it right, but I’d be glad if you could provide that document you were talking about, the one that states that shading language is faster than programs. As for geometry shaders, I guess they won’t be supported any time soon, and frankly I am not that interested at the moment (but it could just be me). Instead I would love to know what other features I am missing, except for loops I can
manually unroll and flow control I can manage with alpha test or NV programs. As a matter of fact, programs offer the highest level of control to developers. And by the way, I don’t mean to flame anyone here, but the fact that you can live with buggy program support does not imply things are alright this way; indeed, I find it quite dangerous to say something like that, especially on the official GL forum, somehow it implicitly legitimates vendors to act at their own convenience. That said, I am aware that the shading language has its big problems and limitations with current drivers, but here we are talking about a couple of fixes that could hardly take more than half an hour of work; nonetheless these have been ignored for years. Oddly enought, I always thought that publishing a feature within the extensions string would mean that feature is supported and NOT discontinued, unless it is proven it is working flawlessly.
@Others: About the “bug-forum”, I love the idea, I could easily write/host a small web app for this purpose; I thought it could be organized as follows:
bug reports should be related to the latest driver version only
bug reports should be classified under different categories (such as FF, VP, FP, GLSL), matters (like ‘software mode’, ‘incorrect binding’, etc) and so on.
each bug report should always be accompanied by a (possibly small) test application with source included that reproduces the problem
every 2 or 3 months, reports/sample apps could be signalled to vendors, in order to get fixes or at least a roadmap for fixes in sight
We would obviously need a number of people with different cards, willing to install/uninstall drivers rather frequently so that we can make sure we don’t send bs to vendors. I believe we should talk about it seriously, it could turn out to be a valid and transparent repository of useful information for developers experiencing troubles with different GL implementations. Anyone who is interested, even just to talk about how it could be done, please contact me at the address above, we may even start a new thread here if mods don’t mind.
“somehow it implicitly legitimates vendors to act at their own convenience”
I believe they have every right to act at their convenience, or at the least at the convenience of customers who control a significant share of the gaming/visualisation market, especially when it comes to out-dated extensions.
I’m sure if a significant registered developer actually rings up the dev team and insists on a fix date, then the bug will be fixed.
Otherwise you’re really not in a strong bargaining position, and not doing yourself any favours by slagging them off on a public forum.
Originally posted by knackered:
[b] “somehow it implicitly legitimates vendors to act at their own convenience”
I believe they have every right to act at their convenience, or at the least at the convenience of customers who control a significant share of the gaming/visualisation market, especially when it comes to out-dated extensions.
I’m sure if a significant registered developer actually rings up the dev team and insists on a fix date, then the bug will be fixed.
Otherwise you’re really not in a strong bargaining position, and not doing yourself any favours by slagging them off on a public forum. [/b]
Now that’s positive feedback!
Apart from jokes, I guess everybody here already knows this.
Anyway I am afraid I was not clear enough, the purpose of the above mentioned forum would not be that of “defacing” vendors as I believe this would be pretty useless, instead it should be intended as a way to join voices together and gather some attention without the need to get a job at Id.
Until this does not happen, each one of us as an individual will stay pretty hopeless as you said.
Originally posted by nullptr: That said, I am aware that the shading language has its big problems and limitations with current drivers, but here we are talking about a couple of fixes that could hardly take more than half an hour of work; nonetheless these have been ignored for years.
Ya, it has some issues, but in general the GLSL compiler of ATI is quite advanced.
They want you to use GLSL and they are working on it.
I’d be glad if you could provide that document you were talking about, the one that states that shading language is faster than programs.
I said nothing about performance of glslang vs. assembly (btw, they’re both programs. Calling one shaders and the other programs does nothing to distinguish them). I was referring to the relative quantity of support that ATi is giving them. IE: virtually none for assembly.
Instead I would love to know what other features I am missing, except for loops I can
manually unroll and flow control I can manage with alpha test or NV programs.
I’m sure that, back in the days of the switch from texture environment/register combiners to shaders, there were people who didn’t feel that shaders (assembly or glslang) offered them anything of note. They were happy puttering along with their stuff and felt that they could emulate what they needed with a multipass here or there.
I don’t feel sorry for these people or the bugs that they may encounter in modern shader-based drivers when they’re still using a decade-old API that had a couple of bandaids slapped on it. Either join the present or languish, adapt or perish.
the fact that you can live with buggy program support does not imply things are alright this way; indeed, I find it quite dangerous to say something like that, especially on the official GL forum, somehow it implicitly legitimates vendors to act at their own convenience.
I have to say that I’m with Knackered on this. When GL 3.0 L&M comes out, with a rigidly defined fast-path and layered/depricated other junk, then we can talk when one of the fast path parts is being buggy. Until then, I’m happy with vendors telling us, either directly or indirectly through bugs, to not use certain APIs. If the assembly API is buggy and not being fixed, that’s because it’s not the path being actively developed.
This is good for developers too. We don’t have to guess which of the 3 APIs for vertex transfer is the right one to use; we know that it’s VBOs. We don’t have to guess at which shader API to use; it’s glslang.
That said, I am aware that the shading language has its big problems and limitations with current drivers, but here we are talking about a couple of fixes that could hardly take more than half an hour of work
Do you know that for a fact? Have you seen the code?
It is the wise programmer that understands that, until you know and understand the code, giving a time estimate for a bugfix is falacious.
Oddly enought, I always thought that publishing a feature within the extensions string would mean that feature is supported and NOT discontinued, unless it is proven it is working flawlessly.
That’s not practical. There’s code out there (old code), games people play that uses assembly programs. You can’t expect someone to download a new driver and have it stop working (or look ugly) just because you decided to cut out some legacy from your drivers.
The real world doesn’t work that way. If you supported an extension that was fairly popular, you’re pretty much obliged to support it for a good 6-8 years.
Originally posted by Korval:
I don’t feel sorry for these people or the bugs that they may encounter in modern shader-based drivers when they’re still using a decade-old API that had a couple of bandaids slapped on it. Either join the present or languish, adapt or perish.
I’m happy with vendors telling us, either directly or indirectly through bugs, to not use certain APIs.
As far as I know the OGL philosphy always was that it is upward compatibile and great ammount of time was invested in that.
With the approach that is fine when old parts of the API do not work correctly, the OGL will become much worse API than than the DX because the DX changes in each version to drop unsupported features, so it is clear what way is the supported one, and because the DX does not “wast” design time in ensuring that specific feature is futureproof since it may be easily removed in next API version.
It is fine if the most optimal API is told by papers or technical talks. It is not fine to tell that trough bugs.
Originally posted by Korval: The real world doesn’t work that way. If you supported an extension that was fairly popular, you’re pretty much obliged to support it for a good 6-8 years.
During 6-8 years there will be several generations of graphics card. If they wish to support such games (e.g. Doom 3) even on that new HW, they likely will need to update the extension implementation to support that HW anyway so they can dedicate some time to fixing bugs as well.
