[Mesa-dev] [PATCH 2/4] gallium: add new properties for clip and cull distance usage
Roland Scheidegger
sroland at vmware.com
Mon Oct 19 17:27:44 PDT 2015
Am 20.10.2015 um 01:26 schrieb Marek Olšák:
> On Tue, Oct 20, 2015 at 12:03 AM, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 19.10.2015 um 23:44 schrieb Marek Olšák:
>>> On Mon, Oct 19, 2015 at 11:31 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>>>> Yes, but I still don't see much change from getting this information
>>>> from the property rather than how tgsi_scan does it now, which is by
>>>> just using the usage mask from the output declaration. So the writes
>>>> shouldn't have to be analyzed.
>>>> (There's also a slight change in patch 4/4, namely these outputs
>>>> absolutely must be in order (xyzw) now as usage mask is determined
>>>> solely by the number of values. That might already have been the case at
>>>> least for some drivers and is probably ok for other state trackers too,
>>>> it wasn't in the docs however.)
>>>
>>> DCL OUT[1..2], ARRAY(1), CLIPDIST
>>>
>>> CLIPDIST became an array declaration recently, so the usage mask isn't
>>> useful unless it's extended to 8 bits.
>> Oh, when and how did that happen? I totally can't find such a change
>> (hence my confusion). The docs don't really reflect that neither.
>> But I agree if that's the case then indeed this change looks good.
>> Albeit I don't think everybody could deal with clipdist being an array
>> suddenly now...
>
> There was a change required for proper indirect addressing that
> changed all inputs and outputs to array declarations for all variables
> that were arrays in GLSL.
>
> If PIPE_SHADER_CAP_TGSI_ANY_INOUT_DECL_RANGE == 0, tgsi/ureg unwinds
> all incoming in/out arrays into simple declarations.
>
> So it's optional until all drivers support that cap.
Ah I see now. I missed that, there's some code in st_program.c which
will use individual clip dist outputs but I guess it gets changed into
an array later at another place (looks certainly confusing).
So this series looks ok then.
Roland
>
> Marek
>
More information about the mesa-dev
mailing list