Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 23 Apr 2003
Online Last Active Today, 02:15 PM

Posts I've Made

In Topic: VS 2015 debugging errors

Today, 12:38 PM

I will take a look Buckeye. Juliean, it happened in other projects, I just put this together as the simplest I could that would reproduce. I've included the zipped project below. When compling under x86/debug it works, but x64/debug gives the error.

In Topic: VS 2015 debugging errors

Today, 07:50 AM

Debug build, no optimizations. And yes I tried setting a break point in main and then in Func (ie. I cleared the breakpoint in Func, set the breakpoint in main, ran it, and while in the main breakpoint re-set the one in Func). Results were identical. s was { 1, 2, 3, 4} in main, and some mess of random numbers (according to the debugger) in Func, and the program when finished executing output the correct value.

In Topic: ID3D11Buffer::GetDesc() performance

18 May 2015 - 04:17 PM

I didn't mention it, but I checked with a disassembler. It's just a couple of movs.

Ok cool!! Thank-you.

In Topic: ID3D11Buffer::GetDesc() performance

18 May 2015 - 01:57 PM

Why not step into the assembly of GetDesc while debugging and check if the code is simple enough (single memcpy or equivalent)?

Ya, I had a feeling thats what I was gonna have to do. I was just hoping someone on here with a better knowledge of the inner workings might know.

In Topic: D3D11 asynchronous buffer updates

15 May 2015 - 10:54 AM

Ok so if I understand correctly. Keep a queue of already mapped buffers (mapped by the main thread) of D3D11_USAGE_STAGING ready for each thread to grab. When its done the main thread just unmaps them and then performs a CopySubresourceRegion(). I assume that the data transfer (as the writing of the data to the mapped region) would be asynchronous? Keeping a queue of mapped buffers isn't a performance issue?

The other issue is that I will need to create these buffers at run time. I know it can cause stalls (hitching, lag, etc...) but I don't know the number or size I will need. Old/unused buffers will be recycled back into a pool for future use. But again from time to time there will be the need to allocate an additional buffer here or there. Now with the solution you suggested, wouldn't I have to create the buffer on the worker thread, stall the worker thread, somehow signal the main thread, have the main thread map the buffer, then signal the worker thread to continue? I'm not saying it wouldn't work. This just seems excessively complex for what seems (at least to me) a rather common usage of multithreading. Is this really what AAA engines do in the background? This sort of inter-thread gymnastics?