Skip to main content
GameDev.net gamedev.net
🔒 Locked

[solved] re-committed sparse texture is mangled

Started by AverageJoeSSU Jun 4, 2015 at 3:56 PM 2 replies 4.2k views
Original Post
AverageJoeSSU
AverageJoeSSU

Puzzling issue. I have a code path that creates a sparse texture, and returns a Texture that is committed and sparse.

I then can uncommit it, which turns the texture to black ( i am rendering it onto a quad). If i then commit it again, which is the same path as was used when the texture was first created (minus the storage part), the texture appears but is totally mangled.

I checked width and height and texid values and format values, and they are the same (or at least after many checks appear to be, i could be missing something stupid). I know my data is at least getting in because the recommitted image is there, just mangled and rearranged in chunks.

Are there any things i need to do when recommitting a sparse textures memory? I know i need to reupload my pixels, and i know the memory needs to be commited before doing so, but I use the same code path when creating it the first time, and it renders and looks fine. the ONLY difference is i call uncommit before that same code path gets executed.

Any ideas?

-Joe

PS: First time image is created and committed (and bits uploaded) and rendered :

[attachment=27579:firstTime.png]

Second Time the image has been uncommitted, then recommitted (and bits uploaded) and rendered:

[attachment=27580:recommit.png]

------------------------------ redwoodpixel.com
AverageJoeSSU
AverageJoeSSU

Fixed! somehow the format passed to subimage either changed the second time around, or mattered the second time around, prolly the former. UGH. at least i found it.

------------------------------ redwoodpixel.com
AverageJoeSSU
AverageJoeSSU

Unfortunately it seems like TexPageCommittment is a blocking operation?

------------------------------ redwoodpixel.com
Krypt0n
Krypt0n

Unfortunately it seems like TexPageCommittment is a blocking operation?

it needs to reconfigure the page table, most likely the hardware cannot be running while this happens as it would lead to unpredictable results. After the call, the memory needs to be available for your updates, so there is a chance it blocks until the reconfiguration is done, otherwise it might become a big complex to track everything and move data asynchronously.

Topic Locked

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

Sign in to reply to this topic.