DDS Ring Buffer
| Author: | catweasel |
| Date: | 22 Aug, 2012 |
| Category: | plugin |
| Credits: | elliotwoods |
Download
64bit
Description
- Introduction
I know a few of you are streaming DDS's off the HDD to playback video. Here's a ring buffer to do that.
- Notes
- All file loading is performed in off-mainloop threads
- Pushing to GPU is performed on main thread (as required in DX9)
- TextureUtils provides a mechanism to create textures from files (e.g. DDS), we use this mechanism for the first frame
- Remaining frames with same resolution will be copied to GPU with an UpdateTexture function*
- Keeps persistent memory buffers between frames if the file sizes are the same (i.e. true of DDS) (*) I've manually coded the UpdateTexture function to parse the DDS file header and contents, and push the contents to the GPU without recreating the texture
- DXT5 lookups are slow?
We didn't end up using this plugin, as we found that texture lookups became slower on DXT5 compared to X8R8G8B8 textures (hits the render stage).
I think in general this effect is negligible, but for the amount of texture lookups we're using (7 * HD in PS 3.0 on Radeon 6970's) it became a noticeable hit (dropped to 40fps min framerate vs 60-synced before). This effect continued after the texture was loaded (i.e. the slowdown was purely at render time).
The hypothesis that a texture lookup on DXT5 takes more GPU time than from an X8R8G8B8 makes theoretical sense, but might turn out to be incorrect. However, it is in line with our tests here.
Comments
Comments are no longer accepted.Please create a new topic in the vvvv beta forum to discuss this contribution.
Nice, unfortunately it doesn't work on my machine. (Renderer stays black, node gets red when changing the value on the index pin)... any idea why?
@flux
thanks for the feedback this is tested on b27. works across 3 machines here. do you get anything in Renderer TTY? which vvvv you on?
works here under beta28 with the \vvvv_45beta28\lib\assets\images\meso_cubemap.dds = DXT format but not with \vvvv_45beta28\lib\assets\images\color_cubemap.dds which is a X8R8G8B8 texture
00:05:04 ERR : Exception occured in TMPluginWrapperNode.Evaluate: File format not supported by DDSFile
aha yes. it's hardcoded for DXT5's right now! :) will add that to the description
@elliot
sorry i forgot, i tested it on beta28. And i think it was the same issue circuitb mentioned. A8R8G8B8 dds textures don't seem to work. i got it running with dxt5 compressed ones on b27 and 28.
a spreadable version sounds possible?
yes. certainly possible. it's not going to be very tidy for changing spread-count accidentally feeding in a large spread is going to either: a) be capped (i.e. hard cap on number of slices) b) crash (you'll allocate too much cpu and gpu ram)
is this something immediately useful? i haven't got the source here anymore
no not really in a hurry just testing best ways to read image sequences for something like 5 sequences of 200 frames ... i duplicate the dds ring buffer node everything is fine with a smooth playback!
but be careful with the buffercount value vvvv dedicated memory get bigger and bigger each time you change this value (increase or decrease)... when it reaches the memory limit DDS nodes turns red and you need to restart vvvv to clear the allocated memory.
interesting. i'm using byte arrays for storage which you can't actively flush (the .NET garbage collector is supposed to clean that up when it feels like). I can provoke the garbage collector to get on with its job whenever you ask as well, so I can do that when the pin's changed (flushing GC manually results in a temporary pause of the whole app, something like 50ms)
yep could be cool to manually flush the memory without restarting vvvv!
also the plugin doesn't work with the sharedtexture /dx9ex switch