On 15.07.2017 02:54, Marek Olšák wrote:
On Wed, Jul 5, 2017 at 1:42 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
On 04.07.2017 15:05, Samuel Pitoiset wrote:

Using VRAM address as bindless handles is not a good idea because
we have to use LLVMIntToPTr and the LLVM CSE pass can't optimize
because it has no information about the pointer.

Instead, use slots indexes like the existing descriptors.

This improves performance with DOW3 by +7%.


Wow.

The thing is, burning a pair of user SGPRs for this seems a bit overkill,
especially since it also hurts apps that don't use bindless at all.

Do you have some examples of how LLVM fails here? Could we perhaps avoid
most of the performance issues by casting 0 to an appropriate pointer type
once, and then using the bindless handle as an index relative to that
pointer?

The problem is inttoptr doesn't support noalias and LLVM passes assume
it's a generic pointer and therefore don't optimize it. radeonsi loads
descriptors before each use and relies on CSE to unify all equivalent
loads that are close to each other. Without CSE, the resulting code is very bad.

I was thinking that it should be possible to achieve the same effect with noalias metadata, but it seems there is some magic about the noalias attribute which is stronger than anything achievable with metadata. I haven't dug deeper into what that is, exactly.

Cheers,
Nicolai


Another interesting aspect of having the bindless descriptor array in
user SGPRs is that we can do buffer invalidations easily by
reuploading the whole array. That, however, adds a lot of overhead,
because the array is usually huge (64 bytes * 1000 slots), so it's
usually worse than the current solution (partial flushes +
WRITE_DATA). The bindless array could be packed better though.
Textures need 12 dwords, images need 8 dwords, and buffers need 4
dwords. Right now, all slots have 16 dwords.

Samuel, sorry I haven't had time to look at these patches yet.

Marek



--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to