On Tue, Jan 26, 2010 at 12:28 PM, Florian Bösch <[email protected]> wrote:
> On Jan 26, 2:49 pm, Tristam MacDonald <[email protected]> wrote: > > Geometry shaders aren't as fast as they might be, but histopyramids > perform > > the exact same task, and are much faster. > Provided you can somehow rather directly get texture data into vertex > buffers (commonly known as render to vertex buffer) > Vertex texture fetch + transform feedback is plenty fast enough for real time marching-cubes implementation via histopyramids. You will have to describe your use case in more detail - I can't picture the problem as you have outlined it. > I would recommend that you eliminate that expensive copy either by > > switching the terrain visualisation to relief mapping (thus rendering > > entirely in the pixel shader) > Relief mapping is slow as hell, besides other rendering related > drawbacks and artefacts. > > >, or using vertex texture fetch to use the > > heightmap texture directly in the vertex shader > Vertex shader texture fetches slow as hell. > > > , or use a texture buffer > > object + framebuffer blit to perform the copy a lot faster. > This is what I do, I follow the spirit of render to vertex buffer > *precisely*, you must have skipped that part of the code, so I'll > explain to you what it does: > 1) use a source heightmap and write that to two textures being the > vertex map and the normal map by way of a FBO > 2) copy that into a PBO (which theoretically should be vram -> vram) > > Suggesting to get rid of the copying process is silly, because > - The texture storage extension (where you get to attach a PBO as the > storage for a texture) does only work on nvidia cards, and I think my > linux driver doesn't even support it. > - Other then copying, there's no way to get data from textures to PBOs > - You can't attach a PBO to a FBO as render target All of your points are valid in other contexts, but in chasing this elusive performance argument, you are missing my larger point that ***none of this applies to your example wave program***. Given the size of window you are rendering the wave program to, a map size of 128x128 results in individual triangles that are on average the same size as an onscreen pixel. By the time you increase to a map size of 1024x1024, you are rendering an average of 64 triangles *per onscreen pixel*. Which means you have three performance problems: 1. copying 1,000,000 vertices from a texture into a vertex buffer. 2. transforming and clipping 1,000,000 vertices. 3. somewhere on the order of 200x overdraw. If you were to switch to relief mapping on a single quad, vertex texture fetch on a constant 128x128 grid, or your existing copy scaled down to 128x128, you would: 1. eliminate the copy entirely, or at least reduce it to a constant (and small) cost 2. reduce vertex processing to a constant and small cost 3. eliminate the massive overdraw In essence, the only performance issue your program is suffering from is that it performs a huge amount of very expensive work, *with no discernible effect to the user*. As the old adage goes, "the fastest code is the code that isn't run"... -- Tristam MacDonald http://swiftcoder.wordpress.com/ -- 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.
