Learning all of this seems all well and good, but why do I get the feeling it will all be nearly useless knowledge 6 months to a year from now? I'm probably being cynical, but that feeling makes me reluctant to really dive into this, particularly for hobby work. If I was getting paid big bucks to know this stuff, that'd be different 8^)
-Casey On Fri, Dec 3, 2010 at 4:20 AM, Florian Bösch <[email protected]> wrote: > On Dec 2, 3:16 pm, Jonathan Hartley <[email protected]> wrote: >> I think the ideas touched on above (moving from arrays to VBOs, using >> VAOs) plus using interleaved arrays, are all taking me in the >> direction you suggest, yes? > More or less, but there's a bit more to it. > >> I'm just doing one call to glDrawElements for each modelview transform >> change in my scene. Presumably after I've done all of the above, this >> should be my next target - to put all my object orientations and >> positions into a big dynamic VBO (as matrices?) and having the shader >> transform vertices right from object space to eye space. At that point >> my entire scene could be rendered with a single call to >> glDrawElements. Presumably this sort of thing is the logical >> conclusion of the direction you are recommending? > > Generally the idea of all this new stuff in OpenGL is to avoid per > frame bus transfer. You typically have something on the order of 0.5GB > - 1.5GB of free transfer capacity on the bus when the system is under > load (this is because the transfer from main memory to the CPU also > blocks time until you can put the data back on the bus again). Usually > you want more then 60 FPS rendering. If you divide your spare capacity > by the frames per second you get to between 10MB-25MB per frame! > That's not a whole lot, if you push it you might get to 50MB per > frame, but that's it, even very high end systems won't let you put > more then 3GB/s on the bus when not idle. 50MB is very little data > when when you talk of graphics. Often the geometry you want to render > alone occupies a couple hundred megabytes. > > Graphics cards these days are practically their own (super) computer. > They have their own backplane/bus (typically at clock rates and bit- > widths far exceeding PCI), they have their own high speed memory > (VRAM) and they have their own processors (the GPU cores). So the > solution to avoid CPU<->GPU bus transfer per frame is to preload as > much of your data as you can onto VRAM. To facilitate this there are a > variety of buffers for different purpose (altough they tend to become > general purpose buffers). > > There are different buffer concepts, they do not necessarily map to a > specific function, but more to a concept of how to use these > functions. > > Texture: This is the oldest buffer of all, it has its own API and you > use it to put a chunk of texture data into VRAM. The reason it's old > is because classically textures where the bus bottleneck (before we > did the geometry explosion of the 1995-2000 ties) > - VBO: Stands for vertex buffer object. The idea is to preload > (possibly generic buffers) with the data you want, and at frame render > time bind these buffers and issue the draw calls (which are the same > as for unbuffered array rendering). The difference is in what OpenGL > does when you do this. It uses its own VRAM location of the data > instead of waiting for the data to arrive on the bus. > - FBO: Framebuffer Object: This buffer became necessary because it is > desirable to capture rasterized output into a texture for various post- > processing/computing effects, and not be restricted to screen > dimensions. It has its own API and is less of a buffer then a way to > render into textures. > - PBO: Pixel buffer Object: Very similar to VBOs, but uses a different > enumerant (GL_PIXEL_PACK_BUFFER_ARB). On ATI card you can use a PBO as > a texture (or framebuffer attachment). On NVIDIA cards you can use it > to copy texture data into that buffer. This is useful for a technique > labeled RTVBO (render to vertex buffer object). It's a way to get > rasterizing stage calculations into a geometry containing buffer. > - VAO: Vertex Array Object: similar to the FBO it does not represent > its own buffer, but rather is a state definition binding a variety of > OpenGL state together and setting it with one bind call. It's > generally not as useful as the other buffers, with one exception, if > you issue a lot of draw calls, it can save quite a bit of time (that > is because presumably the driver can optimize changing its state > better then you can issue the individual state changes). > - TFO: Transform Feedback Object: This stands for its own data, it > does have its own API. The idea of this buffer is to be able to > capture geometry *before* it is rasterized (just before the fragment > shader) into a buffer (and count how many primitives where captured). > This is useful for a variety of computation that happens at the > geometry stages that you either want to perform at less frequencies > then per frame, or that you have some results you reuse in the same > frame in a second geometry pass. > Uniform Buffers: This kind of buffer allows you to pass a uniform > array of values into a shader without incuring bus transfer, the > values for the uniform live in VRAM > > I think you can see the common theme of this jungle of buffers. Avoid > per frame cpu work and bus transfer. There was some work from the > superbuffers group at Khronos to unify all that into a single buffer/ > API, but it didn't get trough yet (or perhaps never will). > > There's yet more concepts that help you avoid per frame cpu work: > - Instancing: Comes in various flavors, the aim is to render the same > geometry with different parameters many times from a single draw call > - Deferred shading/lighting: Avoid having to update buffers per frame > with cpu computed light information and implement per pixel lighting > as a function of rasterizing light bounding volumes into an already > rendered scene > - Generally post processing effects > - Texture/FBO ping pong: A variation of post processing, ping pong > between two (or cycle between more then 2) textures attached to a FBO > to perform some general computation on the GPU (like a blur filter for > instance, or erosion effects, edge detection etc.) > - Geometry ping pong: Involves switching rendering between two (or > cycle between more then two) transform feedback buffers, perform some > geometry buildup and computation (like instancing and fractals or L- > systems) > - GPU skinning: pass in all parameters (bone matrices, weights, mesh) > required for skinning into the pipeline (from buffers), and use the > vertex shader to transform a mesh according to each vertices weight > for the relevant matrices. > - Multi pass alpha/coverage post processing: gives you nice alpha > blending without having to order your primitives on the CPU before > rendering (see GPU Pro) > - Raycasting into volumetric data from shaders: Various effects like > accentuated fog/clouds, ambient occlusion for volumetric data on the > GPU, displacement mapping, contur reconstruction etc. > - and many more.... (it's mind boggling how many different things > people do) > > -- > You received this message because you are subscribed to the Google Groups > "pyglet-users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/pyglet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
