https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #13 from Dieter Nützel ---
Still there.
But patch works, even with latest DRI3 updates.
--
You are receiving this mail because:
You are on the CC list for the bug.___
mesa-dev mailing lis
On Tue, Jan 17, 2017 at 03:17:08PM -0800, Jason Ekstrand wrote:
>I think the commit message could use some work. How about:
>i965/blorp: Use the render cache mechanism instead of explicit flusing
Sounds good, thanks!
>On Tue, Jan 17, 2017 at 10:48 AM, Topi Pohjolainen
><[1]topi.p
On 01/18/2017 06:55 AM, Kenneth Graunke wrote:
> On Tuesday, January 17, 2017 8:51:48 AM PST Eduardo Lima Mitev wrote:
>> On 01/17/2017 08:14 AM, Kenneth Graunke wrote:
>>> struct brw_cache_item is an implementation detail of the program cache.
>>> We don't need to make those internals available to
On 12 December 2016 at 10:11, wrote:
> From: Roland Scheidegger
>
> By using a dst_type in the the gather interface, gather has some more
> knowledge about how values should be fetched.
> E.g. if this is a 3x32bit fetch and dst_type is 4x32bit vector gather
> will no longer do a ZExt with a 96bi
On Tuesday, January 17, 2017 8:51:48 AM PST Eduardo Lima Mitev wrote:
> On 01/17/2017 08:14 AM, Kenneth Graunke wrote:
> > struct brw_cache_item is an implementation detail of the program cache.
> > We don't need to make those internals available to the entire driver.
> >
> > Signed-off-by: Kennet
Seem this breaks a bunch of interpolation related tests for some
reason. But my main aim was to get thoughts on these numbers and if we
are ready to switch this stuff off.
On Wed, 2017-01-18 at 13:12 +1100, Timothy Arceri wrote:
> Run time for shader-db on my machine goes from ~750 seconds to
> ~6
Previously the last stage would not get optimised until the backend did
its GLSL IR opt loop. I plan on removing that from i965 shortly which
caused huge regressions in Deus-ex and Tomb Raider which have large
constant arrays. Moving lowering before the opt loop in the GLSL linker
fixes this and un
On 18/01/17 07:47 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/drivers/radeon/r600_texture.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_texture.c
> b/src/gallium/drivers/radeon/r600_texture.c
> index cba4e7d.
Classically, global code motion is also a dead code pass. However, in
the initial implementation, the decision was made to place every
instruction and let conventional DCE clean up the dead ones. Because
any uses of a dead instruction are unreachable, we have no late block
and the dead instructio
---
src/compiler/nir/nir_opt_gcm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/compiler/nir/nir_opt_gcm.c b/src/compiler/nir/nir_opt_gcm.c
index 9d61c65..80e34e1 100644
--- a/src/compiler/nir/nir_opt_gcm.c
+++ b/src/compiler/nir/nir_opt_gcm.c
@@ -292,6 +292,8 @@ gcm_choose_block_for_
Shader-db results on Sky Lake (Excluding Deus Ex: Mankind Divided):
total instructions in shared programs: 11724449 -> 11706852 (-0.15%)
instructions in affected programs: 1218950 -> 1201353 (-1.44%)
helped: 2562
HURT: 1208
total cycles in shared programs: 109388578 -> 108934482 (-
Now that the GCM pass is more concervative and only moves instructions
to different blocks when it's advantageous to do so, we can have a
proper notion of what it means to make progress.
---
src/compiler/nir/nir_opt_gcm.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff
We are about to adjust our instruction block assignment algorithm and we
will want to know the current block that the instruction lives in. In
order to allow for this, we can't overwrite nir_instr::block in the
early scheduling pass.
---
src/compiler/nir/nir_opt_gcm.c | 52 +++
This patch series has a bunch of fixes and refactors for the global code
motion pass in NIR. The patch to dominance is needed for correctness while
most of the rest of them are just cleanups or exist to enable patch 7
without regressions. With the exception of "Deus Ex: Mankind Divided", the
numb
---
src/compiler/nir/nir.h | 9 -
src/compiler/nir/nir_dominance.c | 37 ++---
2 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 8d6f7d1..fc18b58 100644
--- a/src/compiler/nir/nir
Now that we have the new block iterators, we can simplify things a bit.
---
src/compiler/nir/nir_opt_gcm.c | 138 -
1 file changed, 68 insertions(+), 70 deletions(-)
diff --git a/src/compiler/nir/nir_opt_gcm.c b/src/compiler/nir/nir_opt_gcm.c
index 879a77a.
---
src/compiler/nir/nir_opt_gcm.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/src/compiler/nir/nir_opt_gcm.c b/src/compiler/nir/nir_opt_gcm.c
index 3448154..5bc3ff0 100644
--- a/src/compiler/nir/nir_opt_gcm.c
+++ b/src/compiler/nir/nir_op
This number was chosen in an attempt to match the limits applied to
GLSL IR.
The following patch will disbale the GLSL IR optimisation loop in the i965
backend resulted in 4 loops from The Talos Principle failing to unroll.
Bumping the limit allows them to unroll which results in the instruction
c
If one of the inputs to and mul/add is the result of an another
mul/add there is a chance that we can reuse the result of that
mul/add in other calls if we do the multiplication in the right
order.
Also by attempting to move all constants to the top we increase
the chance of constant folding.
Fo
This shuffles constants down in the reverse of what the previous
patch does and applies some simpilifications that may be made
possible from doing so.
Shader-db results BDW:
total instructions in shared programs: 12978405 -> 12975412 (-0.02%)
instructions in affected programs: 279862 -> 276869 (-
Run time for shader-db on my machine goes from ~750 seconds to
~630 seconds.
shader-db results BDW:
total instructions in shared programs: 12968880 -> 12968298 (-0.00%)
instructions in affected programs: 1467035 -> 1466453 (-0.04%)
helped: 3632
HURT: 3331
total cycles in shared programs: 2465014
Didn't turn out as useful as I'd hoped, but it will help alot more on
i965 by reducing regressions when we drop brw_do_channel_expressions()
and brw_do_vector_splitting().
I'm not sure how much sense 'is_not_used_by_conditional' makes on
platforms other than i965 but since this is a new opt it at
Here we also drop the GLSL IR loop in the i965 linker in
favour of a single do_dead_code() call.
I think the numbers are looking pretty good.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-d
From: Marek Olšák
v2: now it should be correct
---
src/gallium/drivers/radeonsi/si_descriptors.c | 8
src/gallium/drivers/radeonsi/si_state.c | 6 ++
src/gallium/drivers/radeonsi/si_state.h | 1 +
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/galliu
On 01/12/2017 02:47 PM, Matteo Bruni wrote:
> 2017-01-12 23:41 GMT+01:00 Axel Davy :
>>> Do you refer to the d3d9 MAD or the hardware instruction? If the
>>> former, just generating MUL and ADD separately should do the trick. In
>>> the latter case, I guess that means the "NaN switch" should also
>
2017-01-18 1:31 GMT+08:00 Brian Paul :
> On 01/17/2017 06:44 AM, Boyan Ding wrote:
>>
>> st will only add back buffer attachment to window framebuffer when
>> visual is in double-buffer mode. However, some applications may
>> render to front buffer even if they have chosen a double-buffer visual.
>
On Tuesday, January 17, 2017 8:48:22 PM PST Topi Pohjolainen wrote:
> Current blorp logic issues unconditional "flush everything"
> (see brw_emit_mi_flush()) after each render. For example, all
> blits issue this unconditionally which shouldn't be needed if
> they set render cache properly os that
Samuel Iglesias Gonsálvez writes:
> The hardware applies the same channel enable signals to both halves of
> the compressed instruction which will be just wrong under non-uniform
> control flow. Fix this by splitting those instructions to SIMD4.
>
> Signed-off-by: Samuel Iglesias Gonsálvez
> ---
On Tuesday, January 17, 2017 8:48:24 PM PST Topi Pohjolainen wrote:
> Blits do not need any special treatment as the target buffer
> object is added to render cache just as one does for normal draw.
> Color clears and resolves in turn require explicit "end of pipe
> synchronization". It is not clea
Francisco Jerez writes:
> Samuel Iglesias Gonsálvez writes:
>
>> From: "Juan A. Suarez Romero"
>>
>> When converting a DF to F, we set dst stride to 2, to fulfil alignment
>> restrictions.
>>
>> But in IVB/BYT, this is not necessary, as each DF conversion already
>> writes 2 F, the first one th
I think the commit message could use some work. How about:
i965/blorp: Use the render cache mechanism instead of explicit flusing
On Tue, Jan 17, 2017 at 10:48 AM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:
> by replacing brw_emit_mi_flush() with brw_render_cache_set_check_flush().
>
On Tue, Jan 17, 2017 at 10:48 AM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:
> Current blorp logic issues unconditional "flush everything"
> (see brw_emit_mi_flush()) after each render. For example, all
> blits issue this unconditionally which shouldn't be needed if
> they set render ca
"Juan A. Suarez Romero" writes:
> On Tue, 2017-01-17 at 11:34 +0100, Juan A. Suarez Romero wrote:
>> > The above does not necessarily sum to "we shouldn't fix it" but it
>> > probably does mean it's low-priority at best and we need to be careful.
>> >
>> > Looking a bit into the math of atan2,
Matt Turner writes:
> On Tue, Jan 17, 2017 at 2:38 PM, Francisco Jerez
> wrote:
>> Matt Turner writes:
>>
>>> On Tue, Jan 17, 2017 at 11:40 AM, Francisco Jerez
>>> wrote:
Kenneth Graunke writes:
> (Co-authored by Matt Turner.)
>
> Image atomics, for example, return a v
On Wed, 2017-01-18 at 09:50 +1100, Timothy Arceri wrote:
> Previously the last stage would not get optimised until the backend
> did
> its GLSL IR opt loop.
Wait that would be all stages would not get optimised until the backend
called the glsl ir opts. Forgot we worked on a stage at a time for a
On Tue, Jan 17, 2017 at 2:38 PM, Francisco Jerez wrote:
> Matt Turner writes:
>
>> On Tue, Jan 17, 2017 at 11:40 AM, Francisco Jerez
>> wrote:
>>> Kenneth Graunke writes:
>>>
(Co-authored by Matt Turner.)
Image atomics, for example, return a value - but the shader may not
w
Previously the last stage would not get optimised until the backend did
its GLSL IR opt loop. I plan on removing that from i965 shortly which
caused huge regressions in Deus-ex and Tomb Raider which have large
constant arrays. Moving lowering before the opt loop in the GLSL linker
fixes this and un
From: Marek Olšák
Only vertex buffers use a separate bool flag.
---
src/gallium/drivers/radeonsi/si_descriptors.c | 85 +++
src/gallium/drivers/radeonsi/si_pipe.h| 2 +
src/gallium/drivers/radeonsi/si_state.h | 2 -
src/gallium/drivers/radeonsi/si_state_dr
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_cp_dma.c | 12 +++-
src/gallium/drivers/radeonsi/si_pipe.h | 5 +
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_cp_dma.c
b/src/gallium/drivers/radeonsi/si_cp_dma.c
index 4c79df
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_descriptors.c | 8
src/gallium/drivers/radeonsi/si_state.c | 6 ++
src/gallium/drivers/radeonsi/si_state.h | 1 +
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descrip
From: Marek Olšák
the next commit will use it in a clever way, because the CP DMA prefetch
doesn't need this.
---
src/gallium/drivers/radeonsi/si_cp_dma.c | 24 ++--
src/gallium/drivers/radeonsi/si_pipe.h | 1 +
2 files changed, 15 insertions(+), 10 deletions(-)
diff --gi
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_texture.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index cba4e7d..971e40a 100644
--- a/src/gallium/drivers/radeon/r600_textu
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_descriptors.c | 5 -
src/gallium/drivers/radeonsi/si_state.c | 6 ++
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
i
From: Marek Olšák
the mutex lock is inside util_range_add.
---
src/gallium/drivers/radeonsi/si_cp_dma.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_cp_dma.c
b/src/gallium/drivers/radeonsi/si_cp_dma.c
index 06e4899..582e599 100
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.h| 20 ++--
src/gallium/drivers/radeonsi/si_state_shaders.c | 16
2 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.h
b/src/gallium/drivers
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_descriptors.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index fa3eaad..837f393 100644
--- a/src/gallium
From: Marek Olšák
If the shader selector is created with a different context than
the shader variant, we should use the calling context's target machine
for the shader variant.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99419
---
src/gallium/drivers/radeonsi/si_shader.h| 2
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_blit.c| 16 +---
src/gallium/drivers/radeonsi/si_descriptors.c | 21 +
src/gallium/drivers/radeonsi/si_pipe.h| 1 +
3 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/src/gallium/d
Matt Turner writes:
> On Tue, Jan 17, 2017 at 11:40 AM, Francisco Jerez
> wrote:
>> Kenneth Graunke writes:
>>
>>> (Co-authored by Matt Turner.)
>>>
>>> Image atomics, for example, return a value - but the shader may not
>>> want to use it. We assigned a useless VGRF destination. This seemed
On Tue, Jan 17, 2017 at 1:01 PM, Timothy Arceri
wrote:
> This number was chosen in an attempt to match the limits applied to
> GLSL IR.
>
> A recent attempt to disable the GLSL IR optimisation loop in the i965
> backend resulted in 4 loops from The Talos Principle failing to unroll.
> Bumping the
On Tue, Jan 17, 2017 at 11:40 AM, Francisco Jerez wrote:
> Kenneth Graunke writes:
>
>> (Co-authored by Matt Turner.)
>>
>> Image atomics, for example, return a value - but the shader may not
>> want to use it. We assigned a useless VGRF destination. This seemed
>> harmless, but it can actually
Samuel Iglesias Gonsálvez writes:
> From: "Juan A. Suarez Romero"
>
> Previous to Broadwell, we have 8 registers for MOV_INDIRECT.
>
> According to the IVB and HSW PRMs:
>
> "2.When the destination requires two registers and the sources are
> indirect, the sources must use 1x1 regioning mode. I
Samuel Iglesias Gonsálvez writes:
> From: "Juan A. Suarez Romero"
>
> In IVB and BYT, both regioning parameters and execution sizes are measured as
> floats.
>
> So when we have something like:
>
> mov(8) g2<1>DF g3<4,4,1>DF
>
> We are not actually moving 8 doubles (our intention), but 4 doubles
Samuel Iglesias Gonsálvez writes:
> From: Matt Turner
>
> On HSW+, scalar DF sources can be accessed using the normal <0,1,0>
> region, but on IVB and BYT DF regions must be programmed in terms of
> floats. A <0,2,1> region accomplishes this.
Any reason you're doing this here twice instead of d
Samuel Iglesias Gonsálvez writes:
> From: "Juan A. Suarez Romero"
>
> When converting a DF to F, we set dst stride to 2, to fulfil alignment
> restrictions.
>
> But in IVB/BYT, this is not necessary, as each DF conversion already
> writes 2 F, the first one the real value, and the second one a 0
This number was chosen in an attempt to match the limits applied to
GLSL IR.
A recent attempt to disable the GLSL IR optimisation loop in the i965
backend resulted in 4 loops from The Talos Principle failing to unroll.
Bumping the limit allows them to unroll which results in the instruction
count
https://bugs.freedesktop.org/show_bug.cgi?id=99442
--- Comment #2 from Hadrien ---
Created attachment 129012
--> https://bugs.freedesktop.org/attachment.cgi?id=129012&action=edit
gdb bt output
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=99442
--- Comment #1 from Hadrien ---
Created attachment 129011
--> https://bugs.freedesktop.org/attachment.cgi?id=129011&action=edit
vulkaninfo output
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=99442
Bug ID: 99442
Summary: The Talos Principle hangs with Vulkan/Radeon
Product: Mesa
Version: git
Hardware: Other
OS: Linux (All)
Status: NEW
Severity: norma
Reviewed-by: Bas Nieuwenhuizen
On Tue, Jan 17, 2017 at 9:27 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This fixes some issues we'd hit later if using viewport
> indexes.
>
> Signed-off-by: Dave Airlie
> ---
> src/amd/vulkan/radv_cmd_buffer.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> d
Samuel Iglesias Gonsálvez writes:
> From: "Juan A. Suarez Romero"
>
> The execution data size is the biggest type size of any instruction
> operand.
>
> We will use it to know if the instruction deals with DF, because in Ivy
> we need to double the execution size and regioning parameters.
>
> v2
On Tuesday, January 17, 2017 11:40:33 AM PST Francisco Jerez wrote:
> Kenneth Graunke writes:
>
> > (Co-authored by Matt Turner.)
> >
> > Image atomics, for example, return a value - but the shader may not
> > want to use it. We assigned a useless VGRF destination. This seemed
> > harmless, but
Samuel Iglesias Gonsálvez writes:
> From: Iago Toral Quiroga
>
> 4-wide DF operations where NibCtrl applies require and execsize of 8
> in IvyBridge/BayTrail.
>
> v2:
> - Refactor NibCtrl printing (Matt)
>
> Reviewed-by: Matt Turner
Reviewed-by: Francisco Jerez
> ---
> src/mesa/drivers/dri/
Typo in the subject line "an scalar".
Samuel Iglesias Gonsálvez writes:
> Then the SIMD lowering pass will get rid of any compressed instructions with
> scalar
> source (whether force_writemask_all or not) and we avoid hitting the Gen7
> region
> decompression bug.
>
> Signed-off-by: Samuel Ig
From: Dave Airlie
This fixes some issues we'd hit later if using viewport
indexes.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 27fa405..c6f238b 10
Kenneth Graunke writes:
> (Co-authored by Matt Turner.)
>
> Image atomics, for example, return a value - but the shader may not
> want to use it. We assigned a useless VGRF destination. This seemed
> harmless, but it can actually be quite harmful. The register allocator
> has to assign that VG
Eh... can you just do the release per the schedule? We don't block
releases for features, especially for very old platforms. There will be
another release soon enough.
On 01/17/2017 07:07 AM, Emil Velikov wrote:
> Hi all,
>
> As some of you may know the Intel and Igalia devs are working hard o
Blorp blits and clears use heavy hammer before and after each
operation. This is pipe control with almost all the bits set
simultaneously:
PIPE_CONTROL_RENDER_TARGET_FLUSH
PIPE_CONTROL_INSTRUCTION_INVALIDATE
PIPE_CONTROL_CONST_CACHE_INVALIDATE
PIPE_CONTROL_DEPTH_CACHE_FLUSH
PIPE_CON
Current blorp logic issues unconditional "flush everything"
(see brw_emit_mi_flush()) after each render. For example, all
blits issue this unconditionally which shouldn't be needed if
they set render cache properly os that subsequent renders do
necessary flushing before drawing.
In case of piglit:
by replacing brw_emit_mi_flush() with brw_render_cache_set_check_flush().
The latter splits the flush in two:
brw_emit_pipe_control_flush(brw,
PIPE_CONTROL_DEPTH_CACHE_FLUSH |
PIPE_CONTROL_RENDER_TARGET_FLUSH |
Blits do not need any special treatment as the target buffer
object is added to render cache just as one does for normal draw.
Color clears and resolves in turn require explicit "end of pipe
synchronization". It is not clear what this means exactly but the
assumption is that render cache flush with
instead of calling unconditionally brw_emit_mi_flush() which
does:
brw_emit_pipe_control_flush(brw,
PIPE_CONTROL_DEPTH_CACHE_FLUSH |
PIPE_CONTROL_RENDER_TARGET_FLUSH |
PIPE_CONTROL_CS_STALL);
brw
Kenneth Graunke writes:
> On Saturday, January 14, 2017 11:09:53 PM PST Francisco Jerez wrote:
>> Hi Ken!
>>
>> Kenneth Graunke writes:
>>
>> > In theory we might have incorrectly NOP'd instructions that write the
>> > flag, but where that flag value isn't used, and yet the instruction
>> > ei
On 01/17/2017 06:44 AM, Boyan Ding wrote:
st will only add back buffer attachment to window framebuffer when
visual is in double-buffer mode. However, some applications may
render to front buffer even if they have chosen a double-buffer visual.
In this case, no color buffer will be attached when
On 16 January 2017 at 14:16, Bas Nieuwenhuizen wrote:
> On Mon, Jan 16, 2017 at 2:51 PM, Emil Velikov
> wrote:
>> On 14 January 2017 at 02:31, Andres Rodriguez wrote:
>>> On Fri, Jan 13, 2017 at 8:13 PM, Emil Velikov
>>> wrote:
On 13 January 2017 at 23:44, Andres Rodriguez wrote:
>>
On Tue, Jan 17, 2017 at 9:12 PM, Emil Velikov wrote:
> On 17 January 2017 at 14:55, Nayan Deshmukh wrote:
>> On Tue, Jan 17, 2017 at 6:25 PM, Christian König
>> wrote:
>>> Hi Nayan,
>>>
>>> I've pushed this patch yesterday and this one just a minute ago.
>>>
>> Thanks for the push. I am planning
On 01/16/2017 02:32 PM, Adam Jackson wrote:
On Thu, 2017-01-05 at 14:29 -0700, Kyle Brenneman wrote:
---
src/egl/generate/eglFunctionList.py | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Reviewed-by: Adam Jackson
Is this too invasive for 13.1?
- ajax
If it helps, almost all
On Tue, Jan 17, 2017 at 1:24 AM, Juan A. Suarez Romero
wrote:
> Commit 42011be1e disabled HiZ when sharing depth buffer externally,
> which free HiZ buffer.
>
> But in emit_depth_packets() we use that buffer, which generates a crash
> in
> "piglit.spec.egl_khr_gl_image.egl_khr_gl_renderbuffer_ima
On Mon, Jan 16, 2017 at 11:59 PM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Mon, Jan 16, 2017 at 09:13:59AM -0800, Jason Ekstrand wrote:
> >On Mon, Jan 16, 2017 at 1:13 AM, Topi Pohjolainen
> ><[1]topi.pohjolai...@gmail.com> wrote:
> >
> > Signed-off-by: Topi Pohjola
On Tue, Jan 17, 2017 at 12:21 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Mon, Jan 16, 2017 at 08:33:09AM -0800, Jason Ekstrand wrote:
> >On Mon, Jan 16, 2017 at 1:13 AM, Topi Pohjolainen
> ><[1]topi.pohjolai...@gmail.com> wrote:
> >
> > There exact same check earl
On 16 January 2017 at 11:21, Nicolai Hähnle wrote:
> Emil, I'm going to follow up with a patch to try to fix the reported i915
> regression, but feel free to drop the patch from this thread from
> mesa-stable entirely. It's not an important fix.
>
Thank for the confirmation Nicolai !
-Emil
__
On 17 January 2017 at 14:55, Nayan Deshmukh wrote:
> On Tue, Jan 17, 2017 at 6:25 PM, Christian König
> wrote:
>> Hi Nayan,
>>
>> I've pushed this patch yesterday and this one just a minute ago.
>>
> Thanks for the push. I am planning on sending a similar patch for vaapi.
>
If this (and the vaapi
https://bugs.freedesktop.org/show_bug.cgi?id=92634
Nayan Deshmukh changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Hello list,
The candidate for the Mesa 12.0.5 is now available. Currently we have:
- 38 queued
- 0 nominated (outstanding)
- and 0 rejected patches
Take a look at section "Mesa stable queue" for more information.
Note: This is an extra release for the 12.0 stable branch, as per developers'
fe
On Tue, Jan 17, 2017 at 6:25 PM, Christian König
wrote:
> Hi Nayan,
>
> I've pushed this patch yesterday and this one just a minute ago.
>
Thanks for the push. I am planning on sending a similar patch for vaapi.
Regards,
Nayan
___
mesa-dev mailing list
This patch is:
Reviewed-by: Iago Toral Quiroga
On Mon, 2017-01-16 at 17:20 +0100, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> ---
> src/compiler/glsl/ir_optimization.h | 4 +++-
> src/compiler/glsl/lower_instructions.cpp | 19 +++
> 2 files changed, 14 insertions(+),
Reviewed-by: Nicolai Hähnle
On 17.01.2017 13:49, Marek Olšák wrote:
From: Marek Olšák
Cc: 17.0 13.0
---
src/gallium/drivers/radeonsi/si_shader.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeons
On 16 January 2017 at 23:38, Ben Crocker wrote:
> Reenable the PPC64LE Vector-Scalar Extension for LLVM versions >= 3.8.1,
> now that LLVM bug 26775 and its corollary, 25503, are fixed.
>
> Amendment: remove extraneous spaces in macro def & invocations.
>
> Signed-off-by: Ben Crocker
Stable ?
Cc
st will only add back buffer attachment to window framebuffer when
visual is in double-buffer mode. However, some applications may
render to front buffer even if they have chosen a double-buffer visual.
In this case, no color buffer will be attached when rendering. i965
handles this case correctly,
Hi Ben,
On 16 January 2017 at 23:31, Ben Crocker wrote:
> If llvm::sys::getHostCPUName() returns "generic", override
> it with "pwr8" (on PPC64LE).
>
> This is a work-around for a bug in LLVM: a table entry for "POWER8NVL"
> is missing, resulting in (big-endian) "generic" being returned on
> litt
On 16 January 2017 at 14:44, Jose Fonseca wrote:
> On 16/01/17 13:46, Emil Velikov wrote:
>>
>> On 14 January 2017 at 08:46, Jose Fonseca wrote:
>>>
>>> I suspect this might break builds with LLVM 3.6 or higher.
>>>
>>> The LLVMLinkInJIT must be inside #if ... #endif, and it must not be
>>> expan
Hi Nayan,
I've pushed this patch yesterday and this one just a minute ago.
Christian.
Am 16.01.2017 um 14:19 schrieb Nayan Deshmukh:
Hi Christian,
Please push this patch.
There are a couple of patches [1] which are not yet reviewed. They are
trivial and are tested by Andy. Please have a look
On 16 January 2017 at 23:24, Mauro Rossi wrote:
>>> --- a/src/gallium/Android.mk
>>> +++ b/src/gallium/Android.mk
>>> @@ -34,7 +34,9 @@ SUBDIRS += auxiliary/pipe-loader
>>> #
>>>
>>> # swrast
>>> -ifneq ($(filter swrast,$(MESA_GPU_DRIVERS)),)
>>> +ifneq ($(filter llvmpipe,$(MESA_GPU_DRIVERS)),)
On 16 January 2017 at 19:50, Ilia Mirkin wrote:
> What's the problem with using GALLIUM_DRIVER=softpipe /
> GALLIUM_DRIVER=llvmpipe to select between them?
>
Will work, but has the "update existing users" drawback.
Afaict neither scons nor autotools uses such approach, so I'd rather
keep things sy
Reviewed-by: Edward O'Callaghan
On 01/17/2017 11:49 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Cc: 17.0 13.0
> ---
> src/gallium/drivers/radeonsi/si_shader.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c
> b/src/
From: Marek Olšák
Cc: 17.0 13.0
---
src/gallium/drivers/radeonsi/si_shader.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index f404273..10f40a9 100644
--- a/src/gallium/drivers/ra
On Tue, 2017-01-17 at 11:34 +0100, Juan A. Suarez Romero wrote:
> > The above does not necessarily sum to "we shouldn't fix it" but it probably
> > does mean it's low-priority at best and we need to be careful.
> >
> > Looking a bit into the math of atan2, I'm not convinced flushing denorms to
>
I'm fine with this variant as well, so patches 1-2:
Reviewed-by: Nicolai Hähnle
On 17.01.2017 04:28, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
---
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
src/gallium/drivers/i915/i9
On Mon, 2017-01-16 at 10:21 -0800, Jason Ekstrand wrote:
> +curro
>
> I'm not sure what I think here. TBH, I haven't actually read it in detail
> yet, but here are some first impressions:
> 1) There are two implementations of atan2 (SPIR-V and GLSL) and they should
> be kept in sync. The same
Reviewed-by: Nicolai Hähnle
On 16.01.2017 21:17, Bas Nieuwenhuizen wrote:
Otherwise we read past the end of the buffer.
Signed-off-by: Bas Nieuwenhuizen
---
src/amd/common/ac_debug.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/amd/common/ac_debug.c b/src/amd/common/ac_debug.c
ind
1 - 100 of 127 matches
Mail list logo
