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

[Dave Airlie]

On 10 May 2018 at 13:48, Dave Airlie <airlied at gmail.com> wrote:
> On 9 May 2018 at 09:17, Gurchetan Singh <gurchetansingh at chromium.org> wrote:
>> 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’":
>
> 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.

Dave.