Wednesday, November 18, 2009

Adventures in virtual texture space, part 15

For the last couple of weeks I've been working at a client in Utrecht, a city in the middle of the Netherlands, but I live in Capelle aan den Ijssel, which is a small city which has grown into the much larger city of Rotterdam.
The problem is that traffic between those two city is horrible.
If there wasn't any traffic it would take me 45 minutes, but it actually takes me 2 to 3 hours.
Well, it would take me 2 to 3 hours if I didn't get up at 6, eat my breakfast in the car, and drive like mad to avoid the rush!
So for the last couple of weeks I've been in a constant state of tiredness.

Anyway.
Since my last update I've written a idtech-4 shader parser so I can get more correct textures.
Before I would just take the name of the shader and let the importer kinda guess which textures it would need.
Fortunately most of the time the shaders and their textures had predictable names, but not always.
Parsing the shaders also allows me to get back the normal and specular maps, which should be useful when I start to implement lighting.

Other than that I downloaded the beta of Visual Studio 2010, and man, those profiling tools rock!
I haven't tried them on C++ code yet, so I'm not sure how or if they're any good there, but for managed code they're awesome!
Can't wait for it to come out of beta.

I also optimized my code a bit, and now it oscillates between 3-5ms per frame (300-200fps).
It takes about 2ms for the whole readback part, which is more than I would like.
(And I'm pretty sure this could be done a lot faster in C/C++ where you can do all kinds of smart pointer tricks etc.)
This makes me think that the analytical solution that I've been thinking about could be a lot faster.

Other than that it also takes about 2ms to render everything, but I expected that since I'm not doing anything remotely smart, at the moment, when it comes to rendering geometry.. I'm basically just drawing the entire level in one draw call right now.
The fact that the vertex count is way above 200k certainly doesn't help ;)

2 comments:

  1. Are you rendering the uvs, then doing the readback right away? In that case, you will stall the cpu until the gpu is done, which easily explains that slow performance. Especially if you had any expensive shaders running _before_ you did the uv stuff (in the last frame).

    You could try to read the results next frame. This introduces a latency, but prevents GPU stalls.

    ReplyDelete
  2. Yes, that's what I'm doing already.
    Most of the time is spend in the processing of the texture however (figuring out which pages are visible), not the read-back itself

    ReplyDelete

To you spammers out there:
Spam will be deleted before it shows up, so don't bother.