1

I've recently been looking with PIX for Windows at an application using Direct3D 9 for rendering. What I've noticed is that the first operations of a given frame on render targets or textures that wrap them seem to take a very long time. The system is running Windows 7 and is not out of graphics memory. No thrashing should thus be happening. What I find interesting is that operations on 16-bit floating point surfaces take about double the time as on 8-bit integer surfaces.

Anyone have any explanation for this phenomena?

-Timo

Timo Heinäpurola
  • 431
  • 4
  • 7

2 Answers2

0

If the 1st operation takes a long time, but subsequent operations do not, it sounds like a JIT (just-in-time) compilation issue. You didn't mention what language/framework you are using, but if it anything that is compiled at runtime (.NET, Java, etc) you will experience a delay the 1st time you run a bit of code that you will not on subsequent iterations.

As for the 16-bit taking twice as long as the 8-bit, it's hard to tell what's really going on under the hood. It wouldn't be completely ridiculous to believe that 16-bit floating point operations could take twice as long as 8-bit fixed width integers.

Joel B
  • 12,082
  • 10
  • 61
  • 69
  • 1
    This is pure C++ so no JIT involved. Also the time that the operation takes is very long, reported by PIX as 898916352 for the 8-bit render target case. – Timo Heinäpurola Aug 20 '13 at 11:41
  • Even without JIT if they're initializing things for the 1st time (look-up-tables, random numbers, etc) you could have a performance hit. Or maybe they're taking out a chunk of memory the 1st time that they don't have to do on subsequent invocations. Just trying to explain it away though, it might be a real issue, so wait for some other answers and see if anyone else has seen these issues. – Joel B Aug 20 '13 at 12:21
0

In D3D9, the driver architecture is such that resources have to be validated when they are used. This increases the overhead of many API calls, and is part of the reason you should optimize to do more with fewer API calls.

In addition, on older Windows platforms (e.g Windows XP) the D3D driver was completely in kernel-mode, so API calls would invoke a user-mode to kernel-mode context switch (this is not the case in Windows Vista, 7 or 8, which have a user-mode front-end like OpenGL).

In D3D10, resources are validated only when they are created. Likely because D3D10 is layered on top of WDDM, which made the switch from a full kernel-mode to partially user-mode D3D runtime. In WDDM if the D3D runtime crashes it will not cause a kernel panic (BSOD), so validation is not as important. You do not have to be nearly as paranoid about these things when you're running in user-mode.


Now, as for the performance between 8-bit integer and 16-bit fp, this is actually to be expected. Not so much because one is integer and the other is FP (GPUs are great with FP), but because one is twice the size of the other. GPUs have a lot of memory bandwidth, but you can still improve performance simply by using the smallest data type possible.

Andon M. Coleman
  • 42,359
  • 2
  • 81
  • 106
  • Yep, I also thought I might blame it on validation of resources but what I'm bothering is, does the driver actually have to validate each texel in the texture: "Now, as for the performance between 8-bit integer and 16-bit fp, this is actually to be expected." That would sound a bit odd. I would understand it for compressed resources, but uncompressed render targets... – Timo Heinäpurola Aug 30 '13 at 10:10
  • @TimoHeinäpurola: Not at all, you have it backwards in fact. GPUs have better performance with compressed textures than uncompressed. Texture compression is lossy, so it does not have high computational overhead. It is designed for the sole purpose of reducing memory bandwidth at the cost of image quality. It is memory bandwidth that is the source of performance penalty between an 8-bit texture and a 16-bit texture, you are reading/writing twice as much data. – Andon M. Coleman Aug 30 '13 at 12:15