Quote:Original post by deathkrush

Quote:Original post by Seroja

glCopy could indeed be implemented badly, but:
1) It's 1 copy of 512*512 depth texture per frame, why would it decrease preformance x3 or even x4?

If the OpenGL driver is doing something silly like using the CPU to copy data, that would kill performance because accessing VRAM from CPU is very slow on many graphic cards. Think 10MB/s instead of 10GB/s !!!

Quote:Original post by Seroja
2) I use same glCopy for cube mapping, which is 6 256*256 RGB(A) textures, and even increasing that to 6 512*512 textures didn't hurt performance as much.

Maybe the OpenGL driver supports copying an RGBA texture using the GPU, but it falls back to 10MB/s for depth textures? In that case you can lie to the driver and say it's an RGBA texture so it does a fast copy and then change it back to DEPTH texture. You can use PBO (pixel buffer object) for that.

OK, now that makes sense. But I don't think I can fool the driver that easily. FBOs are out of my reach, so PBOs definitely are (not that I know how to use them anyway). Or is it possible with something more simple like pbuffers?

Otherwise, I don't know how to do it. If I tell it's RGBA, it will copy black (since I disable color writes during depth map creation pass). If I glRead the depth, I'll get same performance drop.

Maybe there is a way to convert depth (Z-buffer value) to color... Actually why not... It would be quite cumbersome with the way my code is set up, but the depth pass could have color writes enabled, everything disabled, except for eye-linear texture giving value according to distance from eye (which is the Z value). Will glCopy be able to copy RGBA into depth texture? e.g. what would the following call result with:
glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 0, 0, DepthSize, DepthSize, 0);
If a depth texture is bound?

OK, I actually tried that while writing the post :-)
I didn't do the eye-linear thing, but I bound the scene rendered from light view as a texture. Shadow became colorized :D
Actually, I think it ended up with some interesting projective texture. Unfortunately the R-coordinate comparison won't work this way (RGBA doesn't have R-coordinate). Speed did get up to the reasonable level, but this isn't shadow mapping (at least not without a shader). Unless I can convince OpenGL to use s or t as if they were the r coordinate - which I have no idea of how to do.

I still have doubts about this being a driver bug. Somehow, almost everything that didn't work for me in OpenGL ended up being my own bug.

Render texture isn't supported, so I can only use glCopy.

Tested it today on Intel and it works fine :D
So it's either my computer's or ATi's bad.

Positive: Intel (which turned out to be 945G not 915G), in addition to properly shadowing, seems to also support PCF. I used GL_LINEAR_MIPMAP_LINEAR, turned on blending, changed order of drawing to first dim then bright, and it indeed became quite smooth. Without blending, there were "halos" around shadows (that's where alpha isn't 1 or 0). If Intel can do it and nVidia can do it, why ATi can't?

Negative: The grass started getting "animated" - e.g. I see the triangles that make up the grass, and texture is moving on them. I distorted the texture coordinates and didn't supply proper Q coordinate, I know, but on nVidia and ATi at least the behavior is stable (so when moving the grass plane texture sticks to it and doesn't move). Oh, and Intel's driver doesn't know that fog enable is part of the enable bits, so I had to change PushAttrib to all bits to make it work.


Thanks for the help, I'm pretty much OK with the situation now. I still would like to see someone with an X800 (or similar) tell me if they have same low FPS.


Edit: just a quick question that came into my mind - assuming GPU has PCF, if a fragment has alpha of 0.3, and PCF says 50% coverage (0.5 alpha), what will be the final alpha of te fragment? 0.15, 0.5 or anything else?

[Edited by - Seroja on August 6, 2007 1:50:31 PM]

Quote:Original post by agi_shi

Quote:Original post by Seroja
Render texture isn't supported, so I can only use glCopy.

Tested it today on Intel and it works fine :D
So it's either my computer's or ATi's bad.

Positive: Intel (which turned out to be 945G not 915G), in addition to properly shadowing, seems to also support PCF. I used GL_LINEAR_MIPMAP_LINEAR, turned on blending, changed order of drawing to first dim then bright, and it indeed became quite smooth. Without blending, there were "halos" around shadows (that's where alpha isn't 1 or 0). If Intel can do it and nVidia can do it, why ATi can't?

Negative: The grass started getting "animated" - e.g. I see the triangles that make up the grass, and texture is moving on them. I distorted the texture coordinates and didn't supply proper Q coordinate, I know, but on nVidia and ATi at least the behavior is stable (so when moving the grass plane texture sticks to it and doesn't move). Oh, and Intel's driver doesn't know that fog enable is part of the enable bits, so I had to change PushAttrib to all bits to make it work.


Thanks for the help, I'm pretty much OK with the situation now. I still would like to see someone with an X800 (or similar) tell me if they have same low FPS.


Edit: just a quick question that came into my mind - assuming GPU has PCF, if a fragment has alpha of 0.3, and PCF says 50% coverage (0.5 alpha), what will be the final alpha of te fragment? 0.15, 0.5 or anything else?

I can't contribute anything other than the fact that my X850XT runs that demo at a constant 4FPS [sad].

Thanks. That means that it's most probable that this is an X??? / X8?? series bug. Any point notifying ATi about it? I mean, glCopy is old and isn't widely used (especially on a card with FBOs), and X800 isn't a new card they really care about. If yes, anyone knows how / where?

Quote:Original post by agi_shi

Quote:Original post by Seroja

Quote:Original post by agi_shi

Quote:Original post by Seroja
Render texture isn't supported, so I can only use glCopy.

Tested it today on Intel and it works fine :D
So it's either my computer's or ATi's bad.

Positive: Intel (which turned out to be 945G not 915G), in addition to properly shadowing, seems to also support PCF. I used GL_LINEAR_MIPMAP_LINEAR, turned on blending, changed order of drawing to first dim then bright, and it indeed became quite smooth. Without blending, there were "halos" around shadows (that's where alpha isn't 1 or 0). If Intel can do it and nVidia can do it, why ATi can't?

Negative: The grass started getting "animated" - e.g. I see the triangles that make up the grass, and texture is moving on them. I distorted the texture coordinates and didn't supply proper Q coordinate, I know, but on nVidia and ATi at least the behavior is stable (so when moving the grass plane texture sticks to it and doesn't move). Oh, and Intel's driver doesn't know that fog enable is part of the enable bits, so I had to change PushAttrib to all bits to make it work.


Thanks for the help, I'm pretty much OK with the situation now. I still would like to see someone with an X800 (or similar) tell me if they have same low FPS.


Edit: just a quick question that came into my mind - assuming GPU has PCF, if a fragment has alpha of 0.3, and PCF says 50% coverage (0.5 alpha), what will be the final alpha of te fragment? 0.15, 0.5 or anything else?

I can't contribute anything other than the fact that my X850XT runs that demo at a constant 4FPS [sad].

Thanks. That means that it's most probable that this is an X??? / X8?? series bug. Any point notifying ATi about it? I mean, glCopy is old and isn't widely used (especially on a card with FBOs), and X800 isn't a new card they really care about. If yes, anyone knows how / where?

TBH, I don't see any point. They probably know about it already (well, they are the ones who wrote the drivers [lol])... and besides, these cards are behind 2 generations already [wink].

Speaking of drivers... try out the Omega drivers. They're made "for" games. Maybe they fix this issue?

I *was* on Omega before I got this bug. Then I decided to update drivers, got Omega's latest, which didn't work for some reason. So currently I'm on latest Catalyst.

Which means this is a "serious" bug - that has been for some time in drivers. But this is likely due to the technique not being used in games and thus considered low priority (or maybe they never even noticed the bug).