Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 10 of 14

Thread: subroutines and multiple render targets

Threaded View

  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.

Posting Permissions

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