On 08/28/2018 12:40 PM, Ian Romanick wrote:
> On 08/28/2018 12:09 PM, Rogovin, Kevin wrote:
>> Hi,
>>
>>> Is that tested?
>>
>> I have tested it in a simple shader test I made (i.e. not in a dedicated
>> test suite such as dEQP, piglit or something else). The created assembly is
>> identical.
On Tue, Aug 28, 2018 at 4:13 PM Rogovin, Kevin
wrote:
> Hi,
>
> > You are completely missing the point. Any test which tests the
> > GL_ARB_fragment_shader_interlock extension with a
> > beginInvocationInterlockARB() call inside of control-flow would be an
> > invalid test for
riginal Message-
From: Rogovin, Kevin
Sent: Tuesday, August 28, 2018 10:10 PM
To: 'mesa-dev@lists.freedesktop.org'
Cc: ja...@jlekstrand.net
Subject: [Mesa-dev] [PATCH 0/2] Implement INTEL_fragment_shader_ordering
Hi,
> Is that tested?
I have tested it in a simple shader test I made (i.e. n
Kevin,
Your email messages are missing the in-reply-to header, making this
thread completely incomprehensible on the mailing list.
Please fix your mail client to include the standard headers so we can
follow what you are saying.
-Mark
"Rogovin, Kevin" writes:
> Hi,
>
>> Having the same
On 08/28/2018 12:09 PM, Rogovin, Kevin wrote:
> Hi,
>
>> Is that tested?
>
> I have tested it in a simple shader test I made (i.e. not in a dedicated test
> suite such as dEQP, piglit or something else). The created assembly is
> identical. The specific example is a shader where I replace
On Tue, Aug 28, 2018 at 2:10 PM Rogovin, Kevin
wrote:
> Hi,
>
> > Is that tested?
>
> I have tested it in a simple shader test I made (i.e. not in a dedicated
> test suite such as dEQP, piglit or something else). The created assembly is
> identical. The specific example is a shader where I
Hi,
> Is that tested?
I have tested it in a simple shader test I made (i.e. not in a dedicated test
suite such as dEQP, piglit or something else). The created assembly is
identical. The specific example is a shader where I replace calls of
beginFragmentShaderOrderingINTEL() with
On Tue, Aug 28, 2018 at 1:23 PM Rogovin, Kevin
wrote:
> Hi,
>
> > Having the same underlying compiler intrinsic and having the same
> behavior
> > are not the same thing. The INTEL extension allows strictly more
> > functionality than the ARB extension so it needs even more testing. In
> >
Hi,
> Having the same underlying compiler intrinsic and having the same behavior
> are not the same thing. The INTEL extension allows strictly more
> functionality than the ARB extension so it needs even more testing. In
> particular, it allows you to do the barrier in non-uniform control-flow
"Works on an app" is not and never has been an acceptable testing plan for
landing a new feature in Mesa. There need to be tests in piglit, dEQP, or
one of the conformance suites.
--Jason
On Tue, Aug 28, 2018 at 11:15 AM Rogovin, Kevin
wrote:
> Hi,
>
> On the questions of tests: If people
On Tue, Aug 28, 2018 at 11:22 AM Manolova, Plamena <
plamena.manol...@intel.com> wrote:
> Hi Mark,
> AFAIK there is no piglit test for this specific extension. However
> underneath the hood it reuses the
> functionality of ARB_fragment_shader_interlock, which has a test. I
> believe the only
"Manolova, Plamena" writes:
> Hi Mark,
> AFAIK there is no piglit test for this specific extension. However
> underneath the hood it reuses the functionality of
> ARB_fragment_shader_interlock, which has a test. I believe the only
> major difference between the two extensions is that unlike
>
Hi,
On 28.08.2018 19:15, Rogovin, Kevin wrote:
On the questions of tests: If people want, I can adapt the test in piglit for
ARB_fragment_shader_interlock to this INTEL one. In general, I have an
app/library that uses the extension and testing of that does definitely work on
i965 (which
Hi Mark,
AFAIK there is no piglit test for this specific extension. However
underneath the hood it reuses the
functionality of ARB_fragment_shader_interlock, which has a test. I believe
the only major difference between
the two extensions is that unlike beginInvocationInterlockARB,
@lists.freedesktop.org
Cc: Jerez Plata, Francisco
Subject: Re: [Mesa-dev] [PATCH 0/2] Implement INTEL_fragment_shader_ordering
Hi,
I followed the convention that was already present. The code from
ARB/NV_fragment_shader_interlock had an intrinsic for begin critical section
and an intrinsic for end
Hi,
On the questions of tests: If people want, I can adapt the test in piglit for
ARB_fragment_shader_interlock to this INTEL one. In general, I have an
app/library that uses the extension and testing of that does definitely work on
i965 (which should be utterly unsurprising since the
Hi,
I followed the convention that was already present. The code from
ARB/NV_fragment_shader_interlock had an intrinsic for begin critical section
and an intrinsic for end critical section. I figured that since this extension
has a completely different thinking (i.e. a memory barrier instead
Is there a piglit test that verifies that this feature works properly?
writes:
> From: Kevin Rogovin
>
> INTEL_fragment_shader_ordering provides the ability for shaders
> to issue a call to gaurnantee memory write operation ordering
> of overlapping pixels or samples. In contrast to
>
Actually ignore my comment, I forgot that docs/features.txt is for
non-vendor specific
features only. I'll go ahead and push your patches. Sorry for the confusion.
Thanks,
Pam
On Tue, Aug 28, 2018 at 1:04 PM Manolova, Plamena <
plamena.manol...@intel.com> wrote:
> Hi Kevin,
> Could you also
Hi Kevin,
Could you also mark the extension as done in docs/features.txt? Otherwise
the series looks good to me
and with that tiny change it's Reviewed-by: Plamena Manolova <
plamena.manol...@intel.com>
Thanks,
Pam
On Mon, Aug 27, 2018 at 9:56 AM wrote:
> From: Kevin Rogovin
>
>
From: Kevin Rogovin
INTEL_fragment_shader_ordering provides the ability for shaders
to issue a call to gaurnantee memory write operation ordering
of overlapping pixels or samples. In contrast to
ARB_fragment_shader_interlock, INTEL_fragment_shader_ordering
instead of defining a critical region
21 matches
Mail list logo
