Sign in to follow this  
WFP

D3D12 - Loading textures, etc.

Recommended Posts

WFP    2781

Hi,

 

I've been able to load textures for a while now in my engine, but am wondering about best practices and recommendations.  Because of some of the changes with D3D12, we're responsible for making sure the data is properly staged, uploaded, and synced before being used.  Additionally, we're responsible for making sure any temporary (staging) resources don't get destroyed before they're done being used.

 

It seems that the MiniEngine sample code does an execute command list and GPU sync on every texture load (see DDSTextureLoader and CommandContext).  What I've been doing up to this point is essentially sending a command list to texture load calls during scene initialization and then before the initialization routine ends, calling execute command list on the entire thing and syncing that.  I've been sending along a std::vector<ComPtr<ID3D12Resource>>& for the texture loader to put temporary resources in to make sure they don't get deleted before the sync occurs.  This is nice in that I only have to bother with one command list execute and one GPU sync during initialization, but the load texture method signature gets a little ugly sending in the temporary resource vector.

 

Should I keep up my current approach, or should I be submitting command lists for execution and syncing more often like MiniEngine is doing?  Or is there perhaps a middle ground between the two approaches I should be thinking on instead?

 

Thanks.

Share this post


Link to post
Share on other sites
Hodgman    51334

Yeah performing the sync overhead on a whole "batch" of resources is probably the best idea. Engines often have a "precache" event (which begins loading a whole batch of resources) followed by a "loading complete" event (which only triggers once the entire batch is completed). Doing a single sync before triggering the "loading complete" would make sense.

Share this post


Link to post
Share on other sites
WFP    2781

Thanks for the information.  Sounds like I'm on the right track, then.  What I may try in order to make the client-facing interface a little cleaner is use an RAII type object that that sits in front of the actual texture loader and maintains the temporary resources.  When it goes out of scope, its destructor can execute the command list and sync everything that needs to finish loading up to that point, and the caller doesn't have to worry itself with maintaining vectors of resources, fences, event handles, etc.

Edited by WFP

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this