The user SGPRs for blits are kinda a separate thing where the standard emit paths are disabled. 64-bit pointers are a short-term issue and will be removed in 2 years (or 1.5 years or when we want to kill off old LLVM support). VBO descriptors in user SGPRs will require 32-bit pointers. Next-gen will also require 32-bit pointers. The number of codepaths will be reduced to merged/non-merged and mono/non-mono again. For gfx9 and later, the only codepaths will be mono/non-mono.
There will just be a transitory period when both 32-bit and 64-bit pointers will be supported, and both the old and new way of setting up VBO descriptors will be supported. However, next-gen will only support one way - the newer way. Overall, I don't see an increase in complexity other than the transitory period. Marek On Tue, Feb 20, 2018 at 5:46 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: > With a small comment on patch 6, patches 1-8: > > Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> > > for now. > > However, I'm unhappy about how complex this is all getting. 32- vs. 64-bit, > merged vs. non-merged, monolithic vs. non-monolithic, and then special user > SGPR uses like for blits and soon VBO descriptors, it feels like it's > becoming too much. > > The problem is I don't have a good answer to it all :) > > Perhaps some of it could be helped by having an explicit userdata staging > area, i.e. > > uint32_t userdata_XX[16]; // or 32 > uint32_t userdata_XX_dirty; > > Then si_upload_descriptors would write its pointers into userdata_XX in the > right location and set the appropriate dirty bit(s), and a separate > emit_userdata function would use the contiguous bit scan to actually emit > all the userdata together -- this would include VS state bits, tess state > info, and blit shader SGPRs. > > I do think this would be cleaner especially than the current > si_emit_shader_pointer_* code, and it would coalesce more SH reg writes as a > side bonus. What do you think? > > The other half of it is how the LLVM functions are created. > > Thanks, > Nicolai > > > On 17.02.2018 20:43, Marek Olšák wrote: >> >> Hi, >> >> This series has the following effect on user SGPRs: >> >> 64-bit pointers: >> TCS: 14 -> 12 >> Merged VS-TCS: 24 -> 20 >> Merged VS-GS: 18 -> 16 >> Merged TES-GS: 18 -> 14 >> >> 32-bit pointers: >> TCS: 10 -> 8 >> Merged VS-TCS: 16 -> 12 >> Merged VS-GS: 11 -> 9 >> Merged TES-GS: 11 -> 6 >> >> I tested both monolithic and non-monolithic shaders, and both 64-bit >> and 32-bit pointers. (4 combinations) >> >> This series is a prerequisite for VBO descriptors in user SGPRs. >> >> Note that merged LS-HS and ES-GS don't even use s[6:7] input SGPRs >> yet. Those only provide 40 bits of scalar data (not 64 bits like >> s[0:1]). >> >> Please review. >> >> Thanks, >> Marek >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev >> > > > -- > 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
