On Thu, May 28, 2015 at 10:21 AM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
I think pretty much everyone agrees that having more than a single bool as a
function argument is bordering on a bad idea. What sucks about the current
code is in several instances it's necessary to propagate
On Thu, May 28, 2015 at 5:07 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 27/05/15 16:59, Matt Turner wrote:
On Wed, May 27, 2015 at 4:53 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 27 May 2015 at 11:23, Dave Airlie airl...@gmail.com wrote:
Wow, I hadn't expected such a
On Wednesday, May 27, 2015 11:18:13 AM Ian Romanick wrote:
On 05/27/2015 10:36 AM, Tapani wrote:
On 05/26/2015 10:37 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
This is a bit of a hack for now. Several of the extensions required for
OpenGL ES 3.1 have no
Roland pointed out my previous attempt was lacking, so I enhanced the
texwrap piglit test, and tested them. This fixes the offset calculations
in a number of areas by adding the offset first, it also fixes the fastpaths,
which I forgot to address in the previous commit.
v2: try and avoid divides
Previously when setting up the sample instruction for an indirect
sampler the vec4 backend was directly passing the pseudo opcode's
src0. However this isn't actually set to a valid register because
instead the MRF registers are used as the source so it would end up
passing null as src0.
This
On 2015-05-28 10:21:31, Ben Widawsky wrote:
There are several constraints when determining if one can fast clear a
surface.
Some of these are alignment, pixel density, tiling formats, and others that
vary
by generation. The helper function which exists today does a suitable job,
however it
Hi everyone,
For those interested I will be writing a blog at:
https://hellthom.wordpress.com/
where I will be documenting my progress in GSoC (at least bi-weekly).
It also has some info about me in the about section.
If there is anything else you want to know, or think I should add, just holla.
This restriction was attempted in this commit:
commit 47053464630888f819ef8cc44278f1a1220159b9
Author: Anuj Phogat anuj.pho...@gmail.com
Date: Fri Feb 13 11:21:21 2015 -0800
i965/gen8: Use HALIGN_16 if MCS is enabled for non-MSRT
However, the commit itself doesn't achieve the desired goal
Just like the previous patch, but for the GEN9 constraints.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
This helped find the incorrect HALIGN values from the previous patches.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen8_surface_state.c
I think pretty much everyone agrees that having more than a single bool as a
function argument is bordering on a bad idea. What sucks about the current
code is in several instances it's necessary to propagate these boolean
selections down to lower layers of the code. This requires plumbing
Initially I wanted to just fix our boats HALIGN code for mcs surfaces on gen8+
(the 5th patch in the series). However, I soon realized why the original
implementation was wrong... the mipmap tree layout/creation is very entangled.
This patch series' primary purpose is to fix the HALIGN
For GEN9, much of the logic to use X-Tiled buffers has been stripped out. It is
still supported in some places, but it's never desirable. Unfortunately we don't
yet have the ability to have Y-Tiled scanout (see:
http://patchwork.freedesktop.org/patch/46984/),
NOTE: This patch shouldn't actually
There are several constraints when determining if one can fast clear a surface.
Some of these are alignment, pixel density, tiling formats, and others that vary
by generation. The helper function which exists today does a suitable job,
however it conflates BO properties with Miptree properties
On 2015-05-28 10:21:32, Ben Widawsky wrote:
This restriction was attempted in this commit:
commit 47053464630888f819ef8cc44278f1a1220159b9
Author: Anuj Phogat anuj.pho...@gmail.com
Date: Fri Feb 13 11:21:21 2015 -0800
i965/gen8: Use HALIGN_16 if MCS is enabled for non-MSRT
However,
Looks ok, it's massively simpler and shouldn't break as often.
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am 28.05.2015 um 17:57 schrieb Jose Fonseca:
It doesn't do everything we want. In particular it doesn't allow to
detect jumps or return opcodes. Currently we detect the x86's RET
On 29 May 2015 at 09:36, Marek Olšák mar...@gmail.com wrote:
Hi,
Would people be okay with removing the TGSI_PROCESSOR_ enums and
replacing all usages with PIPE_SHADER_*?
As long as there are no subtle bugs due to VERTEX and FRAGMENT
switching positions between the two,
Dave.
Hi,
Would people be okay with removing the TGSI_PROCESSOR_ enums and
replacing all usages with PIPE_SHADER_*?
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 28.05.2015 18:39, Jose Fonseca wrote:
Hi Michel,
I'm sorry: I hadn't notice your review-request, and just pushed a
similar fix.
No worries, though maybe this is an indication that it wasn't all that
trivial after all. :)
I used push/pop_macro pragma instead. I think it's portable
Am 29.05.2015 um 01:25 schrieb Dave Airlie:
Roland pointed out my previous attempt was lacking, so I enhanced the
texwrap piglit test, and tested them. This fixes the offset calculations
in a number of areas by adding the offset first, it also fixes the fastpaths,
which I forgot to address in
From: Roland Scheidegger srol...@vmware.com
Pure integer formats cannot be sampled with linear tex / mip filters. In GL
such a setup would make the texture incomplete.
We shouldn't rely on the state tracker though to filter that out, just return
all zeros instead of dying in the lerp.
---
On Thu, May 28, 2015 at 04:58:23PM -0700, Matt Turner wrote:
On Wed, May 27, 2015 at 10:16 PM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
AFAICT, there is no real way to make sure a send message with EOT is
properly
ignored from compact, nor can I see a way to actually encode EOT
From: Marek Olšák marek.ol...@amd.com
These states are for GS assembly shaders only. We don't support those.
---
src/mesa/main/context.c| 1 -
src/mesa/main/mtypes.h | 7 ---
src/mesa/main/shared.c | 1 -
src/mesa/program/program.c | 9 -
4 files changed, 18 deletions(-)
From: Marek Olšák marek.ol...@amd.com
There's no reason to use our own definition.
Tessellation will use the NV definitions too.
---
src/mesa/drivers/dri/i965/brw_program.c | 2 +-
src/mesa/main/glheader.h| 6 --
src/mesa/main/state.c | 2 +-
From: Marek Olšák marek.ol...@amd.com
This is for user assembly shaders only (not GLSL). We won't support those.
---
src/mesa/main/mtypes.h | 2 --
src/mesa/program/program.c | 3 ---
2 files changed, 5 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index
From: Marek Olšák marek.ol...@amd.com
---
src/mesa/main/mtypes.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 47be72d..1ecadfe 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -398,7 +398,6 @@ struct gl_config
{
From: Marek Olšák marek.ol...@amd.com
---
src/mesa/main/shaderapi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index a04b287..e06942b 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -532,7
On 29 May 2015 at 09:57, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
All seem fine,
For the series,
Reviewed-by: Dave Airlie airl...@redhat.com
These states are for GS assembly shaders only. We don't support those.
---
src/mesa/main/context.c| 1 -
This patch allows us to enable our Braswell in our continuous
integration pool. Without it, gpu hangs prevent piglit from
completing.
Getting Braswell enabled in the pool will help us prevent future
regressions on the platform.
Tested-by: Mark Janes mark.a.ja...@intel.com
Ben Widawsky
On Wed, May 27, 2015 at 10:16 PM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
AFAICT, there is no real way to make sure a send message with EOT is properly
ignored from compact, nor can I see a way to actually encode EOT while
compacting. Before the single send optimization we'd always bail
On Wed, May 27, 2015 at 12:24:47PM -0700, Matt Turner wrote:
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 2 ++
1 file changed, 2 insertions(+)
Reviewed-by: Topi Pohjolainen topi.pohjolai...@intel.com
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
From: Michel Dänzer michel.daen...@amd.com
Fixes build failure with --enable-debug:
Compiling src/gallium/auxiliary/gallivm/lp_bld_misc.cpp ...
In file included from llvm/include/llvm/Object/RelocVisitor.h:23:0,
from llvm/include/llvm/DebugInfo/DIContext.h:21,
When we compute the output swizzle we want to consider the number of
components in the add operation. So far we were using the writemask
of the multiplication for this instead, which is not correct.
---
src/glsl/nir/nir_opt_peephole_ffma.c | 19 +--
1 file changed, 9
Wrap MapBuffer and MapImage as hard_event actions, like other
operations. This enables correct profiling. Also make sure to wait
for events to finish when blocking is requested by the caller.
---
src/gallium/state_trackers/clover/api/transfer.cpp | 50 --
1 file changed, 46
Mapping can fail, and this should be handled. Return the proper error
code and abort the associated event in this case.
---
src/gallium/state_trackers/clover/api/transfer.cpp | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git
The disassemble function does more harm than good and is often the
most often broken function after an LLVM update. Shouldn't we remove
it to make our lives easier?
Marek
On Wed, May 27, 2015 at 7:27 AM, Vinson Lee v...@freedesktop.org wrote:
TargetOptions::NoFramePointerElim was removed in
On 05/06/2015 03:53 AM, Robert Bragg wrote:
+static struct brw_perf_query_counter gen7_pipeline_statistics[] = {
+
+ STAT(IA_VERTICES_COUNT, N vertices submitted),
+ STAT(IA_PRIMITIVES_COUNT, N primitives submitted),
+ STAT(VS_INVOCATION_COUNT, N vertex shader invocations),
+
On 27/05/15 16:59, Matt Turner wrote:
On Wed, May 27, 2015 at 4:53 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 27 May 2015 at 11:23, Dave Airlie airl...@gmail.com wrote:
Wow, I hadn't expected such a hateful comment on GLES1.
Does anyone else want to convince me that GLES1 should
Hi,
The trailing comma is allowed in array and structure initializers and
is ignored according to the standard.
Marek
On Wed, May 27, 2015 at 8:19 PM, Michael Schellenberger Costa
schellenber...@inb.uni-luebeck.de wrote:
Hi,
Am 27/05/2015 um 09:45 schrieb Dave Airlie:
This adds support to
Hi Chad,
A new patch is attached.
Marek
On Wed, May 27, 2015 at 8:59 PM, Chad Versace chad.vers...@intel.com wrote:
On Wed 13 May 2015, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
---
src/egl/main/eglapi.c | 14 +-
src/egl/main/eglapi.h | 2 +-
https://bugs.freedesktop.org/show_bug.cgi?id=90621
José Fonseca jfons...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
I don't understand. Using size_t should prevent the integer overflow.
Is there anything else wrong other than no fail path for malloc? I
also don't understand how calloc can help here.
Marek
On Wed, May 27, 2015 at 9:07 PM, Chad Versace chad.vers...@intel.com wrote:
On Fri 15 May 2015, Emil
Marek Olšák mar...@gmail.com writes:
I don't understand. Using size_t should prevent the integer overflow.
Is there anything else wrong other than no fail path for malloc? I
also don't understand how calloc can help here.
Marek
size * sizeof(int_attribs[0]) may overflow and thus wrap to a
We need this to implement OpenCL's
CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE.
---
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/drivers/ilo/ilo_screen.c | 8
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 4
Work-group size should always be aligned to subgroup size; this is a
basic requirement, otherwise some work-items will be no-operation.
It might make sense to refine the value according to a kernel's
resource usage, but that's a possible optimization for the future.
---
I use this sometimes for debugging things in llvmpipe, so I don't think
that's a good option. Without it getting the actual assembly of the
shaders would be quite annoying.
It is unfortunately true that (due to the heavy use of the unstable C++
API) it breaks very often, but as long as it isn't
Hi Michel,
I'm sorry: I hadn't notice your review-request, and just pushed a
similar fix.
I used push/pop_macro pragma instead. I think it's portable enough (at
least gcc and msvc support it). Your's is probable more portable
though. I'm OK either way.
Like you said, this is a
Ben Widawsky benjamin.widaw...@intel.com writes:
AFAICT, there is no real way to make sure a send message with EOT is
properly ignored from compact, nor can I see a way to actually encode
EOT while compacting. Before the single send optimization we'd always
bail because we hit the
A new patch is attached. Please review.
Marek
On Wed, May 27, 2015 at 9:07 PM, Chad Versace chad.vers...@intel.com wrote:
On Fri 15 May 2015, Emil Velikov wrote:
On 12/05/15 22:54, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
---
src/egl/main/eglapi.c | 38
For the record, we also feel the pain, and I did look into the LLVM C
API for disassembly, but the problem is that we only get the function
start address -- we don't know where it finishes --, and the LLVM C API
doesn't expose enough capabilities to describe jump/return instructions,
which we
A new patch is attached. Please review.
Marek
On Wed, May 13, 2015 at 12:54 AM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
These are just wrappers around the existing extension functions.
---
src/egl/main/eglapi.c | 45
Am 28.05.2015 um 16:35 schrieb Jose Fonseca:
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 7b906c2..384ea86 100644
---
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
On May 28, 2015 12:06 AM, Iago Toral Quiroga ito...@igalia.com wrote:
When we compute the output swizzle we want to consider the number of
components in the add operation. So far we were using the writemask
of the multiplication for this
On Thu, May 28, 2015 at 3:31 AM, Neil Roberts n...@linux.intel.com wrote:
Ben Widawsky benjamin.widaw...@intel.com writes:
AFAICT, there is no real way to make sure a send message with EOT is
properly ignored from compact, nor can I see a way to actually encode
EOT while compacting. Before
Am 28.05.2015 um 14:28 schrieb Jose Fonseca:
For the record, we also feel the pain, and I did look into the LLVM C
API for disassembly, but the problem is that we only get the function
start address -- we don't know where it finishes --, and the LLVM C API
doesn't expose enough capabilities to
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 7b906c2..384ea86 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++
On 28/05/15 15:37, Roland Scheidegger wrote:
Am 28.05.2015 um 16:35 schrieb Jose Fonseca:
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
It doesn't do everything we want. In particular it doesn't allow to
detect jumps or return opcodes. Currently we detect the x86's RET
opcode.
Even though it's worse for LLVM 3.3, it's an improvement for LLVM 3.7,
which was totally busted.
---
scons/llvm.py |
On Thu, May 28, 2015 at 11:31:40AM +0100, Neil Roberts wrote:
Ben Widawsky benjamin.widaw...@intel.com writes:
AFAICT, there is no real way to make sure a send message with EOT is
properly ignored from compact, nor can I see a way to actually encode
EOT while compacting. Before the single
On Thu, May 28, 2015 at 07:00:38AM -0700, Matt Turner wrote:
On Thu, May 28, 2015 at 3:31 AM, Neil Roberts n...@linux.intel.com wrote:
Ben Widawsky benjamin.widaw...@intel.com writes:
AFAICT, there is no real way to make sure a send message with EOT is
properly ignored from compact, nor
60 matches
Mail list logo
