|
You have to use VAOs if you aren't using a profile that supports legacy stuff. I haven't tested whether they give a performance benefit, but I would assume so since they're basically removing the old way of doing it.
|
# ? Feb 25, 2012 08:53 |
|
|
# ? May 15, 2024 04:43 |
|
Contero posted:In gl 3.1+, do vertex array objects give a performance benefit over manually binding VBOs? What is the advantage of using them? You have to use VAO in GL 3+. In legacy contexts they should ideally provide a performance enhancement. However, most drivers don't implement them so that there's a noticable difference.
|
# ? Feb 26, 2012 06:51 |
|
OK, this one is kicking my rear end. At work we have an Open Inventor app we've had going back to the days when we used SGI hardware. I have to point out that we have always compiled our software into static archives and linked our executables against them. As a science project I'm trying to get them to link against .so versions of the same libraries. Now this app works perfectly fine linking against the static libraries. But when I link it against the shared objects, it crashes about 40 levels deep in the Inventor SoXt::mainLoop(). I've tracked the reason for the crash to a NULL returned by glGetString(GL_VENDOR). Google tells me that this is usually caused by not having a valid GL context at the point of the call. But I *think* there is one in this case, or at least, glXGetCurrent() returns something that appears reasonable; and as I said, it works fine when using the static libraries. So what's going on here? In both cases the code is identical, and it's using the same Inventor and GL libraries, but one way crashes and the other doesn't.
|
# ? Feb 27, 2012 05:52 |
|
Does glGetError() return anything useful after the glGetString() returns 0?
|
# ? Feb 27, 2012 07:07 |
|
pseudorandom name posted:Does glGetError() return anything useful after the glGetString() returns 0?
|
# ? Feb 27, 2012 22:13 |
|
Firstly, what has changed since it used to work? What OS, HW, driver, etc? Do other gl calls work? Can you clear the screen to a color? Can you draw a simple quad? Do other glGet* calls work? Can you call glGetString(GL_RENDERER) or GL_VERSION or GL_EXTENSIONS? Also it occurs to me that you may not be creating the context correctly in the dynamically linked case. How is the context created? Are you using glXGetProcAddress, etc? Does that return valid function pointers?
|
# ? Feb 28, 2012 07:19 |
|
Spite posted:Firstly, what has changed since it used to work? Nothing has changed. The only difference is linking .so versions of our libraries instead of the .a versions. quote:Do other gl calls work? I should point out that I have no idea how to do any of this. This app was written back in the Bronze Age. The big chunk of the display is an SoXtRenderArea. If I comment out the show() call for that object, the app no longer crashes; but then of course all I get is a black window. glGetCurrentContext() works. quote:Can you call glGetString(GL_RENDERER) or GL_VERSION or GL_EXTENSIONS? quote:Also it occurs to me that you may not be creating the context correctly in the dynamically linked case. How is the context created? Are you using glXGetProcAddress, etc? Does that return valid function pointers? EDIT: I removed all the children from the render area and replaced it all with a single SoCube object. It still crashes. Presto fucked around with this message at 19:28 on Feb 28, 2012 |
# ? Feb 28, 2012 17:59 |
|
Sounds like you don't have a context. I'm not sure why that would occur and I don't have much experience with xwin. Try calling glXGetProcAddress and seeing if it returns valid pointers. Where does the code create your context and how does it do so? Look for glCreateContext or glXCreateContext.
|
# ? Mar 1, 2012 07:46 |
|
Spite posted:Sounds like you don't have a context. I'm not sure why that would occur and I don't have much experience with xwin. The context is created in the Open Inventor code. I've put the glGetString call at that point, immediately after the context is created and made current, and it still returns NULL. I also found out that glGetIntegerv also doesn't work properly in the shared link case. For instance glGetIntegerv(GL_MAX_LIGHTS) returns a big negative number (something like -272716322) instead of the 8 it returns when it works. It's almost like some static memory in libGL.so isn't being initialized or something. I've also run the whole thing in valgrind and Insure++ and didn't turn up any smoking guns. Edit: What the poo poo? If I call the function through the pointer returned by glXGetProcAddress it works. Presto fucked around with this message at 00:06 on Mar 2, 2012 |
# ? Mar 1, 2012 23:39 |
|
Got the fucker. In the static link case, glXGetProcAddress("glGetString") and the address of the bare glGetString symbol returned the same pointer, but in the shared object care they didn't. I added a '-y glGetString' option to the link command, and it turned out that one of our local libraries requires OSMesa, and libOSMesa.so also defines a bunch of gl calls, and the symbols were being linked from there instead of from libGL. I moved the OSMesa library to the end of the link line and it's all good now. Thanks for the suggestions.
|
# ? Mar 2, 2012 01:43 |
|
That makes sense, the Mesa lib has its own GL implementation. Fun stuff.
|
# ? Mar 2, 2012 01:51 |
|
I got a question about GLSL Tesselation Shaders. I got some geometry that I'm rendering either as GL_Quads (through a vertex shader) or GL_PATCHES (through a vertex->tess control->tess eval shader chain). The VBO is exactly the same (same vertex definitions and indices). When I look at the wireframe of the GL_QUADS version of the geometry, it shows, as expected, quads. When I look at the wireframe of the GL_PATCHES version however, each quad is subdivided into two triangles. My tesselation control shader has layout(vertices=4) out, set at the top and my tesselation evaluation shader is set to layout(quads) in. Is there some way to work around this issue or am I stuck with looking at my quads with a line in the middle (I'm asking cause I want to make figures for a paper I'm writing and having to explain that "I swear I'm issuing 4-vertex patches to teh GPU instead of two triangles" might not jive very well...).
|
# ? Mar 11, 2012 18:46 |
|
Are const arrays inside shader code supposed to be blatantly slow? I have a tessellation control shader that needs to index the vertices of the input primitive based on the invocation ID (so gl_InvocationID == 0 means that the TCS operates on the edge of gl_in[0] and gl_in[1], etc). Initially, my code had an if-statement (which I would assume GPUs don't like that much when it diverges inside the same execution unit) to make this determination. I figured that I could flatten the vertex indices out into a single const int[8] and index them based on the invocation ID (so I could say indices[glInvocationID * 2] and indices[glInvocationID * 2 + 1] and get the stuff that I need). However, doing this seems to hit me with a 66% performance drop when compared to using if-statements! Would passing the index array as a uniform yield a performance benefit?
|
# ? Mar 19, 2012 22:55 |
|
shodanjr_gr posted:Are const arrays inside shader code supposed to be blatantly slow? What graphics card are you seeing this with? Depending on the hardware, the problem probably isn't the const array, but the fact that you are using dynamic indexing into the array. Some GPUs don't really support base+offset indexing, instead mimicing it using registers. Unfortunately, if you index the arrays dynamically, this requires all the accesses to be expanded (either by unrolling loops, or expanding into a giant nasty set of branches). So you could actually be gaining MORE branches, instead of eliminating them. Why do you need to index the edges like you are doing? Your best bet would be to structure the input to your shader so that it doesn't need to branch at all, even if that means just adding extra interpolants. I'm not sure if that would work for you here, though. e: There's no way to see intermediate assembly with GLSL, right? For DirectX, you could use FXC to dump the shader which might show you if that were happening at the high-level level (though not if it's being introduced at the machine-code translation stage). Hubis fucked around with this message at 14:51 on Mar 20, 2012 |
# ? Mar 20, 2012 11:54 |
|
Hubis posted:What graphics card are you seeing this with? Depending on the hardware, the problem probably isn't the const array, but the fact that you are using dynamic indexing into the array. Some GPUs don't really support base+offset indexing, instead mimicing it using registers. Unfortunately, if you index the arrays dynamically, this requires all the accesses to be expanded (either by unrolling loops, or expanding into a giant nasty set of branches). So you could actually be gaining MORE branches, instead of eliminating them. This is on a Quadro 5000. quote:Why do you need to index the edges like you are doing? Your best bet would be to structure the input to your shader so that it doesn't need to branch at all, even if that means just adding extra interpolants. I'm not sure if that would work for you here, though. quote:e: There's no way to see intermediate assembly with GLSL, right? For DirectX, you could use FXC to dump the shader which might show you if that were happening at the high-level level (though not if it's being introduced at the machine-code translation stage). I believe there are utilities released by AMD/NVIDIA that will compile GLSL down to the machine-level assembly for you....
|
# ? Mar 20, 2012 15:16 |
|
AMD has ShaderAnalyzer, which shows you the assembly dump and cycles for any card they make. NVIDIA, I'm not sure, I've heard there's a way to make CGC do something like that.
|
# ? Mar 20, 2012 15:23 |
|
shodanjr_gr posted:This is on a Quadro 5000. E: Nevermind, thanks! Hubis fucked around with this message at 21:50 on Mar 20, 2012 |
# ? Mar 20, 2012 20:44 |
|
Also are you sure the Quadro actually implements the Tesselation Shaders in hardware? Sometimes they don't have full implementations. Or they fall back to software for stupid reasons.
|
# ? Mar 21, 2012 01:59 |
|
Remind me what the Quadro and Fire are better at doing than the consumer cards again?
|
# ? Mar 21, 2012 15:49 |
|
OneEightHundred posted:Remind me what the Quadro and Fire are better at doing than the consumer cards again? Increasing profit margins? They used to be better at line and other base primitive drawing, for wireframe cad application; not sure if that's true anymore.
|
# ? Mar 21, 2012 15:52 |
|
OneEightHundred posted:Remind me what the Quadro and Fire are better at doing than the consumer cards again? OpenGL 1.0, mostly. And antialiased line rendering.
|
# ? Mar 21, 2012 16:01 |
|
Unormal posted:They used to be better at line and other base primitive drawing, for wireframe cad application; not sure if that's true anymore. I think they generally are. It's all in the drivers though, with similar if not identical hardware behind them (possibly with huge gobs of RAM added). Basically, you're paying for a support agreement, and driver optimizations for non-consumer tasks. The payment just gets tacked onto the hardware purchase instead a driver subscription fee or however else it might be done.
|
# ? Mar 21, 2012 16:32 |
|
OneEightHundred posted:Remind me what the Quadro and Fire are better at doing than the consumer cards again? Higher quality bins of chips, much better handling of geometry-heavy scenes (not just lots of triangles, but lots of small triangles), and the driver and technical support commensurate with a workstation-level GPU (not just perf, but some weird/edge-case features that don't matter much for consumers but might for a professional system).
|
# ? Mar 21, 2012 16:52 |
|
Hubis posted:Higher quality bins of chips, much better handling of geometry-heavy scenes (not just lots of triangles, but lots of small triangles), and the driver and technical support commensurate with a workstation-level GPU (not just perf, but some weird/edge-case features that don't matter much for consumers but might for a professional system). That's very true. I work at a research University and I've been able to ping both NVIDIA and AMD engineers regarding weird behaviors/driver issues/optimizations with their professional level cards. I assume that if you are buying geforce/radeon you can't really call em up and say "Why do the textures in Rage look like crap? send me a custom driver that fixes this!".
|
# ? Mar 21, 2012 23:25 |
|
Pretty much. Margins on the consumer products are enough to pay for someone to recite a script to you, and not much more. It's going to cost a lot more if you want to talk to someone who even understands what you're saying, much less getting engineer time.
|
# ? Mar 21, 2012 23:46 |
|
I have a world defined as a bunch of polygon meshes and I'm using VBOs at the moment to render them. Currently the setup iscode:
The thing with that is that the lighting is baked in and static, and I want to move on to dynamic lighting. Is there a way to accomplish that through loading the vbo -> *doing something where dynamic light values get added* -> DrawArrays? Or have I hit the limitation of rendering that way there? If so, where would I go next from there? Is the next thing to do it all in shaders or is there some kind of intermediate step? Something with a deferred lighting pass maybe? I've learnt a ton of stuff doing things this way that I'd sort of handwaved over before.
|
# ? Mar 26, 2012 11:37 |
|
HauntedRobot posted:I have a world defined as a bunch of polygon meshes and I'm using VBOs at the moment to render them. Currently the setup is If you want to still use VBOs with dynamic lighting instead of shaders, you could put the color values into another VBO and modify them each frame: code:
|
# ? Mar 26, 2012 14:44 |
|
HiriseSoftware posted:If you want to still use VBOs with dynamic lighting instead of shaders, you could put the color values into another VBO and modify them each frame: Oh, that's a pretty good idea. Disentangling them from the other vertex info isn't ideal, but I already have a similar thing in the loader for generating a simplified collision mesh for the physics.
|
# ? Mar 26, 2012 16:09 |
|
I know that binding things in opengl is fairly expensive thing to do and you should try to minimise the amount of times it is called per frame. If something such as a buffer, texture, shader etc is already bound then how much is the performance hit if it is bound again? Is there a way to check what is currently bound, and if so how expensive is that compared to blindly rebinding something?
|
# ? Apr 6, 2012 16:37 |
|
FlyingDodo posted:I know that binding things in opengl is fairly expensive thing to do and you should try to minimise the amount of times it is called per frame. If something such as a buffer, texture, shader etc is already bound then how much is the performance hit if it is bound again? Is there a way to check what is currently bound, and if so how expensive is that compared to blindly rebinding something? You can use the glGet* functions to get the currently bound object for a particular type, for example: code:
Edit: Make sure you do an initial "OpenGL state reset" to get the GL state machine to match up to your initial state array values. HiriseSoftware fucked around with this message at 16:57 on Apr 6, 2012 |
# ? Apr 6, 2012 16:54 |
|
How do OpenGL versions map to DirectX versions in terms of hardware requirements? For example, if I can target DirectX 9.0c, what OpenGL versions do I have to work with?
|
# ? Apr 22, 2012 20:46 |
|
Zilla32167 posted:How do OpenGL versions map to DirectX versions in terms of hardware requirements? For example, if I can target DirectX 9.0c, what OpenGL versions do I have to work with? DirectX 9.0c came out in August 2004, and OpenGL 2.0 came out in September 2004. Cards that came out late 2004 and early 2005 might have support for one but not the other, though.
|
# ? Apr 22, 2012 21:47 |
|
It depends what features you're looking for, a lot of the time some chunk of them will make it in early and others later. Geometry shaders are a 3.2 standard feature but were an extension before that for example. 9.0c should work with pretty much anything that has GLSL support since gl_FrontFacing has existed since day one and the rest of the SM3.0 features are compiler-level.
|
# ? Apr 23, 2012 20:45 |
|
I have a bunch of concave contours whose vertices rest on the surface of a sphere. I want to draw them, filled with color, on that sphere. I was thinking that I could take points from a tessellation of the sphere, calculate the Delaunay triangulation over all of these points and the vertices of my contours, and render that. Is there a simpler way to do this? Sorry if this is a silly question, I haven't worked much in 3D edit: I guess I also need to determine which of the points from the tessellation are inside which contours (for coloring purposes), but it seems like I could do some spherical analogue of a point in polygon test? a slime fucked around with this message at 00:42 on Apr 25, 2012 |
# ? Apr 25, 2012 00:35 |
|
Getting away from DirectX/OpenGL for a moment, does anyone have experience with Nvidia's Optix realtime raycasting? I have used it to create simple tests and it seemed to perform OK at low resolution, eg 1024x768 on some average hardware (GTX 560 Ti & Intel i7 Bloomfield 2.9 Ghz). But I wonder how it performs in real world applications? Youtube has dozens of tech demo's but almost nothing in the way of real applications using the library. It would be nice to know I am not wasting my time before I invest heaps of it coding the CUDA programs and a scene graph and managing GPU paging and all the other related parts. All that is necessary as Optix is just a raycasting library only, it is not a complete scene management solution like Nvidia's SceniX which I do not wish to use for various reasons. Any experiences people can share about Optix would be helpful.
|
# ? Apr 27, 2012 02:22 |
|
Stragen posted:Getting away from DirectX/OpenGL for a moment, does anyone have experience with Nvidia's Optix realtime raycasting? I don't know anything about it, but I'm going to be that guy that points out smugly that ray casting != ray tracing.
|
# ? Apr 27, 2012 04:10 |
|
Heh yeah, I always get them the wrong way around. I meant ray tracing.
|
# ? Apr 27, 2012 06:07 |
|
Stragen posted:Getting away from DirectX/OpenGL for a moment, does anyone have experience with Nvidia's Optix realtime raycasting? It depends a lot on your ultimate use-case. How dynamic is your scene? What's your scene complexity? What light transport/shading technique are you using -- Primary + Shadow, or full path tracing? For a 560 Ti, I wouldn't expect to be ray-tracing Crysis or anything. Since performance depends a lot on acceleration structures (which have to be updated when the scene changes) which structures you use for which objects in the hierarchy and how often they need to change will end up impacting your performance a lot. There's more information here, although it's obviously based on somewhat older hardware: http://graphics.cs.williams.edu/papers/OptiXSIGGRAPH10/Parker10OptiX.pdf
|
# ? Apr 27, 2012 16:16 |
|
Hubis posted:It depends a lot on your ultimate use-case. How dynamic is your scene? What's your scene complexity? What light transport/shading technique are you using -- Primary + Shadow, or full path tracing? For a 560 Ti, I wouldn't expect to be ray-tracing Crysis or anything. Since performance depends a lot on acceleration structures (which have to be updated when the scene changes) which structures you use for which objects in the hierarchy and how often they need to change will end up impacting your performance a lot. I'd like to use static, semi-dynamic and full-dynamic geometry using Sbvh, Bvh and Lbvh accel structures respectively. I only plan to use simple Whitted raytracing, so just usual radiance + shadow casts and probably some limited use of reflection/refraction. My plan is to divide the scene into sections which will contain a static hull and be connected via portals. So attached to the Optix root node would be a series of Selector nodes which only continue traversing if the section ID stored in the ray payload & selector node match. Portals would just alter the payload section ID and re-cast from root. I am hoping that keeping the scene divided into small sections will make calculating Bvh and Lbvh fast enough to be done in real-time, but haven't tested it yet. Also this should make paging fairly easy. I am just worried that checking N selector nodes each time casting from a portal might lower the framerate, not to mention the recursive casting required for portals. If Optix 2.5 GPU-side calculation of Lbvh is fast enough, I am wondering if I would get a better framerate just using a single volume hierarchy for the entire scene instead of sections & portals. That is to say, 3 volume hierarchies, one for each geometry type. I guess it will depend a lot how many sections there are in the scene and positioning of the portals themselves. I have only tested Optix using Bvh accel on a very small fully dynamic scene, so I am not certain how well portals would work. DefiniteIntegral fucked around with this message at 17:12 on Apr 27, 2012 |
# ? Apr 27, 2012 17:07 |
|
|
# ? May 15, 2024 04:43 |
|
I need to implement shadow mapping for the last part of a class project, and I totally understand it except for one thing. How do you create the frustum / projection+view matrices for the light source so that it covers everything in the camera's frustum? Everything I read seems to just skip over this.
|
# ? May 3, 2012 16:10 |