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
> > either writes the accumulator or has
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
> either writes the accumulator or has side effects.
>
> I don't believe any such instructions exist, so this is mostly a
https://bugs.freedesktop.org/show_bug.cgi?id=97921
--- Comment #4 from Maxqia ---
Possible Fix :
https://lists.freedesktop.org/archives/mesa-dev/2016-October/131135.html
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
I thought I'd fixed this already... In any case
Reviewed-by: Jason Ekstrand
you should probably cc stable
On Sat, Jan 14, 2017 at 4:23 PM, Kenneth Graunke
wrote:
> This may fix GPU hangs on Gen8. I don't know if it does though.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dr
This may fix GPU hangs on Gen8. I don't know if it does though.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/genX_blorp_exec.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
index
Renaming data sources was added in
e8bb97ce30051b999a4a69c9b27884daeb8d71e6
It was possible to use a new name longer than
the name array in hud_graph of 128. This
patch truncates the name to fit the array.
CC: Marek Olšák
---
src/gallium/auxiliary/hud/hud_context.c | 6 --
1 file changed, 4
Reviewed-by: Jason Ekstrand
On Sat, Jan 14, 2017 at 3:12 PM, Connor Abbott wrote:
> We were using impl->num_blocks, but that isn't guaranteed to be
> up-to-date until after the block_index metadata is required. If we were
> unlucky, this could lead to overwriting memory.
>
> Noticed by inspecti
We were using impl->num_blocks, but that isn't guaranteed to be
up-to-date until after the block_index metadata is required. If we were
unlucky, this could lead to overwriting memory.
Noticed by inspection.
Signed-off-by: Connor Abbott
---
src/compiler/nir/nir_opt_gcm.c | 6 +++---
1 file chang
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 | 43 +++
https://bugs.freedesktop.org/show_bug.cgi?id=99413
Bug ID: 99413
Summary: Rust game have wrong colors
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: med
On 13/01/2017 19:06, Nicolai Hähnle wrote:
On 13.01.2017 18:53, Jason Ekstrand wrote:
On Fri, Jan 13, 2017 at 8:43 AM, Marek Olšák mailto:mar...@gmail.com>> wrote:
On Fri, Jan 13, 2017 at 5:25 PM, Jason Ekstrand
mailto:ja...@jlekstrand.net>> wrote:
> On Fri, Jan 13, 2017 at 4:05 AM,
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 | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --g
The new algorithm differs from the classic GCM algorithm in that it will
prefer the instruction's original block if there are no better choices.
This new algorithm aims to be a bit more conservative and hopefully not
have quite as much of an impact on register pressure.
---
src/compiler/nir/nir_op
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 72ddc54.
---
src/compiler/nir/nir_opt_gcm.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/compiler/nir/nir_opt_gcm.c b/src/compiler/nir/nir_opt_gcm.c
index cff2315..72ddc54 100644
--- a/src/compiler/nir/nir_opt_gcm.c
+++ b/src/compiler/nir/nir_opt_gcm.c
@@ -38,6
Previous attempts to turn on global code motion and value numbering have
failed due to regressions in shader-db. Some of these regressions are
because GCM is very aggressive about moving instructions between blocks.
This series switches the GCM pass over to a different block assignment
algorithm t
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 | 43 +++
This is so that we can differentiate between flushing any framebuffer
reading caches from regular sampler caches.
Signed-off-by: Ilia Mirkin
Reviewed-by: Nicolai Hähnle
---
v1 -> v2: fix FBREAD -> FBFETCH typo
src/gallium/docs/source/context.rst | 3 ++-
src/gallium/drivers/ddebug
The extension spec is not currently published, so it's a bit premature
to require it for BlendBarrier usage.
Signed-off-by: Ilia Mirkin
---
src/mesa/main/barrier.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/barrier.c b/src/mesa/main/barrier.c
index 2f5b45
We don't need to support all the color buffers for advanced blend, just
cb0. For Fermi, we use the special binding slots so that we don't
overlap with user textures, while Kepler+ gets a dedicated position for
the fb handle in the driver constbuf.
This logic is only triggered when a FBFETCH is act
Signed-off-by: Ilia Mirkin
---
v1 -> v2: reword FBFETCH opcode to make it more explicit how it is allowed to
operate
src/gallium/auxiliary/tgsi/tgsi_info.c | 2 +-
src/gallium/docs/source/tgsi.rst | 13 +
src/gallium/include/pipe/p_shader_tokens.h | 2 +-
3 files ch
Signed-off-by: Ilia Mirkin
---
src/compiler/glsl/lower_output_reads.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/glsl/lower_output_reads.cpp
b/src/compiler/glsl/lower_output_reads.cpp
index 851078b..bd3accb 100644
--- a/src/compiler/glsl/lower_output_reads
This implements support for emitting FBFETCH ops, using the existing
lowering pass for advanced blend logic, and disabling hw blend when
advanced blending is enabled.
Signed-off-by: Ilia Mirkin
Reviewed-by: Nicolai Hähnle
---
src/mesa/state_tracker/st_atom_blend.c| 2 +-
src/mesa/state
Signed-off-by: Ilia Mirkin
---
v1 -> v2: remove accidental enablement in si_pipe
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/drivers/freedreno/freedreno_screen.c | 3 ++-
src/gallium/drivers/i915/i915_screen.c | 1 +
src/gallium/drivers/ilo/ilo_screen.c
Reviewed-by: Marek Olšák
On Dec 6, 2016 5:17 PM, "Philipp Zabel" wrote:
> For imported buffers that can't be used directly as a source to the
> texture samplers, the pipe driver might need to create an internal
> copy, for example in a different tiling layout. When buffers are
> reimported they
Reviewed-by: Marek Olšák
On Dec 6, 2016 5:17 PM, "Philipp Zabel" wrote:
> To comply with the requirement from the GL_OES_EGL_image_external
> extension that a call to glBindTexture guarantees that all further
> sampling will return values that correspond to the values in the
> external texture
Reviewed-by: Marek Olšák
On Dec 6, 2016 2:57 PM, "Philipp Zabel" wrote:
> Use the resource_changed callback to invalidate internal resources
> derived from external textures when they are (re-)bound. This is needed
> to comply with the requirement from the GL_OES_EGL_image_external
> extension
Reviewed and pushed the series.
Thanks,
Bas
On Sat, Jan 14, 2017 at 12:44 AM, Andres Rodriguez wrote:
> Following are a subset of patches from my wip-high-priority branch that
> may be useful outside that context.
>
> The HW priority debugging may take a little while, so I wanted to make some
>
14.01.2017 02:32, Connor Abbott пишет:
On Fri, Jan 13, 2017 at 1:55 PM, Thomas Helland
wrote:
2017-01-13 18:41 GMT+01:00 Vladislav Egorov :
13.01.2017 15:31, Tapani Pälli пишет:
On 01/12/2017 09:23 PM, Thomas Helland wrote:
Walking the whole hash table, inserting entries by hashing them fi
On Sat, 2017-01-14 at 04:50 +0300, Vladislav Egorov wrote:
> 14.01.2017 01:45, Timothy Arceri пишет:
> > I'm asking for a chance to test before we jump in, its probably not
> > a
> > big deal and I may even still be able to reduce my use of hashing
> > but
> > it would be nice to be given a few day
I suspect this might break builds with LLVM 3.6 or higher.
The LLVMLinkInJIT must be inside #if ... #endif, and it must not be
expanded when HAVE_LLVM >= 0x0306, since LLVMLinkInJIT(),
That is, when HAVE_LLVM >= 0x0306:
- USE_MCJIT should be static const
- no point claling GALLIVM_MCJIT
- must
31 matches
Mail list logo
