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 4 FirstFirst 1234 LastLast
Results 11 to 20 of 36

Thread: NVIDIA releases OpenGL 4.4 beta drivers

  1. #11
    Intern Contributor
    Join Date
    Mar 2010
    Posts
    59
    Quote Originally Posted by oscarbg View Post
    This bug is still present on OGL 4.4 beta drivers:
    http://www.opengl.org/discussion_boa...73#post1253473
    Also on a Fermi GPU I see

    and that's a bug as bindless ext is Kerpler only right?
    Sorry, I was unaware of the compute compiler bug until now. I was able to reproduce it and will investigate the issue.

    With regards to NV_bindless_multi_draw_indirect, that should work fine on Fermi. It's only "bindless texture" that requires Kepler.

  2. #12
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,144
    326.29 does not allow swap interval control from the code. While WGL_EXT_swap_control extension is properly listed, (PFNWGLSWAPINTERVALEXTPROC)wglGetProcAddress("wglSwapIntervalEXT") returns NULL. Vsync can be turned on/off from the control panel, so only problem is in returning function address.

  3. #13
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293
    Hi,
    I ran into a quite serious bug with the OpenGL 4.4 beta driver which I was able to reproduce with _all_ 326.x drivers available from the NV website.

    I have a fragment shader which is doing some quite complex things (ray casting a height field). I have these things wrapped into a nice function so the shader does look something like this (broken down to illustrate issue):

    Code :
    #version 420 core
     
    #extension GL_ARB_shading_language_include : require
     
     
    #include </scm/data/horizon/ray_cast.glslh>
    #include </scm/data/horizon/ray_cast/uniforms.glslh>
     
     
    // input/output definitions ///////////////////////////////////////////////////////////////////////
    in per_vertex {
       [...]
    } v_in;
     
     
    // attribute layout definitions ///////////////////////////////////////////////////////////////////
    layout(location = 0, index = 0) out vec4 out_color;
    //layout(depth_any)               out float gl_FragDepth;
     
     
    // implementation /////////////////////////////////////////////////////////////////////////////////
    void main()
    {
        out_color.rgba = vec4(1.0, 0.0, 0.0, 1.0);
     
        ray_cast_something(ray_cast_restult);
     
        //if (ray_cast_restult._t > -1.0) {
        // [...] output something from the result
        // } 
     
     
        out_color.rgb = vec4(0.0, 0.0, 1.0, 1.0);
    }

    The problem I have is that where the ray does hit a surface I get red color and everywhere else blue. However, with this shader code I should get blue everywhere.

    The problem seems to be that the shader is terminating the ray casting function but is not returning control to the main function somehow. I know that the function is working because I write per-pixel feedback into texture images (image load store) and I can see the intersection results are fine. I tried to break down the ray casting function to get it to return some debug values. However everything I tried failed to get control back in the main function to write even just a plain color. To rule out blending or depth testing these options were disabled.

    With driver versions up the the 326+ line everything worked as expected and understandable.

  4. #14
    Intern Contributor
    Join Date
    Mar 2010
    Posts
    59
    Quote Originally Posted by Aleksandar View Post
    326.29 does not allow swap interval control from the code. While WGL_EXT_swap_control extension is properly listed, (PFNWGLSWAPINTERVALEXTPROC)wglGetProcAddress("wglSwapIntervalEXT") returns NULL. Vsync can be turned on/off from the control panel, so only problem is in returning function address.
    I was not able to reproduce this. wglGetProcAddress("wglSwapIntervalEXT") seems to return a non-NULL pointer for me. What GPU are you using?

  5. #15
    Intern Contributor
    Join Date
    Mar 2010
    Posts
    59
    We have published an updated version of the Windows OpenGL 4.4 beta drivers to version 326.58. You can download it from the usual place:
    https://developer.nvidia.com/opengl-driver

    This update fixes the following bugs reported in this forum thread:
    Comment #8: Error C3008: unknown layout specifier 'patch'
    Comment #10: Access to matrix member of an SSBO

    Also fixed:
    Uses of samples in structs and the "uniform" keyword
    Fix some bugs with ARB_sparse_texture on XP

  6. #16
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293
    Quote Originally Posted by Piers Daniell View Post
    We have published an updated version of the Windows OpenGL 4.4 beta drivers to version 326.58. You can download it from the usual place:
    https://developer.nvidia.com/opengl-driver

    This update fixes the following bugs reported in this forum thread:
    Uses of samples in structs and the "uniform" keyword
    What does this refer to?

    I did a lot of changes in my project to remove samplers from structs (strictly used as uniform) after testing the OpenGL 4.4 beta driver. After reading the spec it seemed as that this was 'more' clarified in the current GLSL spec as when i implemented it first and samplers were somewhat allowed in uniform structs. Is this allowed again? Is this behavior conformant to the spec? It seems a bit of a grey area...

  7. #17
    Intern Contributor
    Join Date
    Mar 2010
    Posts
    59
    Quote Originally Posted by Chris Lux View Post
    What does this refer to?

    I did a lot of changes in my project to remove samplers from structs (strictly used as uniform) after testing the OpenGL 4.4 beta driver. After reading the spec it seemed as that this was 'more' clarified in the current GLSL spec as when i implemented it first and samplers were somewhat allowed in uniform structs. Is this allowed again? Is this behavior conformant to the spec? It seems a bit of a grey area...
    The OpenGL 4.4 beta driver had a regression where we became too restrictive with samplers in structs. Basically the spec, in the absence of bindless texture, only allows samplers to be declared as part of a uniform-qualified variable. However, there is no restriction that the sampler can't be in a struct which is declared as a uniform-qualified variable. The bug we fixed is that we forbid this by mistake, where in previous drivers we allowed it.

    Here are some examples:
    uniform sampler2D tex; // legal

    struct S {
    uniform sampler2D tex; // illegal to put "uniform" in struct
    };

    struct S {
    sampler2D tex; // legal
    };
    S foo; // illegal - "samplers" must be uniform
    uniform S bar; // legal - the sampler in S is now part of a uniform-qualified variable (the bug we fixed between 326.29 and 326.58 is to allow this)

    uniform Buffer {
    sampler2D tex; // illegal - without bindless texture this is not allowed
    };

    Hope that helps.

  8. #18
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293
    Quote Originally Posted by Piers Daniell View Post
    The OpenGL 4.4 beta driver had a regression where we became too restrictive with samplers in structs. Basically the spec, in the absence of bindless texture, only allows samplers to be declared as part of a uniform-qualified variable. However, there is no restriction that the sampler can't be in a struct which is declared as a uniform-qualified variable. The bug we fixed is that we forbid this by mistake, where in previous drivers we allowed it.

    Here are some examples:
    uniform sampler2D tex; // legal

    struct S {
    uniform sampler2D tex; // illegal to put "uniform" in struct
    };

    struct S {
    sampler2D tex; // legal
    };
    S foo; // illegal - "samplers" must be uniform
    uniform S bar; // legal - the sampler in S is now part of a uniform-qualified variable (the bug we fixed between 326.29 and 326.58 is to allow this)

    uniform Buffer {
    sampler2D tex; // illegal - without bindless texture this is not allowed
    };

    Hope that helps.
    Thanks for the clarification.

    However, does the spec really allow this. I read the part about opaque and sampler types and it seems to be quite picky about these types, where and how they can be declared. I mean it is really useful, but is it legal according to the spec?

    -chris

  9. #19
    Intern Contributor
    Join Date
    Mar 2010
    Posts
    59
    Yes, the GLSL spec allows this. I confirmed with the spec editor. This sentence on page 27 of the GLSL 440 spec:
    They [opaque values] can only be declared as function parameters or uniform-qualified variables.

    doesn't just mean basic-type variables, it means any variable, including structs.

  10. #20
    Intern Newbie
    Join Date
    Oct 2007
    Posts
    47
    Quote Originally Posted by Piers Daniell View Post
    Yes, the GLSL spec allows this. I confirmed with the spec editor. This sentence on page 27 of the GLSL 440 spec:
    They [opaque values] can only be declared as function parameters or uniform-qualified variables.

    doesn't just mean basic-type variables, it means any variable, including structs.
    Thanks for this fast bug fixing!
    Now some questions hope you can answer some of them:
    I found references about NVX_shader_thread_group and NVX_shader_thread_shuffle and on twitter Pat Brown said that he thought were already implemented on driver.
    Are specs coming soon jointly for also new
    WGL_NV_delay_before_swap extension?

    Release notes of new 325 drivers mention TXAA support on OpenGL.. I obtained TXAA SDK (v2.1) contacting Lottes.. question is if TXAA on OpenGL is already present for Linux 325 driver or Windows driver only?.. if Linux support is present I would like to test but my TXAA SDK libs aren't compiled for Linux..
    Also we get now GL_NVX_nvenc_interop extension reported but current NVENC 2.0 SDK June 2013 release on web doesn't mention support yet for NVENC encoding from OGL buffers/texes (only CUDA pointers and DX support presently).. any clue?

    Latest Intel drivers seems to ship with new exts:
    GL_INTEL_fragment_shader_span_sharing
    Lottes commented "
    GL_INTEL_fragment_shader_span_sharing might be sharing across the threads in a 2x2 pixel quad?"
    Eric Penner's “Shader Amortization using Pixel Quad Message Passing" (Gpu Pro 2) talks about some usage cases
    In case Fermi/Kepler HW supports that is NV interested on implementing/exposing this functionality..
    GL_INTEL_compute_shader_lane_shift
    That also seems like new warp SHUFL intrustion in PTX parlance in Kepler might NV also expose that?

    thanks..

Posting Permissions

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