Welcome to the Oculus Developer Forums!

Your participation on the forum is subject to the Oculus Code of Conduct.

In general, please be respectful and kind. If you violate the Oculus Code of Conduct, your access to the developer forums may be revoked at the discretion of Oculus staff.

Using gl_ViewID_OVR in fragment shader - strange bugs

kwuerlkwuerl Posts: 4
NerveGear
I am experiencing some very strange bugs while trying to use gl_ViewID_OVR in an opengl es 3 fragment shader.
As soon as I use more than one input (in) and gl_ViewID_OVR in the fragment shader the glLinkProgram() function simply deadlocks !?!
When i try to work around this by setting gl_ViewID_OVR in the vertex shader as an flat uint out, the shader compiles but the screen just flickers and produces strange artifacts....
One can reproduce this by simply adding a few lines to the VrCubeWorld NativeSurface example:
Just replace the shade code in the example by the one provided by shaders_bug.txt
My test devices where S7 Edge and S7.

Does anybody see if I'm doing something wrong here or if this is a bug in the driver?
And if it is - is there a better place to report this than in this forum?

Comments

  • deftwaredeftware Posts: 83
    Hiro Protagonist
    According to: https://www.khronos.org/registry/OpenGL/extensions/OVR/OVR_multiview.txt

    It's only supposed to be used in the vertex shader.

    It's also likely that it's not exactly a variable that you can copy out to the fragment shader as well. Although this seems like it would be an implementation-specific thing that some hardware vendors and/or drivers have just hacked in there.
  • deftwaredeftware Posts: 83
    Hiro Protagonist
    Ah:
    In this mode there are several restrictions:
    
            - in vertex shader gl_Position is the only output that can depend on
              gl_ViewID_OVR (see Section 7.1 of the OpenGL ES Shading Language
              specification)

    This would imply that nowhere else would you be able to set any variables using its value.


  • kwuerlkwuerl Posts: 4
    NerveGear
    Maybe i should mention that i use the OVR_multiview2 extension, so at least passing the variable from vertex to fragment shader should work:
    https://www.khronos.org/registry/OpenGL/extensions/OVR/OVR_multiview2.txt
    This extension relaxes the restriction in OVR_multiview that only gl_Position
    can depend on ViewID in the vertex shader.  With this change, view-dependent
    outputs like reflection vectors and similar are allowed.
    
    Nevertheless  gl_ViewID_OVR should be visible in fragment shader also:
    https://www.khronos.org/registry/OpenGL/extensions/OVR/OVR_multiview.txt
    (6) Is gl_ViewID_OVR visible at every pipeline stage?
    
        Resolved: To make integration simple for app developers, the intent is for
        gl_ViewID_OVR to be visible as a built-in at each programmable pipeline stage.
    It is not quite clear if fragment shader output can be dependent on gl_ViewID_OVR or not - i gess it should be in multiview2, as it lifts the dependency restriction...
    https://www.khronos.org/registry/OpenGL/extensions/OVR/OVR_multiview.txt
    For non-VTG stages (eg compute and fragment) which don't have a
        gl_Position output variable this means that no outputs can depend
        on the gl_VIewID_OVR. It is still possible that shader side effects
        (such as image or buffer stores) could be view-dependent.
    Btw: i found a really really ugly workaround that allows me to pass the viewid to the fragment shader:
    This is the only way this seems to work reliable without random artifacts or strange flickering.
    In vertex shader:
    ...
    flat out float V_VIEW_ID;
    ....
    void main() {
    ...
    V_VIEW_ID = (float(VIEW_ID) > 0.5 ? 1.0 : 0.0);
    ...
    }
    In fragment shader:
    ...
    flat in float V_VIEW_ID;
    ...
    void main() {
    ...
    int VIEW_ID = V_VIEW_ID > 0.5 ? 1 : 0;
    ...
    }
    
    The thing is: At least some of this does not work as intended. I was hoping some Oculus guy could maybe look over this.
  • deftwaredeftware Posts: 83
    Hiro Protagonist
    edited October 2017
     [ DELETED ]
     Doh, I just repeated what you already found.
  • kwuerlkwuerl Posts: 4
    NerveGear
    Thank you for your support so far!
    All our test devices have Android N - 7.0.
    But we use SDK version 23 to build.


  • WadeWattsWadeWatts Posts: 60
    Hiro Protagonist
    Did this get resolved? We are running into the same problem?
Sign In or Register to comment.