Jump to content

  • Log In with Google      Sign In   
  • Create Account

Yours3!f

Member Since 04 Feb 2011
Offline Last Active Apr 19 2016 01:15 AM

Posts I've Made

In Topic: "check before flight" list - for OpenGL

26 February 2016 - 08:30 AM

Greate list, but I'd like to add that one should also test for OpenGL errors.

 

of course :)


In Topic: [d3d12] command queues vs hardware queues (ACEs)

16 September 2015 - 01:29 AM

 


so what do you advise if I want to say do compute stuff while doing shadow map rendering (ie. only depth passes)
one graphics + one compute queue?
Yes, and then all of the necessary events/fences to synchronize the resources that are being shared between the two queues (just like you would for code that was split across two threads on a CPU).

 

allright, thank you! :)


In Topic: [d3d12] command queues vs hardware queues (ACEs)

15 September 2015 - 02:23 PM

Threads on the CPU are used to gain access to multi-core and hyperthreading resources.

Queues on the GPU are used to gain access to multi-GPU and async-compute ("GPU shader hyperthreading") resources.

Don't make one queue per CPU thread just to make your life easier. Make them only where you explicitly intend to create GPU-side command concurrency. e.g. computing while rasterizing, or copying while computing.

 

so what do you advise if I want to say do compute stuff while doing shadow map rendering (ie. only depth passes)

one graphics + one compute queue?


In Topic: [d3d12] command queues vs hardware queues (ACEs)

15 September 2015 - 02:22 PM

I did not test this, but I can guess having two copy queues with different priorities could be a good example where more than one queue are useful: a higher priority queue for things you need to load immediately before presentation and a "normal" priority queue for background copy operations.

 

yeah of course that makes sense :)


In Topic: [d3d12] command queues vs hardware queues (ACEs)

14 September 2015 - 09:17 AM

There is only one graphics queue queue per adapter node, but the same restriction does not apply to compute and especially copy queues as far I remember.  There are no restriction to the number of threads submitting command lists on a single queue, of course you need some kind of synchronization between different threads.

 

yeah I know that, I guess I'll have to measure out if multiple command queues get me additional perf or not.


PARTNERS