PDA

View Full Version : New AMD extensions



charliejay
07-29-2011, 06:35 AM
Just updated to Catalyst 11.7, and noticed the addition of AMD_pinned_memory, and AMD_shader_trace.

These seem to have been in Catalyst 11.6, and I was able to find an example of the use of pinned memory.

Are there specs out there for these two, and if so, could someone point me at them, please?

If not, are they expected soon? Shader trace in particular sounds interesting...

mfort
07-29-2011, 07:37 AM
AMD_pinned_memory ... very cool. Some more info here: http://developer.amd.com/afds/assets/presentations/2116_final.pdf

NVIDIA is ashamed now. I have to use CUDA 4 to do the same tricks there.

charliejay
07-29-2011, 08:27 AM
2116_final was the reference I found, too...

Couldn't find anything on shader_trace though.

Alfonse Reinheart
07-29-2011, 12:18 PM
At first, I was impressed by AMD_pinned_memory. After understanding what it does? Not so much.

They radically alter the meaning of glBufferData, changing it from an allocation function to a "attach this client memory pointer to a buffer object" function. Was there some reason they couldn't just add a new function to do this? And say that you can't call glMap/Unmap/Buffer(Sub)Data on their new buffer object target?

The idea is understandable; the implementation is what's wacky.

And it doesn't even seem to be much of a speed-up, even for their own tests. Sure, if you're loading a bunch of 256x256 textures you get some nice improvements. But who does that? Most applications that need the performance are loading big textures. For them, the DMA bandwidth is what matters most; the minor setup improvements that this extension offers are exactly that: minor.

Pierre Boudier
08-08-2011, 12:06 PM
there is a key difference introduced by this extension:
- you can directly use memory allocated outside of the GL and directly read from there with your GPU.

there are actually many applications which wants to fetch data only once, and spend time uploading on the GPU before using it, which requires memcpy+dma+driver setup.

By pinning/locking the memory they don't need to do this at all; this is an even bigger improvement on an APU which has a shared memory architecture.

Pierre B.

Alfonse Reinheart
08-08-2011, 01:09 PM
I completely understand what it does. And the functionality itself is fine.

What I'm against is the abuse of the API. You use glBufferData to specify the pointer, rather than adding a new function specifically for that. You redefine the meaning of an existing function to mean something completely different from its prior meaning.

That's not good. Especially when all you needed to do was provide another entrypoint.

mhagain
08-08-2011, 03:17 PM
I agree with Alfonse here. Historically the VBO API was already made a mess of by piggy-backing different behaviour on the gl*Pointer functions depending on whether or not a buffer object is bound (which could lead to some exciting surprises if one wasn't careful enough) - this is just more of the same and the API becomes messier as a result. Hopefully when/if something like this begins it's move to core (which it should because it's a great feature) the spec for it will be revised.