<div dir="ltr">I'll send out v3 in the next couple of days.</div><div dir="ltr"> </div> <div class="gmail_quote"><div dir="ltr">On Sun, May 27, 2018 at 7:17 PM Dave Airlie <<a href="mailto:airlied@gmail.com" target="_blank">airlied@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11 May 2018 at 08:30, Gurchetan Singh <<a href="mailto:gurchetansingh@google.com" target="_blank">gurchetansingh@google.com</a>> wrote: > On Wed, May 9, 2018 at 9:06 PM, Dave Airlie <<a href="mailto:airlied@gmail.com" target="_blank">airlied@gmail.com</a>> wrote: >> On 10 May 2018 at 13:48, Dave Airlie <<a href="mailto:airlied@gmail.com" target="_blank">airlied@gmail.com</a>> wrote: >>> On 9 May 2018 at 09:17, Gurchetan Singh <<a href="mailto:gurchetansingh@chromium.org" target="_blank">gurchetansingh@chromium.org</a>> wrote: >>>> On Tue, May 8, 2018 at 3:34 PM, Dave Airlie <<a href="mailto:airlied@gmail.com" target="_blank">airlied@gmail.com</a>> wrote: >>>>> On 9 May 2018 at 05:06, Gurchetan Singh <<a href="mailto:gurchetansingh@chromium.org" target="_blank">gurchetansingh@chromium.org</a>> wrote: >>>>>> This series is intended to have no functional impact. This mainly >>>>>> moves code around and adds a conversion table in attempt to: >>>>>> >>>>>> - Add some abstraction to our TGSI to GLSL logic. >>>>>> - Split up large functions. >>>>>> >>>>>> This was tested with the dEQP GLES3 suite, where no regressions were >>>>>> observed. This increases the overall code line count, but may make >>>>>> subsequent changes / refactors a little easier. >>>>>> >>>>> >>>>> I think these are mostly fine, however they are going to complicate landing >>>>> any of the work we have in branches quite heavily, we have fp64, most of >>>>> arb_gpu_shader5 and a chunk of gles3.1 sitting around, this will make >>>>> landing all of that a bit more work. >>>>> >>>>> I'm also not sure about the 3 srcs, I think there are 4 srcs TGSI instructions >>>>> in my gpu_shader5 (bitfieldInsert) >>>> >>>> Only 3 srcs is based on this blurb in the documentation -- "An opcode >>>> may have up to one destination register, known as dst, and between >>>> zero and three source registers, called src0 through src2". >>>> bitfieldInsert seems to use the destination as a source since it >>>> replaces "a bit region of ‘base’ with the low bits of ‘insert’": >>> >>> Yeah unfortunately that's lies in the docs for bfi at least in the r600 driver >>> we access src[3]. tgsi_info_opcodes.h shows a few 4s in the number of >>> srcs fields. >> >> Also dst[1] is used for FREXP/DFREXP. >> >> So I'd definitely want the refactor to not go reducing those sizes. > > Thanks for the info, I'll change back the sizes when I send out v3. Hey, Is there an updated version of this yet? I'd like to at least land the first patch since it seems a lot cleaner an less error prone. I'm happy to stall fp64/tess for these cleanups at this stage, I've nearly finished tessellation now (at least it passes nearly all the piglit tests). This would allow GL4.1 support and then if we get the GLES3.1 feature work done, we'd pretty much be close to hitting GL4.5 as well. Dave. </blockquote></div>