[virglrenderer-devel] [PATCH 0/4] Refactor vrend_shader, part I

[Gurchetan Singh]

On Tue, May 8, 2018 at 3:34 PM, Dave Airlie <airlied at gmail.com> wrote:
> On 9 May 2018 at 05:06, Gurchetan Singh <gurchetansingh at chromium.org> 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’":

def bfi(base, insert, offset, bits):
       ....
       return ((insert << offset) & mask) | (base & ~mask)

http://gallium.readthedocs.io/en/latest/tgsi.html


> So I'm not if we should put more effort into landing the branches then
> doing the cleanup.

I've only looked at the GLES31 branch, and I think that would benefit
from a clean-up before we try to land it.  Almost all the tests I ran
failed, and many of errors were conversion related -- it could be
useful to abstract them away.

When do you expect the fp64 and arb_gpu_shader5 branches to land?  If
they are in a better state and ready to go, it's reasonable to hold
off on refactoring.

>
> Dave.