PDA

View Full Version : The performance of shadowmap.



Lorenzot
10-09-2003, 10:15 PM
i use the same size of shadowmap texture(512X512).
first, i create the shadowmap with glCopyTexSubImage2D, the FPS is 330.
then i switch to pbuffer, but the FPS is 270.it is puzzling, because pbuffer eliminates the bus requirement of transfering the depth data.
any suggestions?
thanks

Korval
10-09-2003, 10:29 PM
it is puzzling, because pbuffer eliminates the bus requirement of transfering the depth data.

In theory. Some implementations are unable to implement pbuffers in hardware and must internally do a copy.

cass
10-10-2003, 04:21 AM
The more likely problem is that the expense
of changing contexts and/or drawables costs more than the copy.

Thanks -
Cass

Christian Schüler
10-21-2003, 04:57 AM
I found render-to-texture PBuffers to have a lower fillrate than windows, at least on NVidia hardware.

cass
10-21-2003, 07:25 AM
Originally posted by cschueler:

I found render-to-texture PBuffers to have a lower fillrate than windows, at least on NVidia hardware.



If you're rendering exclusively to pbuffers (that is, not calling MakeCurrent every frame), I would be surprised to see a difference. However, it does depend on the driver version - this feature does generally get better perf over time.

Obli
10-21-2003, 11:21 AM
Originally posted by cass:
The more likely problem is that the expense
of changing contexts and/or drawables costs more than the copy.
I'm somewhat shocked by that. I knew that changing contexts was slow but I didn't realized it was **so slow**.

Is there a possibility context switched will be faster in the future? I heard the last VPU from 3Dlabs (P10) got something to accelerate this task. I don't know if this is true and if it gives serious advantages, but I hope this capability will be improved.

cass
10-21-2003, 11:27 AM
Originally posted by Obli:

Originally posted by cass:
The more likely problem is that the expense
of changing contexts and/or drawables costs more than the copy.
I'm somewhat shocked by that. I knew that changing contexts was slow but I didn't realized it was **so slow**.

Is there a possibility context switched will be faster in the future? I heard the last VPU from 3Dlabs (P10) got something to accelerate this task. I don't know if this is true and if it gives serious advantages, but I hope this capability will be improved.



The context switching overhead could be reduced. Some of it's due to the general driver design assumption that it doesn't happen terribly often.

ARB_superbuffers should provide a significantly lighter-weight mechanism for offscreen rendering within a single context. That will hopefully be a more attractive API and more efficient to use.

Thanks -
Cass

Hampel
10-21-2003, 09:05 PM
Cass, is the ARB specification for ARB_superbuffer already approved and available? When there will be drivers available that support this extension?

Kosta

Christian Schüler
10-21-2003, 10:36 PM
Originally posted by cass:
If you're rendering exclusively to pbuffers (that is, not calling MakeCurrent every frame), I would be surprised to see a difference. However, it does depend on the driver version - this feature does generally get better perf over time.


I tested this with a minimal setup: Render everything into a pbuffer and then one final texture blast onto the screen. (So there's one context change per frame)

Not only is glClear() slower by an order of magnitude, but when I move the camera close to objects so triangles get large, the framerate drops more than when rendering directly into the screen.

All this on a GeForce2 MX, with detonator 45.xx

Zengar
10-22-2003, 07:56 AM
If it would be approved, we would have known about it... It looks like frozen - no news for a month!!! I'm going to the damn net avery day only to see if it's already there... http://www.opengl.org/discussion_boards/ubb/frown.gif but ...

roffe
10-22-2003, 09:53 AM
Originally posted by cschueler:
Not only is glClear() slower by an order of magnitude

That's strange, you're the second one to complain about slow clears for pbuffers(see beginners forum). I wonder why a pbuffer clear would be that much slower(unless its a 128bit pixel format)?

rgpc
10-22-2003, 07:15 PM
Originally posted by cschueler:

I tested this with a minimal setup: Render everything into a pbuffer and then one final texture blast onto the screen. (So there's one context change per frame)

Not only is glClear() slower by an order of magnitude, but when I move the camera close to objects so triangles get large, the framerate drops more than when rendering directly into the screen.



You mean two context changes... (Back and forth)

How are you getting the data into the texture - render to texture or CopyTexSubImage2D? Have you tried just rendering the scene to the pbuffer without copying it to the window? (ie. just do the context change, maybe display a frame rate but don't actually transfer the data from the pbuffer).

Maybe it's the transfer that is slowing you down and not the actual rendering?

Christian Schüler
10-22-2003, 10:41 PM
Originally posted by rgpc:
How are you getting the data into the texture - render to texture or CopyTexSubImage2D? Have you tried just rendering the scene to the pbuffer without copying it to the window? (ie. just do the context change, maybe display a frame rate but don't actually transfer the data from the pbuffer).

Maybe it's the transfer that is slowing you down and not the actual rendering?

I render directly into the pbuffer.
I could try your suggestion, but to make a point, I also see performance scale badly with large triangles and overdraw when rendering into the pbuffer.

I suspect the swizzled memory layout of pow-2 textures to be responsible for the poor rasterizing performance.

Sidenote: Do you have NVSDK and the NV effects browser? There's a pbuffer example, and even this pbuffer examples never gets above 20 fps or so, even on new cards.

Obli
10-23-2003, 03:10 AM
Originally posted by cass:
...
ARB_superbuffers should provide a significantly lighter-weight mechanism for offscreen rendering within a single context. That will hopefully be a more attractive API and more efficient to use.

Thanks -
Cass

That's good news however I am somewhat curious about compatibility of that functionality. I am not really worried since i'm targeting mainly NV3x and RD3xx hardware however if it runs even on lower end hardware, much better.

Zengar
10-23-2003, 03:43 AM
Obli, I guess it should run on a older hardware. It is just another solution of memory management. I assume it would be the VBO - like situation.

Obli
10-23-2003, 12:19 PM
Originally posted by Zengar:
Obli, I guess it should run on a older hardware. It is just another solution of memory management. I assume it would be the VBO - like situation.
Wow, I hope you're right. This would be a real "final solution" http://www.opengl.org/discussion_boards/ubb/smile.gif
Can't wait for them.

Korval
10-23-2003, 01:21 PM
It looks like frozen - no news for a month!!!

There was no news for some time since the GDC when superbuffers was first revealed as an idea. Since then, the only real news we had was a Power-Point presentation by ATi. The spec they presented had pretty decent basic functionality, but it was too restrictive in terms of which buffers you could use in a frame buffer (everything having to be the same size, etc), which other API's don't require.

rgpc
10-23-2003, 04:52 PM
Originally posted by cschueler:
I render directly into the pbuffer.

So you use Render to texture (not copy)..?



Originally posted by cschueler:
Sidenote: Do you have NVSDK and the NV effects browser? There's a pbuffer example, and even this pbuffer examples never gets above 20 fps or so, even on new cards.



I certainly get more than 20fps in the pbuffer examples (not sure of the actual figures). My own project uses pbuffers for dynamic cubemaps and gets 100-200fps on a geforce 3 and 600-800fps on a 5900 when using Render to texture. The same project gets around 150fps on the 5900 if I use pbuffers and copy.

harsman
10-24-2003, 01:14 AM
Not only is glClear() slower by an order of magnitude, but when I move the camera close to objects so triangles get large, the framerate drops more than when rendering directly into the screen.

All this on a GeForce2 MX, with detonator 45.xx

You're obviously fill bound. Or to be more precise, memory bandwidth bound. The GeForce 2MX has very little bandwidth, it's basically memory bandwidth bound at 640x480 in 32 bit colour (at lest my old one was). Try decreasing colourdepth to 16 bits and I'm willing to bet you'll see a large increase in framerate.

Christian Schüler
10-24-2003, 02:10 AM
Originally posted by harsman:
You're obviously fill bound. Or to be more precise, memory bandwidth bound. The GeForce 2MX has very little bandwidth, it's basically memory bandwidth bound at 640x480 in 32 bit colour (at lest my old one was). Try decreasing colourdepth to 16 bits and I'm willing to bet you'll see a large increase in framerate.

Sure, the MX has litte fill, but my point is, rendering into pbuffers gives even less fill.