AMD-ATI vs NVIDIA, the OpenGL showdown
category: general [glöplog]
Quote:
Where's the problem in sharing between windows of a same process? I've been doing that for ages (not in an ATI, though). Just use the same render context and switch between windows using wglMakeCurrent.
Afaik what you need glsharelists for is when you deal with multiple processes each with its own render context.
Quoting from the docs for wglShareLists:
"When you create an OpenGL rendering context, it has its own display-list space. The wglShareLists function enables a rendering context to share the display-list space of another rendering context; any number of rendering contexts can share a single display-list space."
and
"You can only share display lists with rendering contexts within the same process. However, not all rendering contexts in a process can share display lists. Rendering contexts can share display lists only if they use the same implementation of OpenGL functions."
In short, the separate namespaces are simply mandated by the spec (regardless of whether you think that makes sense or not), and there's no support for cross-process sharing.
There's a general pattern there - aside from the usual driver bugs (and yeah, ATI definitely has more OGL-related bugs than NV does), NV drivers are usually pretty lenient in what they accept whereas ATI, Intel, 3Dlabs etc. try to follow the spec to the letter. Which is a pain if your code ends up being unintentionally broken without you noticing since "it works just fine here".
all you say makes me think that the radeon HD 4850 i raised a question about lately is definitely not a bad choice as a cheap gpu for 3d experiments
if it works with ati's glsl, it works with nvidia --> can i take that as a rule of thumb ?
if it works with ati's glsl, it works with nvidia --> can i take that as a rule of thumb ?
ATI drivers are generally pickier, but especially with GLSL, you just have to test. The really stupid bugs are fixed everywhere, but nontrivial shaders are still a hit-and-miss affair on all HW. For me, that's one of the main advantages of D3D nowadays - the HLSL compiler is also kind of fickle (prepare to fall back to an older version sometimes), but it compiles to shader binary code, and the shader binary->actual GPU code translators inside drivers are orders of magnitude less complex than GLSL compilers and hence significantly more mature.
does opengl 3.0 change the approach about glsl btw ? (for instance what you mention about no shader byte code)
No idea. OpenGL ES has compiled shader code. Among other things. Actually, GL ES is basically the better GL in a lot of respects :)
Quote:
if it works with ati's glsl, it works with nvidia --> can i take that as a rule of thumb ?
ATI forces you to write stricter syntax, so at least you won't get compile errors on nvidia.
We do mostly our shader development on nvidia and usually we need to tweak shaders when testing them on ATI for the first time. Sometimes because of bad syntax and other times because of ATI bugs.
On the other hand I've also had a glsl related driver crash bug only on nvidia+vista. ati+xp & nvidia+xp worked like a charm. So I guess you never can be totally sure that your code will work.
Still, I've learned to hate ATI while doing glsl stuff.
when i first did 3d accel stuff, i had nv hardware, but i had more problems with matrox and s3 than i did with ati cards. then i had all ati cards for a pretty long time (from 2001 on), and was seriously annoyed when i had to fix stuff to make it work on nv hardware (all using d3d though, i only used more of gl functionality than basic gl 1.2 from 2005 on or so). now i have a nv card again (gf8600gt), but i like to think i'm past vendor-related whining. you have to test it everywhere anyway.
of course, that is me now, without any problem of that kind to solve. just wait for me to bitch and curse loudly if i actually have to debug such crap :)
of course, that is me now, without any problem of that kind to solve. just wait for me to bitch and curse loudly if i actually have to debug such crap :)
Quote:
does opengl 3.0 change the approach about glsl btw ? (for instance what you mention about no shader byte code)
sometimes it seems to me that opengl 3 designers will never accept to implement loading og (pre)compiled shaders (to intermediate, hw neutral and easy to parse bytcode) even if they know it's a superb idea, just cause they don't want to accept that microsoft guys had a good idea doing so. Like the device caps...
iq: That's because it's not a good idea. Fictional assembly languages add fictional limitations - compiling directly from high-level code can in many cases generate better code than by going though byte code languages. At least that's what the shader-compiler team at work tells me.
ryg: "In short, the separate namespaces are simply mandated by the spec"
Wait...WGL... spec?! Let me quote the GL_NV_render_texture_rectangle extension spec:
"Additions to the WGL Specification
First, close your eyes and pretend that a WGL specification actually
existed. Maybe if we all concentrate hard enough, one will magically
appear.
"
Wait...WGL... spec?! Let me quote the GL_NV_render_texture_rectangle extension spec:
"Additions to the WGL Specification
First, close your eyes and pretend that a WGL specification actually
existed. Maybe if we all concentrate hard enough, one will magically
appear.
"
then they have a problem if they expect games to use gl one day... who can wait for the compile time while rendering? (and another thread will not do since only one thread can own the rendering context at a time) Opengl will become just a toy like this...
Quote:
Fictional assembly languages add fictional limitations - compiling directly from high-level code can in many cases generate better code than by going though byte code languages.
adding one feature shouldnt really imply the removal of another though.
iq: I'm not sure about what nv/at doesi, but we're perfectly able to compile shaders without noticable performance drops. On mobile phones.
Gargaj: No, but what's the point in adding it? OpenGL ES 2.0 did the right thing and added implementation-specific binary formats right away... Now THAT's actually useful.
Gargaj: No, but what's the point in adding it? OpenGL ES 2.0 did the right thing and added implementation-specific binary formats right away... Now THAT's actually useful.
That should of course be "nv/ati does"...
kusma: maybe thats because on mobile phones you arent making long enough shaders to really stress the compiler. :)
(something it's pretty easy to do on pc)
(something it's pretty easy to do on pc)
smash: Nope, it's not :)
Quote:
On ATI too. This is Windows-related: if a driver doesn't react or just runs a spin loop for a certain amount of time (5 seconds I think) Windows will assume either the driver or the HW has crashed and automatically BSOD. So now drivers do the same check and take care to abort and execute an internal reset before that happens, since BSODs don't look too good :).
Under Vista? In XP I can still render a single quad taking like 30s. I guess the driver can answer even though the gpu is working..
And yes, writing glsl on ati hardware is easier if you want your code to run on both. There may still be weird compiler bugs, but you won't have all the syntaxical problems and you have better error messages.
Quote:
Under Vista? In XP I can still render a single quad taking like 30s. I guess the driver can answer even though the gpu is working..
Under Win2k and XP too, at least with older drivers. Guess they've worked around that now. I guess on Vista the GPU core being busy for a long time is more of a problem since the 3D HW is actually being used for the GUI (with Aero enabled anyway).
This kind of means that for offline rendering, one could not build a "very lengthy" shader?
again, it depends on the driver/os combo you're running.
Or split the screen into tiles.
