Jump to content
  • Advertisement

JohnHardy

Member
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

100 Neutral

About JohnHardy

  • Rank
    Newbie

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. JohnHardy

    OpenGL Large Texture Multiple Monitors

    Thanks! Is there any literature on the differences WebGL Vs OpenGl overhead for large texture sampling?
  2. JohnHardy

    OpenGL Large Texture Multiple Monitors

    Yea it's the same image for each rendering/window. At this stage it can be a single process if it's beneficial (although it may be harder to code?). Is there a perf benefit or will I see the same sampling speed? I've knocked up a WebGL prototype in THREEJS and I was wondering if doing it natively will improve performance. Thanks for your help!
  3. Hello! I am writing an multi-window application that does some data vis on many 4K monitors. My challenge is that, on each monitor, I need to sample from a massive texture (shared between the windows) as a efficiently as possible. Luckily, it just fits under the resolution limit. However, I don't know the best way to configure OpenGL for best performance in this situation and could use some pointers. My current thinking is that the best bet is to avoid loading the texture 4 times (saving GPU memory and possibly some cache benefits?), render 4 separate windows, and then share the context between them. I only have a single draw call per window (a large almost-full-screen plane). I guess my questions are: Is there actually a performance benefit to doing this, or is it just a memory saving? Is there a way to just share the texture rather than work in a single context? Is this better / worse? Does it matter that the monitors may be plugged in / unplugged during run-time and would that mean I have to re-create the context or can I create a context without it being tied to a monitor? Thanks!
  4. JohnHardy

    Expert advice about render order

    Thanks for your reply! Why is changing a shader so expensive? Is it clearing all the caches' and video memory? As for what I am defining as a pass: technique SomeTechnique { pass p0 { ...blah... VertexShader = compile vs_3_0 VS_Model(); PixelShader = compile ps_3_0 PS_Model(); } pass p1 { ...blah... VertexShader = compile vs_3_0 VS_Model(); PixelShader = compile ps_3_0 PS_Detail(); } } [font="courier new"][size="1"][font="arial, verdana, tahoma, sans-serif"] [/font][/font] In this case, p0 and p1 are the different passes within the same technique. Does this change your answer?
  5. Hey Folks, I have a question about how to optimally draw things in light of how the video driver works. I had a quick poke around and found a few conflicting examples (most are suited to cases where scalability is not a denominating issue) so figured this would be a good place for a definitive answer. In our game we are using lots of models in the same scene which have large texture files and high poly meshes - enough to fill the texture memory of most cards. Should we draw them like this: Method A: Begin() BeginPass(1) RenderModelA_TextureA RenderModelA_TextureB RenderModelB_TextureA RenderModelB_TextureB BeginPass(2) RenderModelA_TextureA RenderModelA_TextureB RenderModelB_TextureA RenderModelB_TextureB End() or Method B: Begin() BeginPass(1) RenderModelA_TextureA BeginPass(2) RenderModelA_TextureA BeginPass(1) RenderModelA_TextureB BeginPass(2) RenderModelA_TextureB BeginPass(1) RenderModelB_TextureA BeginPass(2) RenderModelB_TextureA BeginPass(1) RenderModelB_TextureB BeginPass(2) RenderModelB_TextureB End() My current feeling is that Method B will be best since seems cheaper to change a pointer in the shaders than it is to hit a cache limit and end up sending another 2048x2048x32x5 texture set to the card. However the other argument is that once it is in memory, we cannot really code for the caching policy and at by changing the texture set we are just effectively swapping pointers and there is no large data transfer going on - this suggests we should avoid the render state switches instead. Looking forward to hearing what your answers are! Best, John
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!