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 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: subroutines and multiple render targets

  1. #11
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Lack of vertex shader DOES produce an INVALID_OPERATION error at draw time in core profile.
    Does it?

    Quote Originally Posted by OpenGL 4.3, core profile, chapter 11
    If the current vertex stage program object has no vertex shader, or no program object is current for the vertex stage, the results of programmable vertex processing are undefined.
    It doesn't seem that way. Or if it does, the GL_INVALID_OPERATION must come from something else.

    Come on, if you don't have to run fragment shaders on the shader cores, more vertex shaders can be in flight at once. How wouldn't be that faster? Think about it.
    You're effectively alleging that shader compilers and implementations that are smart enough to inline functions, remove dead code, and various other optimizations are too stupid to optimize an empty fragment shader into the same thing as not having one. So as I said before, where is your evidence that any real systems will exhibit this performance difference?

    In short, show me the driver/compiler which cannot optimize away an empty fragment shader.

    Just create a core profile context, setup a vertex shader-only program, set draw buffers to none, attach a depth texture to your framebuffer and let it go. I bet you it will work.
    Yes, and so will this fragment shader:

    Code :
    #version 330
     
    out vec4 someColor;
     
    void main()
    {
      someColor = vec4(1.0f, 0.0f, 0.0f, 1.0f);
    }

    If you use this fragment shader without a call to glBindFragDataLocation, it will in virtually all cases assign `someColor` to output number 0. But the OpenGL standard does not require this behavior.

    My point is that the standard itself doesn't provide coverage for the behavior that you suggest it does, not whether or not it will "work" on some or even all implementations. You can rely on undefined behavior if you want, but you shouldn't suggest that others do so.

  2. #12
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Quote Originally Posted by Alfonse Reinheart View Post
    It doesn't seem that way. Or if it does, the GL_INVALID_OPERATION must come from something else.
    Okay, I admit I was wrong about this, in fact not having a vertex shader only makes the results of vertex processing undefined but doesn't generate an error. At least one of us can admit if he's wrong...
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  3. #13
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    The spec clearly states in chapter 14

    Quote Originally Posted by The Spec
    Thus, rasterizing a primitive consists of two parts. The first is to determine which squares of an integer grid in window coordinates are occupied by the primitive. The second is assigning a depth value and one or more color values to each such square. [..] The color values assigned to a fragment are determined by a fragment shader as defined in section 15. [..] The final depth value is initially determined by the rasterization operations and may be modified or replaced by a fragment shader.
    Furthermore, section 15.2 clearly states:

    Quote Originally Posted by The Spec
    Writing to gl_FragDepth specifies the depth value for the fragment being processed. If the active fragment shader does not statically assign a value to gl_-FragDepth, then the depth value generated during rasterization is used by subsequent stages of the pipeline.
    Now, I think there may be room for interpretation here, although I have to agree that such an important fact should be made clear as day. So here's mine: Depth values are initially defined during rasterization. If a fragment shader is active and writes to gl_FragDepth, then the value is modified and set to the specified new value. Furthermore, it has to do so statically, i.e. not base writing to gl_FragDepth on dynamic braching whatsoever. Otherwise, the initial value, produced during rasterization and not during fragment shading, is used. Not having a fragment shader, i.e. fragment shader execution leading to undefined results, automatically results in gl_FragDepth not being set and thus the rasterized depth value not being modified. The depth value is defined - after rasterization.

    In conclusion, I agree with aqnuep and I have yet to see a case where generating a correct depth map without a fragment shader has not worked cross-platform and cross-vendor and I have working examples of renderings on AMD, NVIDIA and Intel hardware.

    Furthermore, why on earth would the ARB mandate that a fragment shader be present to actually defined a valid depth value? What about depth pre-passes? Nobody gives a damn about fragment shader outs. What about occlusion queries? Fragment shading? Why? I think this would be an oversight no one in the ARB could justify.

  4. #14
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Thanks, thokra, for searching that for me. Apparently, I was doing lazy when trying to find the relevant spec statements.

    Another thing to note, which is actually related to the original question:

    While the driver may be able to optimize out an empty fragment shader, it cannot optimize out a shader that dynamically uniformly calls subroutines from which only a single subroutine is the one that doesn't emit any colors.

    In this particular case the driver cannot optimize out the fragment shader as the decision is done at run-time (even if the decision is dynamically uniform) thus you'll have to pay for the cost of fragment shader execution for sure.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

Posting Permissions

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