On 11 October 2016 at 12:13, Dave Airlie <airl...@gmail.com> wrote: > On 11 October 2016 at 11:42, Dave Airlie <airl...@gmail.com> wrote: >> On 11 October 2016 at 05:50, Dave Airlie <airl...@gmail.com> wrote: >>> On 10 October 2016 at 21:45, Arsenault, Matthew >>> <matthew.arsena...@amd.com> wrote: >>>> I don't like adding explicit IR arguments for ABI arguments, especially >>>> this >>>> one. Adding a special case for the first index feels dirty. The rest of >>>> llvm >>>> also won't be aware of the specialness of the argument. It would be >>>> problematic because bugpoint would eliminate the unused argument and then >>>> codegen would have to fail in some way when the argument is missing >>>> >>> >>> We should just hardcode the behaviour and switch both radv/radeonsi >>> over in one go? >>> >>> I'll try and code up, using the first 64-bits of the first buffer >>> pointed to by userdata 0/1, >>> to store things. >> >> I've looked at doing a dword fetch from the first two words of the 0/1 >> userdata, >> >> It's not optimal for vulkan unfortunately, since the idea I had was per >> command >> buffer I just allocate one scratch buffer of the size required at the end, >> and >> patch it in at the start of the command buffer. However in the first >> slot I was going >> to use the push constants/dynamic buffer to store the value, however it looks >> like I need to keep a list of everyone of these buffers I emit, and >> backpatch them >> all. It might not be too insane, just a slight bump in the keeping it simple. > > I'm probably losing te plot here, but I'm considering a double indirection, > > we load the 64-bit address from the first two dwords, then load the > 64-bits dword > from that address to get the value. > > This saves me allocating scratch bo's for secondary command buffers, > and also having to allocating ever increasing scratch bo's as shaders that > need more scratch get bound to the pipeline. > > I'm not sure how much of an effect this should have for GL though.
I've posted a patch to this affect to the llvm phabricator. It definitely is cleaner for the radv driver. Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
