Skip to main content
gamedev.net
🔒 Locked

GetRenderTargetData problems with multiple render targets

Started by Koiby25 Mar 1, 2009 at 12:50 AM 5 replies 1k views
Original Post
Koiby25
Koiby25
GetRenderTargetData is giving me surface which looks partially "cut off" (see outLockSurf_other.jpg). I'm rendering to the back buffer and another surface, and putting the render target data in a lockable surface. The problem only occurs when I'm getting data from the other surface. Everything is fine when I use the back buffer. Here's the code, with the (hopefully) unimportant stuff removed:
// "finalTex" is the texture to which the other surface is attached
D3DDev->CreateTexture( width, height, 1, D3DUSAGE_RENDERTARGET,
	D3DFMT_A8R8G8B8, D3DPOOL_DEFAULT, &finalTex, 0 );

// "lockTex" is the texture to which the lockable surface is attached
D3DDev->CreateTexture( width, height, 1, 0,
	D3DFMT_A8R8G8B8, D3DPOOL_SYSTEMMEM, &lockTex, 0 );
	
/* ...rendering stuff... */

// Setting up the targets for the final render pass
D3DDev->SetRenderTarget(0, D3DBackBuffer);

finalTex->GetSurfaceLevel(0, &finalSurf);
D3DDev->SetRenderTarget(1, finalSurf);

/* ...final render pass... */

// Put render data in the lockable surface
lockTex->GetSurfaceLevel(0, &lockSurf);

finalTex->GetSurfaceLevel(0, &finalSurf);	// using this render target creates the problem

D3DDev->GetRenderTargetData(finalSurf, lockSurf);

// Save the surfaces to a file for proof
D3DXSaveSurfaceToFile(L"outFinalSurf.jpg", D3DXIFF_JPG, finalSurf, NULL, NULL);
D3DXSaveSurfaceToFile(L"outLockSurf.jpg", D3DXIFF_JPG, lockSurf, NULL, NULL);


This gives a "correct" outFinalSurf.jpg, and a cut off outLockSurf.jpg (shown in outLockSurf_other.jpg). If the problem-creating line (marked with a comment) in the code is replaced with this, all output is correct:
D3DDev->GetBackBuffer(0, 0, D3DBACKBUFFER_TYPE_MONO, &finalSurf);


So now outFinalSurf.jpg matches outLockSurf.jpg (shown in outLockSurf_back.jpg), and both are the way they're supposed to look. Also, there is no problem either way when the image is 1024x1024 pixels. The uploaded pictures were originally output at 2048x2048, and when larger images are used (like 4096x4096) more than 50% of the image is cut off. Does anybody know why this is happening? Images: outFinalSurf.jpg outFinalSurf.jpg outLockSurf_other.jpg outLockSurf_other.jpg outLockSurf_back.jpg outLockSurf_back.jpg
ET3D
ET3D
What results do you get when running with the reference device? If everything is fine with REF, try another card or different drivers (what are you currently using?) and see if that helps. If you get the same problem with REF, there's probably something wrong with your code, and we could try to get to the bottom of it.
Koiby25
Koiby25
Quote:
Original post by ET3D
What results do you get when running with the reference device? If everything is fine with REF, try another card or different drivers (what are you currently using?) and see if that helps. If you get the same problem with REF, there's probably something wrong with your code, and we could try to get to the bottom of it.


There was no problem when I tried it with REF.

Since I rebooted, the problem now only occurs with textures 4096x4096 pixels or greater (the 2048x2048 output is correct now, unlike yesterday). I don't think I can try it on any other card, since I don't have another with a maximum texture width or height above 2048 pixels. I'm using a Radeon HD 4870 X2 now, which has maximum texture dimensions of 8192x8192.
Koiby25
Koiby25
I'm not sure if this would have anything to do with the problem... but when I call finalSurf->Release(), it returns 1. Shouldn't it be returning 0? The same thing happens with a few other surfaces that I send to GetSurfaceLevel.
ET3D
ET3D
Is there any way to temporarily disable crossfire on your card? If so, I'd suggest trying that. Sounds like a likely suspect.

Regarding the 'release', you're probably using a function that adds to the reference count, but you don't have a matching 'release'. (Functions such as GetSurfaceLevel and GetRenderTarget add to the reference count.) I don't think it's a related problem.
Evil Steve
Evil Steve
Quote:
Original post by ET3D
Is there any way to temporarily disable crossfire on your card? If so, I'd suggest trying that. Sounds like a likely suspect.
I'd second this. If you have two graphics cards handling one output surface, it's usually handled by splitting the surface into two, and having each card render one half of it.
If the reference rasterizer works, then that strongly hints at a driver bug, and this sort of thing looks like the second card isn't submitting it's render target data correctly.
Koiby25
Koiby25
Quote:
Original post by ET3D
Is there any way to temporarily disable crossfire on your card?


There doesn't seem to be a way to do that, unfortunately. I've heard the Windows XP drivers for this card are not so good, though. I'm doing this all in XP right now, but I'll try it with Vista when I get the chance.

Topic Locked

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

Sign in to reply to this topic.