On 11/04/2016 05:37 PM, Rob Clark wrote:
On Fri, Nov 4, 2016 at 11:31 AM, Emil Velikov wrote:
On 1 November 2016 at 22:05, Rob Clark wrote:
On Tue, Nov 1, 2016 at 5:42 PM, Mauro Rossi wrote:
Mauro or Chih-Wei should be able to answer this (being do static
wallpapers work in i965?).
Rob
The mesa default is 4, but we program the hardware for 8 on all
generations.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 3085a9
Now that we also have to consider OES_viewport_array & friends, nothing uses
this.
Signed-off-by: Chris Forbes
---
src/mesa/main/get.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 5f5e76a..854f8ab 100644
--- a/src/mesa/main/get.c
+++ b/src/m
https://bugs.freedesktop.org/show_bug.cgi?id=98512
--- Comment #14 from jcamp ---
(In reply to Nicolai Hähnle from comment #13)
> I think I understand the problem.
> https://patchwork.freedesktop.org/patch/119855/ fixes the issue for me,
> could you please check that it fixes r600 as well?
Conf
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #7 from Dieter Nützel ---
(In reply to Chris Rankin from comment #1)
> I think this bug is related to DRI3, because this change "fixes" the problem:
>
> diff --git a/src/gallium/state_trackers/vdpau/device.c
> b/src/gallium/state_tra
Can you describe what this is doing? I'm confused. And I'm not sure if
the thing you're doing with blocks is the right thing either...
On Tue, Oct 25, 2016 at 3:41 PM, Samuel Pitoiset
wrote:
> Loosely based on radeonsi, thanks Nicolai!
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/gallium/driv
On Tue, Oct 25, 2016 at 3:41 PM, Samuel Pitoiset
wrote:
> Signed-off-by: Samuel Pitoiset
> ---
> src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
> b/src/gallium/driver
Primitive restart is a thing for non-indexed draws too. There's a
method that controls it - NVC0_3D_PRIM_RESTART_WITH_DRAW_ARRAYS. The
more recently GL 4.5 behaviour is to *not* do primitive restart for
draw arrays, however the older behavior is to do it. I don't think
there's clear direction on th
On Wed, Oct 26, 2016 at 4:14 AM, Samuel Pitoiset
wrote:
>
>
> On 10/25/2016 09:49 PM, Ilia Mirkin wrote:
>>
>> What if instance_count = 1M? (It can happen.)
>
>
> We allocate a giant space in the pushbuf in one shot. Well, anyways this is
> not the optimization of the year, so I can drop it. :-)
Patches 1-2 seem OK. I'm a little concerned that this one is changing
functionality, since it's removing the "need_flush" thing. It'd be
nice if you could get this patch some heavier testing before pushing
it out...
On Wed, Oct 26, 2016 at 4:00 PM, Samuel Pitoiset
wrote:
> The first goal is to re
Series is:
Reviewed-by: Ben Widawsky
On 16-10-26 11:29:51, Anuj Phogat wrote:
On Tue, Oct 25, 2016 at 4:36 PM, Ilia Mirkin wrote:
On Tue, Oct 25, 2016 at 7:09 PM, Anuj Phogat wrote:
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/i965/brw_wm.c | 4 ++--
src/mesa/drivers/dri/
There is currently no protection against walking a hash (using
_mesa_HashWalk()) and modifying it at the same time, for instance by inserting
or deleting elements. This leads to segfaults in multithreaded code if e.g.
someone calls glTexImage2D (which may have to walk the list of FBOs) while
anothe
These were racy when using the same shaders (seemingly even from different
program objects) on multiple theads sharing the same objects, leading to
issues such as (excerpts from an apitrace dump from a real application):
1097 @0 glCreateProgram() = 9
1099 @0 glAttachShader(program = 9, shader
On Mon, Nov 07, 2016 at 08:54:13AM +1100, Timothy Arceri wrote:
> The problem is is can happen totally unintentionally. Anyway I've sent
> a couple of patches as a follow-up to your series, one to fix it and
> one to make use of it.
>
> https://patchwork.freedesktop.org/series/14902/
Great, thank
On Mon, Nov 07, 2016 at 08:42:18AM +1100, Timothy Arceri wrote:
>> Interesting. So other code seemingly has done refcounting with non-
>> atomics but with locking; those locks were just missing here.
> I was trying to point you to the fact that locking is known to be
> broken in some places in case
On Sun, 2016-11-06 at 12:16 +0100, Steinar H. Gunderson wrote:
> On Sun, Nov 06, 2016 at 09:35:37AM +1100, Timothy Arceri wrote:
> >
> > Can you please change this line to say something like. With this
> > change
> > we switch to using a recursive mutex, which avoids the deadlock.
>
> Rewording.
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #6 from smoki ---
That was pure information :), as i tried to reproduce it with that old
affected one and newest which does not have an issue since it does not have
decode... so no offense, bug is there.
--
You are receiving this
Now that we use recursive locking for the hash table mutex, it is possible
to pass a callback to that remove the entry to _mesa_HashDeleteAll() without
getting stuck waiting for a lock. However we will end up removing the entry
twice and the hash table entry counts will get messed up.
To avoid mes
We no longer need this as it was just working around a locking issue
that has been fixed by switching to using recursive locking in the
hash table.
We can now just let delete_shader_cb() free the shader program data.
---
src/mesa/main/shared.c | 17 -
1 file changed, 17 deletions(
On Sun, 2016-11-06 at 12:17 +0100, Steinar H. Gunderson wrote:
> On Sun, Nov 06, 2016 at 09:40:03AM +1100, Timothy Arceri wrote:
> >
> > https://lists.freedesktop.org/archives/mesa-dev/2016-October/132629
> > .html
>
> Interesting. So other code seemingly has done refcounting with non-
> atomics
no regressions in piglit on my nve6
2016-11-06 15:05 GMT+01:00 Karol Herbst :
> This series reworks the structure of the pass to make it easier to add
> more optimisations to it.
>
> I have to rework the RA commit a bit and the post_ra_dead patch should be
> submitted on its own.
>
> v2: swaped th
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #5 from Chris Rankin ---
(In reply to smoki from comment #4)
> In couple months 11.2.x seems will cease to be supported anymore, so this
> might be time fixable... well in case they did not decide to enable VDPAU
> again :)
I don't s
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #4 from smoki ---
But yeah newer does not have VDPAU support, neither this 24 beta it seems:
http://labs.adobe.com/downloads/flashplayer.html
In couple months 11.2.x seems will cease to be supported anymore, so this
might be tim
https://bugs.freedesktop.org/show_bug.cgi?id=98604
Nayan Deshmukh changed:
What|Removed |Added
CC||mesa-dev@lists.freedesktop.
r600g: add HUD queries for shaders created and compiler invocations
for easy review, it is based on these commits for radeonsi:
70f5e49ba5ca8eb063a0d7db94fbef1585b21b2d
30a7e0c021c3a77c20c6f041dc80b7dc90ad238f
it is my first patch and I don't have commit access
tested on a richland apu with wine
Subject: [PATCH v5] gm107/ir: add LIMM form of mad
v2: renamed commit
reordered modifiers
add assert(dst == src2)
v3: reordered modifiers again
v5: no roudning bit for limms
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 34 --
.../d
After latest clover commit 'luxmark-v3.0' sigfault immediately:
SOURCE/luxmark-v3.0> ./luxmark
./luxmark.bin: /usr/local/lib/libOpenCL.so.1: no version information
available (required by ./luxmark.bin)
*** Error in `./luxmark.bin': corrupted double-linked list:
0x7f51a57829e0 ***
=== B
On 04/11/16 04:14, srol...@vmware.com wrote:
From: Roland Scheidegger
This is used by shader umul_hi/imul_hi functions (and soon by draw).
It's actually useful separating this out on its own, however the real
reason for doing it is because we're using an optimized sse2 version,
since the code l
Hello everyone,
I have been working on translating SPIR-V to NV50 IR inside Nouveau in order to
run OpenCL kernels, received as SPIR-V binaries, on Nouveau. I have some
patches for clover as well as gallium, but before sending those for review, I
would like to know how to handle the SPIR-V header
On Nov 6, 2016 9:06 AM, "Karol Herbst" wrote:
>
> v2: renamed commit
> reordered modifiers
> add assert(dst == src2)
> v3: reordered modifiers again
>
> Signed-off-by: Karol Herbst
> ---
> .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 35
--
> .../drivers/nouve
we might want to add more folding passes here, so make it a bit more generic
v2: leave the comment and reword commit message
v4: rename it to PostRaLoadPropagation
Signed-off-by: Karol Herbst
Reviewed-by: Samuel Pitoiset
---
.../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 121 +++-
v2: renamed commit
reordered modifiers
add assert(dst == src2)
v3: removed wrong neg mod emission
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 50 ++
.../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 2 +-
2 files changed, 3
changes for GpuTest /test=pixmark_piano /benchmark /no_scorebox /msaa=0
/benchmark_duration_ms=6 /width=1024 /height=640:
score: 1026 -> 1044
changes for shader-db:
total instructions in shared programs : 3499445 -> 3491273 (-0.23%)
total gprs used in shared programs: 453803 -> 453803 (0
This series reworks the structure of the pass to make it easier to add
more optimisations to it.
I have to rework the RA commit a bit and the post_ra_dead patch should be
submitted on its own.
v2: swaped the last two commits
v3: reworked order
v4: droped last two patches
Karol Herbst (4):
nv50
v2: renamed commit
reordered modifiers
add assert(dst == src2)
v3: reordered modifiers again
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 35 --
.../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 3 +-
2 files changed, 27 ins
On Sun, Nov 06, 2016 at 09:40:03AM +1100, Timothy Arceri wrote:
> https://lists.freedesktop.org/archives/mesa-dev/2016-October/132629.html
Interesting. So other code seemingly has done refcounting with non-atomics
but with locking; those locks were just missing here.
(I've skipped the finer point
On Sun, Nov 06, 2016 at 09:35:37AM +1100, Timothy Arceri wrote:
> Can you please change this line to say something like. With this change
> we switch to using a recursive mutex, which avoids the deadlock.
Rewording.
> I was a little confused. At first I thought it was already using a
> recursive
https://bugs.freedesktop.org/show_bug.cgi?id=98595
--- Comment #7 from Jonathan Gray ---
Sorry that commit was just looking over commits. An actual bisect results in
"a4a93103fb8f5c21c4cd17e89f07badfab14c0ab is the first bad commit".
glsl: use the linear allocator for ast_node and derived class
38 matches
Mail list logo
