Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Sep 2011
Offline Last Active Today, 05:49 AM

Posts I've Made

In Topic: Vulkan is Next-Gen OpenGL

21 July 2016 - 10:23 AM



Async compute is looking to be a killer feature for DX12 / Vulkan titles. The benchmarks indicate that Pascal's implementation of async compute isn't half as good as AMD's.

Ah, one should be careful with such a blanket statement (unless you have some more detailled information?). Benchmarks are rarely unbiased and never fair, and interpreting the results can be tricky. I'm not trying to defend nVidia here, and you might quite possibly even be right, but I think solely on the linked results, this is a bit of a hasty conclusion.

From what one can see in that video, one possible interpretation is "Yay, AMD is so awesome, nVidia sucks". However, another possible interpretation might be "AMD sucks less with Vulkan than with OpenGL". Or worded differently, AMD's OpenGL implementation is poor, with Vulkan they're up-to-par.

Consider the numbers. The R9 Fury is meant to attack the GTX980 (which by the way is Maxwell, not Pascal). With Vulkan, it has more or less the same FPS, give or take one frame. It's still way slower than the Pascal GPUs, but comparing against these wouldn't be fair since they're much bigger beasts, so let's skip that. With OpenGL, it is however some 30+ percent slower than the competing Maxwell card.

All tested GPUs gain from using Vulkan, but for the nVidia ones it's in the 6-8% range while for the AMDs it's in the 30-40% range. I think there are really two ways of interpreting that result.


Not really, because all games that have async compute AMD gains much more than pascal, including direct X titles. Check this out if you don't believe me:




That benchmark shows that samoth is correct. Async Compute seems to be improving performance by 2-5% for AMD, which is far from the massive improvement in Doom. The "AMD is awful at OpenGL" theory seems even more likely now.

In Topic: D3Dlock_Nooverwrite Erratic Flashing

21 July 2016 - 04:05 AM

Have you enabled the debug layer?

D3DLOCK_DISCARD together with D3DLOCK_NOOVERWRITE is nonsense. Either you use only discard to get a new buffer every time or you create a larger buffer, map a small part with nooverwrite and use it, map the next small part with nooverwrite and use it, map the next...

In Topic: [D3D12] SV_ClipDistance shader compile error

09 July 2016 - 06:25 AM

It means that the maximum is

float4 clipplanes0 : SV_ClipDistance0;
float4 clipplanes1 : SV_ClipDistance1;

In Topic: [D3D12] SV_ClipDistance shader compile error

09 July 2016 - 05:21 AM

MSDN says

The combined clip and cull distance values are at most D3D#_CLIP_OR_CULL_DISTANCE_COUNT components in at most D3D#_CLIP_OR_CULL_DISTANCE_ELEMENT_COUNT registers

In Topic: Is using one the switch statement better then using multiple if statements?

25 June 2016 - 08:32 PM

Modern compiles are not so stupid, however. Example: https://godbolt.org/g/i5NBKH Note that foo() and bar() are both compiled into jump tables despite one using a switch statement and the other an if-statement chain.

Doesn't seem to be the case for GCC and MSVC.