🔒 Locked

Interlaced pixels & depth data

Started by Viperius Aug 13, 2007 at 5:50 AM 0 replies 950+ views

Original Post

Aug 13, 2007 at 5:50 AM

First of all, I'm very new to DirectX programming so I will probably not use the correct terms; please bear with me :). Quick sketch of the problem: I'm trying to render to a display with an unconventional pixels layout; this pixel layout has pixels that are interpreted as color data and pixels interpreted as depth data. Furthermore the pixel mapping is interlaced. Following sketches should make this a bit more clear. X = RGB color info 0 = 0x00's D = Depth info Interlacing image color data: XXXX0000 XXXX0000 XXXX0000 00000000 00000000 00000000 to XXXX0000 00000000 XXXX0000 00000000 XXXX0000 00000000 Adding interlaced image depth data: XXXX0000 00000000 XXXX0000 00000000 XXXX0000 00000000 to XXXXDDDD 00000000 XXXXDDDD 00000000 XXXXDDDD 00000000 I tried rendering the data, and then moving the image- and depth data to system memory; however this creates a very big performance hit. As such I'd like to do this directly on the gfx card. Since I only have very limited knowledge of DirectX, I'd rather know beforehand if this is actually possible before getting further into it - just so I don't loose weeks on something that isn't deemed possible :). Edit: Come to think of it - I actually need to initialize the backbuffer and depth stencil surface with data coming from the system memory on every render step (the 3d rendered by directX is an overlay ontop of non-directX data). So even when doing these pixel mapping actions on the gfx card, I still have traffic of twice the frame size from the system memory to the gfx card memory with every rendered frame. Is there still an advantage then to try and do this aforementioned mapping on the gfx card itself? So is there a difference between reading and writing from/to the gfx card memory (1st case where pixel mapping is done on the gfx card requires writing to the gfx card memory for the initial backbuffer and depth stencil surfaces; 2nd case would be retrieving the rendered surfaces and processing them by the cpu - so reading the data from the gfx card). [Edited by - Viperius on August 13, 2007 6:40:25 AM]

ET3D

139

ET3D

Aug 14, 2007 at 4:26 AM

In the AGP days reading back from the card was significantly slower than writing to it. With PCIe this shouldn't be the case, though I think it's still so to a much slower extent. Of course, this is still a relatively slow operation (in both directions), so it's better to do it as little as possible.

Regarding what you're trying to do, it doesn't make sense to me that you'd want to output to a display with this kind of screen format unless you're reading back and display to a device different from the normal graphics card. In which case you already have to move things back to the CPU side, and it's probably better to just render the 3D and overlay it on the incoming data using the CPU.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.