Page 1 of 1

Launching Ogre from RenderDoc yield wrong texture rowPitch info

Posted: Wed Apr 11, 2018 5:29 pm
by garbage_collector
I have a D3D11 Ogre 1.10 application in which I create some manual textures and copy data to them using a PixelBox / HardwarePixelBuffer::lock. Similar to blitFromMemory, my copy routine takes into consideration that 'rowPitch' sometimes do not equal 'width', and everything works fine..

But then when I launched my application from RenderDoc, I noticed that textures that usually yielded a 'rowPitch' different from 'width' were displayed incorrectly. It looked similar to when one copies texture content without taking row pitch into account...

After further investigation I noticed that 'rowPitch' of locked PixelBox actually was different when launching the application from RenderDoc; it had changed to now equal 'width'. To me it seems like the rowPitch value received from mDevice.GetImmediateContext()->Map(...) is actually wrong when launching from RenderDoc, compared to how the resource appears to beon the GPU...

Have anybody experienced something similar when launching with RenderDoc?

Any idea of how this could be possible and how to fix it?

Re: Launching Ogre from RenderDoc yield wrong texture rowPitch info

Posted: Thu Apr 12, 2018 8:11 am
by garbage_collector
It seems that the incorrect rendering/copying only happens if I lock the texture using HBL_WRITE_ONLY when copying to it, but not if locking with HBL_DISCARDABLE. The difference in rowPitch (between with or without RenderDoc) is still there though regardless:

For a 200x200 texture:

1. Launching stand-alone, lock using HBL_DISCARDABLE: row pitch 224, correct result copying to gpu.
2. Launching stand-alone, lock using HBL_WRITE_ONLY: row pitch 224, correct result copying to gpu.
3. Launching from RenderDoc, lock using HBL_DISCARDABLE: row pitch 200, correct result copying to gpu.
4. Launching from RenderDoc, lock using HBL_WRITE_ONLY: row pitch 200, wrong copying result!

Image