Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 12 of 19 FirstFirst ... 21011121314 ... LastLast
Results 111 to 120 of 184

Thread: Official feedback on OpenGL 4.0 thread

  1. #111
    Junior Member Regular Contributor
    Join Date
    Jan 2004
    Location
    Czech Republic, EU
    Posts
    190

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Groovounet
    ... and glGet are likely to imply a stall
    This is a myth and I wonder why people are following it so blindly. glGet should never cause a stall except for hardware queries. Drivers may (and should) store any OpenGL state in the context thread and pass only real rendering commands to the internal worker thread of a driver. Where are the stalls now? Yeah, there are none.

    Quote Originally Posted by Alfonse Reinheart
    ATI might pretend that the entire HD 5xxx line may support 4.0 and silently convert doubles to floats
    Welcome to the reality. Yes, features are being faked, were, and will be. Live with it - it's a tradition. Otherwise all ATI GL2.1 GPUs would be advertising GL1.1 (hw support for texture_lod is missing and the same holds for at least 2 other GL2 features) and some early pieces of ATI GL3 stuff would be advertising GL2.1 (hw support for draw_buffers2 is missing). They can't afford marketing their GPUs as being on the same level as the "old crap". It doesn't surprise me they're going to fake doubles, I am expecting it.
    (usually just hobbyist) OpenGL driver developer

  2. #112
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.0 thread

    Drivers may (and should)
    But they don't, so it doesn't matter what they "may" or "should" be doing. They don't, so glGet is a bad idea.

    And why "should" they? If I don't need to glGet anything, why should the driver be taking up precious memory to mirror something I don't care about? That's why it is left up to the application.

    Live with it - it's a tradition.
    This is different. textureLod is not a feature that is frequently used. It also doesn't affect the output much, so its absence is not a huge thing. And drivers that don't yet implement everything are quite a bit different from drivers that will never implement everything.

    If you ask for double-precision, it is only because you need it. You will not get an acceptable answer from single-precision computations.

    On the plus side, double-precision matters a lot more for OpenCL than for OpenGL. So not many GL applications will actually care, and OpenCL has a way to effectively test this.

  3. #113
    Junior Member Regular Contributor
    Join Date
    Jan 2004
    Location
    Czech Republic, EU
    Posts
    190

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Alfonse Reinheart
    Drivers may (and should)
    But they don't, so it doesn't matter what they "may" or "should" be doing. They don't, so glGet is a bad idea.
    Do you have a proof for this? To my knowledge, an implementation-dependent issue which can be resolved so easily isn't a good justification for getting "some other feature" into the spec. I want DSA as much as you do but for the reason it's more efficient as a whole rather than some implementation has issues to do multithreading right in the first place. A few more kilobytes of variables in memory? Yeah that's really too much wasted space, isn't it?

    Quote Originally Posted by Alfonse Reinheart
    If you ask for double-precision, it is only because you need it.
    You don't ask for anything - it's simply advertised to you. It's the same case as with NPOT textures. You either get it in software fallback or never.
    (usually just hobbyist) OpenGL driver developer

  4. #114
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.0 thread

    Do you have a proof for this?
    Name an IHV who has ever, ever recommended that glGet functions are perfectly fine performance-wise and that user mirroring would be a waste of time.

    Since the earliest days of OpenGL implementations, driver writers have drilled into our heads that glGet is bad. Maybe that's changed in 10 years, but they have not yet said otherwise.

    You don't ask for anything - it's simply advertised to you.
    Of course you ask for it. If you use a "vec3" in any GL 4.0 shader, you're getting floating-point values. Only by explicitly using a "dvec3" do you get double-precision values. Just like with NPOTs, you must ask for them to use them.

    And just like with NPOTs, if you ask for them, it is because you need them.

  5. #115
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.0 thread

    I want DSA as much as you do but for the reason it's more efficient as a whole rather than some implementation has issues to do multithreading right in the first place.
    DSA is not about efficiency. DSA does not mean that drivers can happily get rid of the name-to-pointer mapping. DSA does not make your code more efficient.

  6. #116
    Intern Contributor
    Join Date
    Feb 2004
    Location
    Germany
    Posts
    59

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Alfonse Reinheart
    DSA does not make your code more efficient.

    I disagree. DSA would mean that I could get rid of an entire headache inducing crap layer in my code that's only there to track down and manage current bindings.

  7. #117
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.0 thread

    I was talking to Eosie, who seems to think that what you are referring to is unimportant, since you should just be doing glGets.

  8. #118
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    935

    Re: Official feedback on OpenGL 4.0 thread

    Ok, I actually agree with Eosie if we stick to the theory.

    All glGet doesn't stall, some does, some doesn't. Which one? I don't know, It's more guessing than proving facts and probably implementation dependent so I prefer to consider the glGet stall as a good practice.

    I made some tests (a while ago back at OpenGL 2.1 time!) comparing glGet and macro state objects build with display list: obvious win for the macro state objects even if I changed a lot more states than required this way.

  9. #119
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: Official feedback on OpenGL 4.0 thread

    Don't forget that a glGet* call will call into a driver-DLL, which is ALWAYS slower, than calling your own functions, no matter how fast that function actually returns.
    GLIM - Immediate Mode Emulation for GL3

  10. #120
    Junior Member Newbie
    Join Date
    Mar 2010
    Posts
    14

    Re: Official feedback on OpenGL 4.0 thread

    @All: regarding stalls and glGet, I have observed directly via Shark that the OS X OpenGL implementation will stall on some glGets when the "threaded" driver is in use via a window-system enable. I have heard from my users that X-Plane performance is dreadful on NV drivers if the threaded driver is used, so I can only speculate that it's the same problem of a threaded driver stalling on a "get".

    It's not clear to me why the driver must stall, as these gets are for state set only from the client side, but OpenGL is a leaky abstraction...the spec never promises fast gets and it never promises slow ones either. :-)

    Quote Originally Posted by Ilian
    The gpu cmdstream is one. Wanting to magically push more and more via the old methods indefinitely won't work. So, look at the HW caps, and think out of the box.
    @Ilian: Fair enough...I can't argue with the hardware.

    Quote Originally Posted by Jan
    It is really a huge piece of rendering code that sets many different shaders, uniforms, binds textures, executes (instanced) drawcalls, etc.
    Ah. My "emulated display lists" took advantage of the fact that all of the OpenGL calls were going through only six calls into the lower levels of the rendering engine, so the culling code could simply accumulate these six calls as opcodes in a buffer and then run them later. It sounds like your app has code organization/architectural reasons why this won't work.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •