Re: Compressed textures

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Thanks a lot for your very detailed answer. I have mixed my response and aditional questions with the text. I hope it is not looking too messy.

You are right in that I wonder what happens to the bandwidth (pci-e) and why it is so slow. I was previously considering writing a texture in parallel with begin,end,present and as I understand you, that would have improved things.

(note that this blocking call isn't always present()!).
That is new for me. Good to know. I was pretty confident I only had to consider blockking there.

Let's include a (discard-mode) lock,

1. lock, copy, unlock
2. beginscene draw endscene
3. present, goto 1

This is exactly what I had until today... and it was slow.

and assume, the dirver is able to create n shadow-instances f the texture object,

I have not been able to find any info on "shadow instances". What do you mean by that? That the object exist in multiple copies behind the scene so I can use one copy for rendering while writing into another?

where n is an integer >= 0. This number n might depend on things like driver configuration,
but also on the runtime situation (memory fragmentation, for example, or simply lazy
realeasing of shadow-instances). Remember noone said that this number n must be
greater then 0, so the driver is always free to choose to ignore the discard-locking-mode.

If n is less then the number of frames, the driver/gpu can fall behind the applicction,
and if the application feeds d3d-tasks fast, the situation would become
almost idetical to the case where n=0 (no dicard-mode).

With two backbuffers, I assume present will block when the gpu rendering falls two frames behind?
I understand the above as that I can not render ahead when I change the object in between render calls.
Keep in mind I an new to this, so I may misunderstand you entirely, but is what you are saying that
1:lock,write tex,unlock
2:begin,end,present
3:lock,write tex,unlock
will actually block in 3 since the gpu maybe still havent come arround to render when was defined in 2, and that rendering needs the texture as it is after 1, so while it has not used the texture in its first state, I can not alter it?





After all, you're probably right in that on your computer it doesn't make
a diffrence for your application, if you lock(discard) a single "upload"
texture object, or lock(discard) just one surface of a circular "upoad"
texture collection.

Well, if it doesnt make a difference, then something else certainly do.

However, if you compare the amount of data you actually upload
(100 MB/s ?) against the available upload bandwidth (AGP8X: 2GB/s)
you'll probably wonder where all that bandwidth is gone, even if
you take some degrading factors (like suboptimal CPU<->AGP bus
coupling/usage and/or CPU-usage for additional processing) into account.

On the system I sit with right now, I can render 280FPS when I read texels to memory and every frame lock,copy,unlock,begin,draw,end,present
If I create a managed texture for every frame and then change to begin,set texture,draw,end,present I get 1400 fps. That is because the entire movie can be in videomemory at once. This indicates to me that the difference is lost on the overhead of transfering data. I actually transfer 464MB every second at 280FPS.

If I understand you correctly, having a managed texture for every frame and letting directx move the data when needed would be a lot better than having one texture and dealing with it as I did before. This way a texture is never modified. Perhaps this could be even better if I asked it to preload a few frames ahead so one or two slow texture loads would not suddenly slow down a few frames and causeme to loose a frame.

Anyway. Thanks a lot for the explanation. I hope I understood it correctly.

.

Relevant Pages

  • Re: MultiVMR9 issue
    ... You can only access the render texture during the 'Present' call. ... Of course one solution was to just copy to another texture during the Present call which then freed me to render at the rate I wished. ... that speed I stop getting any frames painted. ... resolution MPG1 file it works at 60fps ... ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: Bad Colors On Frame Buffer Textures
    ... program possible to render to a texture ... I'll hack up a small GLUT program to ... nVidia's notoriously buggy Linux driver. ...
    (comp.graphics.api.opengl)
  • Re: Movie Rendering in Direct3D
    ... still, read up on filters, and managing filter graphs. ... >> InitGeometry, and Render. ... >> gets a pointer to the base filter from the texture renderer filter, ... >> adds the source filter to the graph ...
    (microsoft.public.win32.programmer.directx.graphics)
  • Re: DirectDraw and Direct3D
    ... Render them in back to front order and use color keying to exclude pixels ... with alpha blending and alpha testing enabled (or just ... layer behind the previously displayed layer for pixels that are removed. ... texture in video memory whenever the background is updated. ...
    (microsoft.public.win32.programmer.directx.managed)
  • Re: Movie Rendering in Direct3D
    ... > InitGeometry, and Render. ... > gets a pointer to the base filter from the texture renderer filter, ... > adds the source filter to the graph ...
    (microsoft.public.win32.programmer.directx.graphics)