On Thu, May 28, 2015 at 10:21:33AM -0700, Ben Widawsky wrote:
> Just like the previous patch, but for the GEN9 constraints.
>
> Signed-off-by: Ben Widawsky
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i9
On Thu, May 28, 2015 at 10:21:32AM -0700, Ben Widawsky wrote:
> This restriction was attempted in this commit:
> commit 47053464630888f819ef8cc44278f1a1220159b9
> Author: Anuj Phogat
> Date: Fri Feb 13 11:21:21 2015 -0800
>
>i965/gen8: Use HALIGN_16 if MCS is enabled for non-MSRT
>
> Howev
On Fri, May 29, 2015 at 09:32:53AM +0300, Pohjolainen, Topi wrote:
> On Thu, May 28, 2015 at 10:21:29AM -0700, Ben Widawsky 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
On Thu, May 28, 2015 at 10:21:29AM -0700, Ben Widawsky 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 these boolean
> select
From: Roland Scheidegger
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.
---
src/gallium/auxiliary/gal
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
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 e
On Thu, May 28, 2015 at 04:58:23PM -0700, Matt Turner wrote:
> On Wed, May 27, 2015 at 10:16 PM, Ben Widawsky
> 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. B
On 29 May 2015 at 09:57, Marek Olšák wrote:
> From: Marek Olšák
All seem fine,
For the series,
Reviewed-by: Dave Airlie
>
> 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/m
On 29 May 2015 at 09:36, Marek Olšák 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.
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
Ben Widawsky writes:
> AFAICT, there is no
On Wed, May 27, 2015 at 10:16 PM, Ben Widawsky
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 because we
> hit
> the
From: Marek Olšák
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(-)
diff --git a/src/me
From: Marek Olšák
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 +-
src/mesa/program/prog_print.c
From: Marek Olšák
---
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
{
GLboolean rgbMode;
From: Marek Olšák
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 96ef060..47be72d 100644
---
From: Marek Olšák
---
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 +532,7 @@ get_programi
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
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 i
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
> >>
> >> This is a bit of a hack for now. Several of the extensions required for
> >> OpenGL ES 3.1 have no support, at all,
On Thu, May 28, 2015 at 10:21 AM, Ben Widawsky
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 these boolean
> selections do
On Thu, May 28, 2015 at 5:07 AM, Emil Velikov wrote:
> On 27/05/15 16:59, Matt Turner wrote:
>> On Wed, May 27, 2015 at 4:53 AM, Emil Velikov
>> wrote:
>>> On 27 May 2015 at 11:23, Dave Airlie wrote:
> Wow, I hadn't expected such a hateful comment on GLES1.
>
> Does anyone else want
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.
On 2015-05-28 10:21:32, Ben Widawsky wrote:
> This restriction was attempted in this commit:
> commit 47053464630888f819ef8cc44278f1a1220159b9
> Author: Anuj Phogat
> Date: Fri Feb 13 11:21:21 2015 -0800
>
>i965/gen8: Use HALIGN_16 if MCS is enabled for non-MSRT
>
> However, the commit its
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,
> howev
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 patch
Looks ok, it's massively simpler and shouldn't break as often.
Reviewed-by: Roland Scheidegger
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
> opcode.
>
> E
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 constraints
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"
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 (mechani
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 do
This restriction was attempted in this commit:
commit 47053464630888f819ef8cc44278f1a1220159b9
Author: Anuj Phogat
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 as determined by the
as
This helped find the incorrect HALIGN values from the previous patches.
Signed-off-by: Ben Widawsky
---
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
b/src/mesa/drivers/dri/i965/gen8_surface_
Just like the previous patch, but for the GEN9 constraints.
Signed-off-by: Ben Widawsky
---
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
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index
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 | 4
On Thu, May 28, 2015 at 11:31:40AM +0100, Neil Roberts wrote:
> Ben Widawsky 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 w
On Thu, May 28, 2015 at 07:00:38AM -0700, Matt Turner wrote:
> On Thu, May 28, 2015 at 3:31 AM, Neil Roberts wrote:
> > Ben Widawsky 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
> >
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
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
> ---
---
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
+++ b/src/galli
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
On Thu, May 28, 2015 at 3:31 AM, Neil Roberts wrote:
> Ben Widawsky 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
>
Reviewed-by: Jason Ekstrand
On May 28, 2015 12:06 AM, "Iago Toral Quiroga" 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 instead, which is not correct.
> ---
>
A new patch is attached. Please review.
Marek
On Wed, May 13, 2015 at 12:54 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> These are just wrappers around the existing extension functions.
> ---
> src/egl/main/eglapi.c | 45 +
> 1 file changed, 45 ins
A new patch is attached. Please review.
Marek
On Wed, May 27, 2015 at 9:07 PM, Chad Versace wrote:
> On Fri 15 May 2015, Emil Velikov wrote:
>> On 12/05/15 22:54, Marek Olšák wrote:
>> > From: Marek Olšák
>> >
>> > ---
>> > 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 r
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 pos
On 27/05/15 16:59, Matt Turner wrote:
> On Wed, May 27, 2015 at 4:53 AM, Emil Velikov
> wrote:
>> On 27 May 2015 at 11:23, Dave Airlie wrote:
Wow, I hadn't expected such a hateful comment on GLES1.
Does anyone else want to convince me that GLES1 should burn in hell?
>>>
>>> So I d
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
src/gallium/drivers/radeon/r600_pipe_
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.
---
src/gallium/state_trackers
Marek Olšák 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 small
numbe
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"),
+ STAT
Ben Widawsky 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 is_immediate && !is_compactable_imm
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
wrote:
> Hi,
>
> Am 27/05/2015 um 09:45 schrieb Dave Airlie:
>> This adds support to retrieve the primitive counts
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 wrote:
> On Fri 15 May 2015, Emil Velikov wrote:
>> On 12/
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 wrote:
> TargetOptions::NoFramePointerElim was removed in llvm-3.7.0svn r238244
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 workaround
https://bugs.freedesktop.org/show_bug.cgi?id=90621
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Chad,
A new patch is attached.
Marek
On Wed, May 27, 2015 at 8:59 PM, Chad Versace wrote:
> On Wed 13 May 2015, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> ---
>> src/egl/main/eglapi.c | 14 +-
>> src/egl/main/eglapi.h | 2 +-
>> src/egl/main/eglsync.c | 2 +-
>> src/egl/
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 a/src/gallium/state_trackers/clover/api
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 ins
From: Michel Dänzer
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,
from llvm/include/llvm
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 insertions(+),
63 matches
Mail list logo
