So, which thread were posting in originally? Because the link you gave is to this thread, but it doesn't match the dimensions you've descried. Perhaps this is part of the problem?
GCN is even better in future games. GCN is a fully bindless architecture (except for index buffers). It doesn't have any fast path hardware for vertex fetch, constant buffers or static binding. This must hurt a bit in current games. GCN pays a little bit extra for more flexibility. Other GPUs will likely lose a little bit of performance from bindless resources (esp older ones). As far as I know, no PC game yet uses bindless resources, so we need to wait a bit to see the results. AMD also is exactly as fast reading data from a raw/structured buffer compared to a constant buffer. Nvidia performance drops. Constant buffers cannot be directly written by compute shaders. If you want to achieve the fast path on Nvidia, you need extra copy operations (= more GPU stalls). Not a big problem in old games, but compute shader based pipelines are getting more common.
AMD Terascale also had separate constant buffer hardware. I measured up to 6x perf diffference on Radeon 5870 (CB vs structured, coherent access). CB read (coherent) was also 2x faster than LDS read. It was really hard to get heavily compute shader based code running fast on Terascale.
Sounds plausible. I have also heard other guesses like using LDS memory for storing temporary graphics stage outputs. Nvidia's graphics pipeline load balancing has been better than AMD. Having more on-chip memory is always better for purposes like this. If you look at the pixel shader epilogue generated by AMDs shader compiler, you also notice that transformed vertices are loaded from LDS (before interpolating them). AMD also uses some LDS for graphics pipeline purposes. Example (page 42+): https://michaldrobot.files.wordpress.com/2014/05/gcn_alu_opt_digitaldragons2014.pdf.
I have done this manually several times. It is faster to load lookup table to LDS compared to directly indexing (incoherent) it from memory. Both on Nvidia and AMD. As long as your thread groups are big enough, there isn't much overhead in loading the lookup table to LDS once per group (one 100% coalesced load instruction per thread from L1/L2 cache). Sharing constant data loaded to LDS accross thread groups is an interesting topic of discussion. I have also found other use cases for it. It would definitely bring some gains, but it would complicate the LDS resource management a lot (potential on-chip memory fragmentation, resource starvation, etc).It would be cute to have a flag to tell the AMD driver to pre-load the CB contents into LDS. No bank conflicts on read AFAIR. The LDS can be persistent, having a lifetime as long as there are waves of that kind on a CU. Just as a workaround until we get a LDS model for the graphics pipeline stages ... one can dream.
Don't know. My dev computer still has GTX 980. Nvidia hasn't been lately as open as AMD about their GPU architecture. I would hope that we get documents like this from Nvidia: http://developer.amd.com/wordpress/media/2013/07/AMD_Sea_Islands_Instruction_Set_Architecture.pdf.
You can get bank conflicts on reads and writes to LDS.It would be cute to have a flag to tell the AMD driver to pre-load the CB contents into LDS. No bank conflicts on read AFAIR. The LDS can be persistent, having a lifetime as long as there are waves of that kind on a CU. Just as a workaround until we get a LDS model for the graphics pipeline stages ... one can dream.
