https://bugs.freedesktop.org/show_bug.cgi?id=86944
--- Comment #3 from Vinson Lee ---
(In reply to Matt Turner from comment #2)
> Oh, I bet there's something wrong with the macro. I'd try removing the
> typeof(*v) cast in src/util/u_atomic.h around line 173. If that fixes it, we
> should remove t
On Fri, Dec 5, 2014 at 5:23 PM, Ben Widawsky wrote:
> On Fri, Dec 05, 2014 at 05:08:40PM -0800, Matt Turner wrote:
>> diff --git a/src/mesa/drivers/dri/i965/intel_asm_annotation.c
>> b/src/mesa/drivers/dri/i965/intel_asm_annotation.c
>> index 37ad090..ac12655 100644
>> --- a/src/mesa/drivers/dri/
On 12/06/2014 08:01 AM, Matt Turner wrote:
On Fri, Dec 5, 2014 at 8:56 PM, Vadim Girlin wrote:
On 12/06/2014 07:50 AM, Matt Turner wrote:
On Fri, Dec 5, 2014 at 8:13 PM, Vadim Girlin
wrote:
I suspect we should rather get rid of such loops somehow, i.e. convert to
something else, the loop t
On 12/05/2014 09:34 PM, Ben Widawsky wrote:
> On Fri, Dec 05, 2014 at 08:57:27PM -0800, Ian Romanick wrote:
>> On 12/05/2014 05:23 PM, Ben Widawsky wrote:
>>> On Fri, Dec 05, 2014 at 05:08:40PM -0800, Matt Turner wrote:
---
Eric was against making this the default when I first suggested a
On Fri, Dec 05, 2014 at 08:57:27PM -0800, Ian Romanick wrote:
> On 12/05/2014 05:23 PM, Ben Widawsky wrote:
> > On Fri, Dec 05, 2014 at 05:08:40PM -0800, Matt Turner wrote:
> >> ---
> >> Eric was against making this the default when I first suggested a flag.
> >> Have opinions changed since then? I
On Fri, Dec 5, 2014 at 8:56 PM, Vadim Girlin wrote:
> On 12/06/2014 07:50 AM, Matt Turner wrote:
>>
>> On Fri, Dec 5, 2014 at 8:13 PM, Vadim Girlin
>> wrote:
>>>
>>> I suspect we should rather get rid of such loops somehow, i.e. convert to
>>> something else, the loop that never repeats is not re
On 12/05/2014 05:23 PM, Ben Widawsky wrote:
> On Fri, Dec 05, 2014 at 05:08:40PM -0800, Matt Turner wrote:
>> ---
>> Eric was against making this the default when I first suggested a flag.
>> Have opinions changed since then? I rarely use the annotations, and they
>> do make the assembly harder to
On 12/06/2014 07:50 AM, Matt Turner wrote:
On Fri, Dec 5, 2014 at 8:13 PM, Vadim Girlin wrote:
I suspect we should rather get rid of such loops somehow, i.e. convert to
something else, the loop that never repeats is not really a loop anyway.
AFAICS "continue" is not supported in switch statemen
On Fri, Dec 5, 2014 at 8:13 PM, Vadim Girlin wrote:
> I suspect we should rather get rid of such loops somehow, i.e. convert to
> something else, the loop that never repeats is not really a loop anyway.
> AFAICS "continue" is not supported in switch statements according to GLSL
> specs, so the loo
On 12/04/2014 01:43 AM, Dave Airlie wrote:
Hi Vadim,
I've been looking with Glenn's help into a bug in sb for a couple of
weeks now triggered by a change in how GLSL generates switch
statements.
I understand you probably aren't too interested in r600g but I believe
I'm hitting a design level pr
On Fri, Dec 05, 2014 at 06:56:27PM -0800, Matt Turner wrote:
> On Fri, Dec 5, 2014 at 6:18 PM, Vinson Lee wrote:
> > This patch fixes this build error with GCC <= 4.6.
> >
> > CXXtest_vf_float_conversions.o
> > test_vf_float_conversions.cpp: In function ???unsigned int f2u(float)???:
> > tes
Hi,
this might be a stupid question, but if you use opengl fill mode line /
point are the shared edges/vertices in strip (or fan) primitives drawn
multiple times? My pedantic reading of the spec would seem to say yes
(because it essentially says tri strips form individual triangles for
rasterizati
On Fri, Dec 05, 2014 at 06:56:27PM -0800, Matt Turner wrote:
> On Fri, Dec 5, 2014 at 6:18 PM, Vinson Lee wrote:
> > This patch fixes this build error with GCC <= 4.6.
> >
> > CXXtest_vf_float_conversions.o
> > test_vf_float_conversions.cpp: In function ‘unsigned int f2u(float)’:
> > test_vf
On Fri, Dec 5, 2014 at 6:18 PM, Vinson Lee wrote:
> This patch fixes this build error with GCC <= 4.6.
>
> CXXtest_vf_float_conversions.o
> test_vf_float_conversions.cpp: In function ‘unsigned int f2u(float)’:
> test_vf_float_conversions.cpp:63:20: error: expected primary-expression
> befor
This patch fixes this build error with GCC <= 4.6.
CXXtest_vf_float_conversions.o
test_vf_float_conversions.cpp: In function ‘unsigned int f2u(float)’:
test_vf_float_conversions.cpp:63:20: error: expected primary-expression before
‘.’ token
Bugzilla: https://bugs.freedesktop.org/show_bug.c
On Thu, Dec 04, 2014 at 10:02:25PM -0800, Kristian Høgsberg wrote:
> Now that the caller passes in the shader debug name, we don't need this
> anymore.
>
> Signed-off-by: Kristian Høgsberg
Up through here all looks fine to me. I do like Jason's suggestion for patch 1.
(I also don't really see th
On Thu, Dec 4, 2014 at 7:07 PM, Ian Romanick wrote:
> On 12/04/2014 04:37 PM, Matt Turner wrote:
>> The LINE instruction performs a multiply-add instruction (a * b + c)
>> where b and c are scalar arguments. It reads b and c from offsets in
>> src0 such that you can load them (it they're represent
On Fri, Dec 05, 2014 at 05:08:40PM -0800, Matt Turner wrote:
> ---
> Eric was against making this the default when I first suggested a flag.
> Have opinions changed since then? I rarely use the annotations, and they
> do make the assembly harder to read, when the assembly is what you're
> intereste
All uses of this require that the value be at least one, so it's
easier to report at least one than having to wrap all uses
in MAX2(max_compute_units, 1).
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 2 ++
2 files changed, 3 inse
---
Eric was against making this the default when I first suggested a flag.
Have opinions changed since then? I rarely use the annotations, and they
do make the assembly harder to read, when the assembly is what you're
interested in.
src/mesa/drivers/dri/i965/intel_asm_annotation.c | 2 +-
src/me
This is the maximum value allowed for this field.
---
src/gallium/drivers/radeonsi/si_compute.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 6ddb478..bf935dc 100644
--- a/src/gallium/drivers/rade
On 12/05/2014 01:54 PM, Ian Romanick wrote:
> On 12/05/2014 01:50 PM, Matt Turner wrote:
>> On Fri, Dec 5, 2014 at 1:48 PM, Ian Romanick wrote:
>>> On 12/05/2014 01:42 PM, Matt Turner wrote:
On Fri, Dec 5, 2014 at 1:25 PM, Ian Romanick wrote:
> On 12/05/2014 01:17 PM, Carl Worth wrote:
>
THis way we get a warning if an enum value is not handled
v2: codestyle
Signed-off-by: Jan Vesely
Reviewed-by: Francisco Jerez
---
src/gallium/state_trackers/clover/core/kernel.cpp | 44 ++-
1 file changed, 19 insertions(+), 25 deletions(-)
diff --git a/src/gallium/state_t
On 12/05/2014 01:50 PM, Matt Turner wrote:
> On Fri, Dec 5, 2014 at 1:48 PM, Ian Romanick wrote:
>> On 12/05/2014 01:42 PM, Matt Turner wrote:
>>> On Fri, Dec 5, 2014 at 1:25 PM, Ian Romanick wrote:
On 12/05/2014 01:17 PM, Carl Worth wrote:
> Previously, if __builtin_unreachable() was un
On Fri, Dec 5, 2014 at 1:48 PM, Ian Romanick wrote:
> On 12/05/2014 01:42 PM, Matt Turner wrote:
>> On Fri, Dec 5, 2014 at 1:25 PM, Ian Romanick wrote:
>>> On 12/05/2014 01:17 PM, Carl Worth wrote:
Previously, if __builtin_unreachable() was unavailable, the
unreachable macro was defined
On 12/05/2014 01:42 PM, Matt Turner wrote:
> On Fri, Dec 5, 2014 at 1:25 PM, Ian Romanick wrote:
>> On 12/05/2014 01:17 PM, Carl Worth wrote:
>>> Previously, if __builtin_unreachable() was unavailable, the
>>> unreachable macro was defined to do nothing. We do better here, by at
>>> least still ma
On Fri, Dec 5, 2014 at 1:25 PM, Ian Romanick wrote:
> On 12/05/2014 01:17 PM, Carl Worth wrote:
>> Previously, if __builtin_unreachable() was unavailable, the
>> unreachable macro was defined to do nothing. We do better here, by at
>> least still making it an assert.
>> ---
>> src/util/macros.h |
On Fri, Dec 05, 2014 at 01:36:52PM -0800, Matt Turner wrote:
> On Fri, Dec 5, 2014 at 1:34 PM, Ben Widawsky wrote:
> > I do wonder the original motivation for the debug_flag member. Seems totally
> > superfluous.
>
> Because brw_fs_generator is used by the fs and by blorp, and you want
> differen
On 12/05/2014 01:17 PM, Carl Worth wrote:
> The unreachable macro has the advantage (for modern compilers) of
> hinting to the compiler that this code is actually unreachable, which
> can help reduce spurious warnings, etc.
>
> Also, this version is a bit easier to type correctly and understand
>
On Fri, Dec 5, 2014 at 1:34 PM, Ben Widawsky wrote:
> I do wonder the original motivation for the debug_flag member. Seems totally
> superfluous.
Because brw_fs_generator is used by the fs and by blorp, and you want
different debug flags for them.
___
m
On Thu, Dec 04, 2014 at 10:02:24PM -0800, Kristian Høgsberg wrote:
> fs_generator no longer knows what stage it's generating code for, so
> we have to set the debug name of the shader from the call site.
>
> Signed-off-by: Kristian Høgsberg
> ---
> src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
On 12/05/2014 01:17 PM, Carl Worth wrote:
> Previously, if __builtin_unreachable() was unavailable, the
> unreachable macro was defined to do nothing. We do better here, by at
> least still making it an assert.
> ---
> src/util/macros.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
Series is
Reviewed-by: Ian Romanick
I like Eric's suggestions for patch 2, but I think those could be a
follow-on patch.
On 12/03/2014 10:24 AM, Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i915/intel_context.h | 2 ++
> src/mesa/drivers/dri/i915/intel_fbo.c | 1 +
> src/mesa/drivers/dr
The unreachable macro has the advantage (for modern compilers) of
hinting to the compiler that this code is actually unreachable, which
can help reduce spurious warnings, etc.
Also, this version is a bit easier to type correctly and understand
when reading without that seemingly out-of-place logic
Previously, if __builtin_unreachable() was unavailable, the
unreachable macro was defined to do nothing. We do better here, by at
least still making it an assert.
---
src/util/macros.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/macros.h b/src/util/macros.h
index 5
On Thu, Dec 4, 2014 at 10:02 PM, Kristian Høgsberg
wrote:
> We don't propagate the saturate bit and some instructions can't
> saturate at all. If the source has saturate set, just skip propagation.
>
I think the commit message could use some help.
The real point is that copy propagation propag
On Fri, Dec 5, 2014 at 10:24 AM, Matt Turner wrote:
> On Fri, Dec 5, 2014 at 7:02 AM, Jason Ekstrand
> wrote:
> > First off, how is this different from the sel peephole?
>
> This happens in the visitor during translation from GLSL IR to FS IR.
> It only looks for an exact sequence of IF/MOV/ELSE
Ahh the comment referred to that part of the code...
Yes indeed looks better.
Roland
Am 05.12.2014 um 19:35 schrieb Jose Fonseca:
> What I mean is, instead of
>
> if (switch_order) {
> FOO(l_src, r)
> } else {
> FOO(r, l_src,)
> }
>
>...
>
> if (switch_order) {
> BO
What I mean is, instead of
if (switch_order) {
FOO(l_src, r)
} else {
FOO(r, l_src,)
}
...
if (switch_order) {
BOO(l_src, r)
} else {
BOO(r, l_src,)
}
simply do
op1 = l_src,
op2 = r;
if (switch_order) {
op1 = r;
op2 = l_src
}
FOO
On Fri, Dec 5, 2014 at 7:02 AM, Jason Ekstrand wrote:
> First off, how is this different from the sel peephole?
This happens in the visitor during translation from GLSL IR to FS IR.
It only looks for an exact sequence of IF/MOV/ELSE/MOV/ENDIF where the
MOVs are to the same destination.
The peeph
On Thu, Dec 4, 2014 at 11:22 PM, Kenneth Graunke wrote:
> On Friday, November 21, 2014 10:23:43 AM Matt Turner wrote:
>> On Tue, Nov 11, 2014 at 9:41 AM, Matt Turner wrote:
>> > The rest of our backend optimizations have replaced the need for this
>> > since it was written.
>> >
>> > instructions
I am not quite sure what formulation do you suggest? This one seemed
about as simple as any other one I could quickly come up with. (though
the switch_order = false statements are redundant as they are the
default, so if you prefer that they can easily be killed, and the "if
(expr->operation == ir_
https://bugs.freedesktop.org/show_bug.cgi?id=86788
--- Comment #9 from José Fonseca ---
I pushed a quick fix on a1fc6a91e5c6ab098fa8576e63b3a070852aa2a7 .
Though I have to say I'm a bit disappointed that pointing out the
problem/solution wasn't enough: I had to prepare the fix myself, and that m
I re-submitted the patch according with suggested corrections.
Thank you,
Valentin Corfu
On 29.11.2014 07:53, Matt Turner wrote:
On Thu, Nov 27, 2014 at 1:59 AM, Valentin Corfu wrote:
With this check we can avoid segmentation fault when invalid value used during
eglCreateContext.
Cc: mesa-
On Fri, 5 Dec 2014, Mario Kleiner wrote:
Wrt. 2/5: It's a bit ambiguous how to read that bit of the spec, and i agree
that one could read it in a way that the current mesa dri3 behaviour is not
(completely) violating the spec. When we implemented the DRI2 version, we
understood it in the way
On Dec 4, 2014 11:22 PM, "Kenneth Graunke" wrote:
>
> On Friday, November 21, 2014 10:23:43 AM Matt Turner wrote:
> > On Tue, Nov 11, 2014 at 9:41 AM, Matt Turner wrote:
> > > The rest of our backend optimizations have replaced the need for this
> > > since it was written.
> > >
> > > instruction
On Fri, Dec 5, 2014 at 9:29 AM, Jose Fonseca wrote:
> On 05/12/14 14:18, Ilia Mirkin wrote:
>>
>> On Fri, Dec 5, 2014 at 9:16 AM, Jose Fonseca wrote:
>>>
>>> From: José Fonseca
>>>
>>> Matches what u_vbuf_get_minmax_index() does.
>>
>>
>> Hm, nouveau nv50 (and probably nvc0) does:
>>
>>i
On 05/12/14 14:18, Ilia Mirkin wrote:
On Fri, Dec 5, 2014 at 9:16 AM, Jose Fonseca wrote:
From: José Fonseca
Matches what u_vbuf_get_minmax_index() does.
Hm, nouveau nv50 (and probably nvc0) does:
if (ib->buffer) {
nv50->idxbuf.offset = ib->offset;
BCTX_REFN(nv50
On Fri, Dec 5, 2014 at 9:18 AM, Ilia Mirkin wrote:
> On Fri, Dec 5, 2014 at 9:16 AM, Jose Fonseca wrote:
>> From: José Fonseca
>>
>> Matches what u_vbuf_get_minmax_index() does.
>
> Hm, nouveau nv50 (and probably nvc0) does:
>
> if (ib->buffer) {
> nv50->idxbuf.offset = ib->offset
On 05/12/14 14:12, Ilia Mirkin wrote:
On Fri, Dec 5, 2014 at 9:10 AM, Jose Fonseca wrote:
On 05/12/14 00:01, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
Cc: "10.4 10.3"
---
src/gallium/auxiliary/indices/u_primconvert.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Fri, Dec 5, 2014 at 9:16 AM, Jose Fonseca wrote:
> From: José Fonseca
>
> Matches what u_vbuf_get_minmax_index() does.
Hm, nouveau nv50 (and probably nvc0) does:
if (ib->buffer) {
nv50->idxbuf.offset = ib->offset;
BCTX_REFN(nv50->bufctx_3d, INDEX, nv04_resource(ib->bu
From: José Fonseca
Matches what u_vbuf_get_minmax_index() does.
---
src/gallium/auxiliary/indices/u_primconvert.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/indices/u_primconvert.c
b/src/gallium/auxiliary/indices/u_primconvert.c
index 4632781..eb
On Fri, Dec 5, 2014 at 9:10 AM, Jose Fonseca wrote:
> On 05/12/14 00:01, Ilia Mirkin wrote:
>>
>> Signed-off-by: Ilia Mirkin
>> Cc: "10.4 10.3"
>> ---
>> src/gallium/auxiliary/indices/u_primconvert.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/auxil
On 05/12/14 00:01, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
Cc: "10.4 10.3"
---
src/gallium/auxiliary/indices/u_primconvert.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/indices/u_primconvert.c
b/src/gallium/auxiliary/indices/u_primconvert.
Looks good AFAICT.
But I think we should probably swap the operands only once, in one
place, instead of having two branches for switch_order.
Jose
On 04/12/14 23:25, srol...@vmware.com wrote:
From: Roland Scheidegger
The original idea was to optimize away the condition by integrating it di
On 12/05/2014 03:41 AM, Eric Anholt wrote:
Mario Kleiner writes:
A slightly updated and extended series of the dri3/present fixes for Mesa i
sent last week.
Patch 1 and 2 are same as before. Patch 3 now has signed off by Frank Binns
and reviewed by Chris Wilson. Patch 4 and 5 are additional f
Hi,
On 12/04/2014 11:38 PM, Mario Kleiner wrote:
On 12/04/2014 11:20 AM, Axel Davy wrote:
On 02/12/2014 20:53, Mario Kleiner wrote :
Restores proper immediate tearing swap behaviour for
OpenGL bufferswap under DRI3/Present.
+ if (priv->swap_interval == 0)
+ options |= XCB_PRESE
57 matches
Mail list logo
