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 19 of 19

Thread: Best solution for dealing with multiple light types

  1. #11
    Member Regular Contributor
    Join Date
    Jul 2012
    Posts
    459
    Quote Originally Posted by Bram Ridder View Post
    GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS returns 32 as well. It is actually an AMD card: SAPPHIRE Radeon RX 580 NITRO+ 4 GB GDDR5.
    OK. I will try to try that as well on my side. Thank you.

  2. #12
    Junior Member Newbie
    Join Date
    Dec 2017
    Posts
    11
    Well, I just want to know what these values mean. Because it seems to me that I am going over these limits with the number of textures I use, yet everything works fine.

  3. #13
    Member Regular Contributor
    Join Date
    Jul 2012
    Posts
    459
    Well, these are depicted here.

    And for the combined, if both shader access the same unit, this is counted as 2.

    From what I know and what I understand, these should be hard limits, not hints. Reading the relevant parts of the spec might also give some clue.

  4. #14
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,571
    Quote Originally Posted by Bram Ridder View Post
    Quick update. I implemented some of your recommendations and I have successfully rendered a scene with 56 lights (including shadow maps)! I now use two UBOs, one for the view and projection matrix and the other for all the lighting information.
    Cool! Congrats on getting it up and running.

    I ran into an issue with having to many outs in my vertex shader so I moved all the calculation to the fragment shader (doing so somehow doubled my FPS ). While I am happy it works, it really shouldn't...
    That's interesting. A few thoughts: vertex shaders are executed for all vertices, not just all vertices 1) in the view frustum 2) which aren't occluded by any other objects (the latter for depth-tested geometry). I wonder if #1 and #2 might help explain the performance difference?

    Also, how many interpolators (varyings; aka vertex out/fragment in) were you using before versus now? I think I recall reading that the more of these you use, the fewer vertex shader threads can execute in parallel (on the same GPU), so the slower your vertex transform work executes. Not sure if that correlates with your problem though.

    As far as I understand I should have exceeded the sampler limit in the fragment shader (GL_MAX_TEXTURE_IMAGE_UNITS), but it just seems to work. Maybe you can help me figure out what is going on.
    Hmmm. 121 is certainly > 32 (your GL_MAX_TEXTURE_IMAGE_UNITS, which I believe is the bound texture access limit for fragment shaders). GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS is the limit across all shader units, and you're well under that. It sounds like GL_MAX_TEXTURE_IMAGE_UNITS isn't really the hard upper limit for fragment shaders (on your GL drivers at least), but it sounds like that's operating outside of the spec, so your code in general might not work on other such drivers where you're over-the-limit.

  5. #15
    Junior Member Newbie
    Join Date
    Dec 2017
    Posts
    11
    Quote Originally Posted by Dark Photon View Post
    Cool! Congrats on getting it up and running.
    Thanks .

    Quote Originally Posted by Dark Photon View Post
    Also, how many interpolators (varyings; aka vertex out/fragment in) were you using before versus now? I think I recall reading that the more of these you use, the fewer vertex shader threads can execute in parallel (on the same GPU), so the slower your vertex transform work executes. Not sure if that correlates with your problem though.
    I used to use 4 * #lights + 3, now I only use 5 or so. So thay might explain it. I even get the speedup with very simple scenes where all vertices are withing the frustrum and none of them are occluded.

    Quote Originally Posted by Dark Photon View Post
    Hmmm. 121 is certainly > 32 (your GL_MAX_TEXTURE_IMAGE_UNITS, which I believe is the bound texture access limit for fragment shaders). GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS is the limit across all shader units, and you're well under that. It sounds like GL_MAX_TEXTURE_IMAGE_UNITS isn't really the hard upper limit for fragment shaders (on your GL drivers at least), but it sounds like that's operating outside of the spec, so your code in general might not work on other such drivers where you're over-the-limit.
    Something must be going on in the driver. I was trying to break my shaders by pushing the number of lights higher and higher, but it never did. Even on a mobile NVIDEA GPU on my laptop it works fine.

    You are right though. I should stay within the specs and start using texture arrays or Atlas textures for my depth maps.

    Good to know I understand the limits and should be surprised .

  6. #16
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,571
    Quote Originally Posted by Bram Ridder View Post
    Something must be going on in the driver. I was trying to break my shaders by pushing the number of lights higher and higher, but it never did. Even on a mobile NVIDEA GPU on my laptop it works fine.
    Just out of curiousity, did you try using more than GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS?

    I don't know that that should break it, but it would confirm or refute that (on NVidia drivers at least) this is or isn't a hard upper limit.

    I really doubt that it is though because it seems that (on recent NVidia drivers) the value for this is always 5 times or 6 times the max number of texture per shader state (which you found is bogus). 5 is the number of shader stages w/o compute, and 6 is the number of shader stages with compute. For instance, on your card 32*5=160. Here on the NVidia card I was running on, 32*6=192. For the *6, no clue why they'd count compute as a stage in the shader pipeline, since it doesn't coexist with the others in a program (AFAIK).

    You are right though. I should stay within the specs and start using texture arrays or Atlas textures for my depth maps.
    Also check out Bindless Texture. For some cases, this is much more convenient than texture arrays. And both of these in my opinion have fewer drawbacks than texture atlases (unless you're targeting really, really old hardware).

  7. #17
    Member Regular Contributor
    Join Date
    Jul 2012
    Posts
    459
    With the same GC than the OP (AMD RX 580) I have almost the same parameters: 32, 32 and 192 (the last one for the combine), which look more like what Dark Photon found on its nVidia card.

    I use free drivers on Mesa / Linux here.

  8. #18
    Junior Member Newbie
    Join Date
    Dec 2017
    Posts
    11
    Quote Originally Posted by Dark Photon View Post
    Just out of curiousity, did you try using more than GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS?

    I don't know that that should break it, but it would confirm or refute that (on NVidia drivers at least) this is or isn't a hard upper limit.

    I really doubt that it is though because it seems that (on recent NVidia drivers) the value for this is always 5 times or 6 times the max number of texture per shader state (which you found is bogus). 5 is the number of shader stages w/o compute, and 6 is the number of shader stages with compute. For instance, on your card 32*5=160. Here on the NVidia card I was running on, 32*6=192. For the *6, no clue why they'd count compute as a stage in the shader pipeline, since it doesn't coexist with the others in a program (AFAIK).
    Yeah, if I go over that limit then it does break (tried 162 and got some crazy effects).

    Quote Originally Posted by Dark Photon View Post
    Also check out Bindless Texture. For some cases, this is much more convenient than texture arrays. And both of these in my opinion have fewer drawbacks than texture atlases (unless you're targeting really, really old hardware).
    Does the latest DOOM not use texture atlases for their depth maps? At this stage I do not know the pros and cons of these different ways of handling textures. But I will look into bindless textures, it seems to promise to be able to draw everything with one draw call which is kind of neat :P.

  9. #19
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,571
    Quote Originally Posted by Bram Ridder View Post
    Yeah, if I go over that limit then it does break (tried 162 and got some crazy effects).
    Interesting. Good to know.

    Does the latest DOOM not use texture atlases for their depth maps?
    No clue.

    But I will look into bindless textures, it seems to promise to be able to draw everything with one draw call which is kind of neat :P.
    Yeah, I'd just read the wiki page so you've got that in your back of tricks, and can pull it out if/when you determine that you need it.

Posting Permissions

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