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

[Gurchetan Singh]

I'll send out v3 in the next couple of days.


On Sun, May 27, 2018 at 7:17 PM Dave Airlie <airlied at gmail.com> wrote:

> On 11 May 2018 at 08:30, Gurchetan Singh <gurchetansingh at google.com>
> wrote:
> > On Wed, May 9, 2018 at 9:06 PM, Dave Airlie <airlied at gmail.com> wrote:
> >> 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.
> >
> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/virglrenderer-devel/attachments/20180530/9416eeaf/attachment.html>