Hi Curro,
On Fri, 2015-10-30 at 16:19 +0200, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> > Right now some opcodes that only use constant surface indexing mark them as
> > used in the generator while others do it in the visitor. When the opcode can
> > handle both direct and indirect
On Sat, 2015-10-31 at 23:22 -0700, Jordan Justen wrote:
> On 2015-10-29 01:22:37, Iago Toral wrote:
> > On Thu, 2015-10-29 at 00:47 -0700, Jordan Justen wrote:
> > > The OpenGLES GLSL 3.1 specification uses the precision qualifier
> > > ordering rules from ARB_shading_language_420pack.
> >
> > May
the changes look reasonable. For both patches:
Reviewed-by: Iago Toral Quiroga
On Mon, 2015-11-02 at 00:35 -0800, Jordan Justen wrote:
> There is some discrepancy between the return values for some error
> cases for the DispatchComputeIndirect call in the ARB_compute_shader
> specification. Rega
On 10/28/2015 04:43 PM, Connor Abbott wrote:
> On Wed, Oct 28, 2015 at 7:06 PM, Ian Romanick wrote:
>> On 10/28/2015 02:32 PM, Jason Ekstrand wrote:
>>> ---
>>> src/glsl/nir/nir.h | 19 +++
>>> src/glsl/nir/nir_pass.c | 64
>>> -
>>
On Mon, Nov 2, 2015 at 8:30 PM, Ryan Houdek wrote:
> This extension requires ES 3.1 since it relies on glMemoryBarrier.
> For testing purposes I temporarily moved glMemoryBarrier to be an ES 3.0
> function.
> This has been tested with the piglit in the ML and the Dolphin emulator.
Reviewed-by: Il
This extension requires ES 3.1 since it relies on glMemoryBarrier.
For testing purposes I temporarily moved glMemoryBarrier to be an ES 3.0
function.
This has been tested with the piglit in the ML and the Dolphin emulator.
---
docs/relnotes/11.1.0.html | 1 +
src/mapi/glapi/gen/es_EXT.xml | 9
On Mon, Nov 2, 2015 at 8:19 PM, Ryan Houdek wrote:
> This extension requires ES 3.1 since it relies on glMemoryBarrier.
> For testing purposes I temporarily moved glMemoryBarrier to be an ES 3.0
> function.
> This has been tested with the piglit in the ML and the Dolphin emulator.
> ---
> docs/re
This extension requires ES 3.1 since it relies on glMemoryBarrier.
For testing purposes I temporarily moved glMemoryBarrier to be an ES 3.0
function.
This has been tested with the piglit in the ML and the Dolphin emulator.
---
docs/relnotes/11.1.0.html | 1 +
src/mapi/glapi/gen/es_EXT.xml | 9
On Mon, Nov 2, 2015 at 8:07 PM, Ian Romanick wrote:
> On 11/02/2015 04:50 PM, Ilia Mirkin wrote:
>> GL_EXT_color_buffer_float adds support for float buffers in ES3.0+, but
>> explicitly disallows 32-bit blending. However this restriction was never
>> implemented in mesa.
>>
>> Add the restriction,
On 11/02/2015 04:50 PM, Ilia Mirkin wrote:
> GL_EXT_color_buffer_float adds support for float buffers in ES3.0+, but
> explicitly disallows 32-bit blending. However this restriction was never
> implemented in mesa.
>
> Add the restriction, and also allow a driver to expose
> GL_EXT_float_blend whi
GL_EXT_color_buffer_float adds support for float buffers in ES3.0+, but
explicitly disallows 32-bit blending. However this restriction was never
implemented in mesa.
Add the restriction, and also allow a driver to expose
GL_EXT_float_blend which re-enables the functionality.
Signed-off-by: Ilia M
If the driver supports PIPE_BIND_BLENABLE on RGBA32F, flip
EXT_blend_float on (which will affect ES3 contexts).
Signed-off-by: Ilia Mirkin
---
src/mesa/state_tracker/st_extensions.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa
From the table in brw_surface_formats.c, it appears that all generations
support blending on RGBA32F surfaces.
Signed-off-by: Ilia Mirkin
---
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/
On Mon, Nov 2, 2015 at 7:46 PM, Ian Romanick wrote:
> On 11/01/2015 07:29 PM, Ilia Mirkin wrote:
>> On Sun, Nov 1, 2015 at 10:24 PM, Ryan Houdek wrote:
>>> This has been tested with the piglits in the mailing list and
>>> on the Dolphin emulator.
>>> ---
>>> docs/GL3.txt
On 11/01/2015 07:29 PM, Ilia Mirkin wrote:
> On Sun, Nov 1, 2015 at 10:24 PM, Ryan Houdek wrote:
>> This has been tested with the piglits in the mailing list and
>> on the Dolphin emulator.
>> ---
>> docs/GL3.txt | 2 +-
>> docs/relnotes/11.1.0.html
So, I noticed while running benchmarks that there seem to be some
significant bugs somewhere. In particular, Unigen Heaven misrenders
on Haswell. One of the synmark tests also misrenders. Initially I
thought it was a spilling bug, but I'm also seeing misrendering on the
sethi ullman patch.
--Jas
Cuts 10k of .text, of which only 776 bytes are the fs_reg constructor
implementations themselves.
text data bss dec hex filename
5204535 21411227784 5446431 531b1f i965_dri.so before
5193977 21411227784 5435873 52f1e1 i965_dri.so after
---
src/mesa/drive
The 2-bit hardware register file field is ARF, GRF, MRF, IMM.
Rename GRF to VGRF (virtual GRF) so that we can reuse the GRF name to
mean an assigned general purpose register.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 104 ++---
src/mesa/drivers/dri/i965/brw_fs.h
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 93 +-
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 9 +-
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 4 +-
src/mesa/drivers/dri/i965/brw_ir_fs.h | 4 +-
src/mesa/drivers/dri/i965/brw_ir_v
The test (file == BAD_FILE) works on registers for which the constructor
has not run because BAD_FILE is zero. The next commit will move
BAD_FILE in the enum so that it's no longer zero.
---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 10 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
We use brw_imm_v() to produce type-V immediates, which generates a
brw_reg with fs_reg's .file set to HW_REG. The next commit will rid us
of HW_REGs, so we need to handle BRW_REGISTER_TYPE_V in the IMM case.
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 3 +++
1 file changed, 3 insertions(+
The generator asserts that this is true (and presumably it's useful in
some optimization passes?) and the VF fs_reg constructors did this (by
virtue of the fact that it doesn't override what init() does).
In the next commit, calling this constructor with brw_imm_* will
generate an IMM file registe
Cuts 1.5k of .text.
---
src/mesa/drivers/dri/i965/brw_ir_vec4.h| 5 --
src/mesa/drivers/dri/i965/brw_vec4.cpp | 67 +++
src/mesa/drivers/dri/i965/brw_vec4_builder.h | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 38 +
src/mesa/drive
The first four values (2-bits) are hardware values, and VGRF, ATTR, and
UNIFORM remain values used in the IR.
---
src/mesa/drivers/dri/i965/brw_defines.h | 11 +++
src/mesa/drivers/dri/i965/brw_fs.cpp| 5 ++---
src/mesa/drivers/dri/i965/brw_ir_fs.h | 4 ++--
src/mesa/drivers/dri/i9
HW_REGs are (were!) kind of awful. If the file was HW_REG, you had to
look at different fields for type, abs, negate, writemask, swizzle, and
a second file. They also caused annoying problems like immediate sources
being considered scheduling barriers (commit 6148e94e2) and other such
nonsense.
In
I'm going to begin using brw_reg's file field in backend_reg and its
derivatives, and in order to keep the hardware value for ARF as 0, we
have to do something different.
---
src/mesa/drivers/dri/i965/brw_shader.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers
---
src/mesa/drivers/dri/i965/brw_fs.cpp| 5 +
src/mesa/drivers/dri/i965/brw_fs_combine_constants.cpp | 3 +--
src/mesa/drivers/dri/i965/brw_vec4.cpp | 5 +
src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp | 3 +--
4 files changed, 4 insertions(
This reverts commit bbf8239f92ecd79431dfa41402e1c85318e7267f.
I didn't like that commit to begin with -- computing things at compile
time is fine -- but for purposes of verifying that the resulting values
are correct, looking up 0x00 and 0x30 in a table is a lot better than
evaluating a recursive
In addition to combining another field, we get replace silliness like
"reg.reg" with something that actually makes sense, "reg.nr"; and no one
will ever wonder again why dst.reg isn't a dst_reg.
Moving the now 16-bit nr field to a 16-bit boundary decreases code size
by about 3k.
---
src/mesa/driv
---
src/mesa/drivers/dri/i965/brw_disasm.c | 4 ++--
src/mesa/drivers/dri/i965/brw_eu_emit.c| 4 ++--
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mes
The previous two commits make this unnecessary.
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 32 +-
src/mesa/drivers/dri/i965/brw_vec4.cpp | 6 +
2 files changed, 2 insertions(+), 36 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.
W/UW immediates are 16-bits, but those 16-bits must be replicated
in the high 16-bits of the 32-bit field.
Remove the useless W/UW immediate saturating code, since we'll now be
using the appropriate immediate (and W/UW immediates in the IR can now
no longer be larger than 16-bits).
---
src/mesa/d
Instead use the ones provided by brw_reg. Also allows us to handle
HW_REGs in the negate() functions.
---
src/mesa/drivers/dri/i965/brw_ir_fs.h | 2 +-
src/mesa/drivers/dri/i965/brw_ir_vec4.h | 2 +-
src/mesa/drivers/dri/i965/brw_shader.h | 3 ---
3 files changed, 2 insertions(+), 5 deletions(-
Put fields that are meaningless with an immediate in the same storage
with the immediate. This leaves fields type, file, nr, subnr in the
first dword where there's now extra room for expansion.
---
src/mesa/drivers/dri/i965/brw_reg.h | 16
1 file changed, 8 insertions(+), 8 deleti
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 74 +++---
.../drivers/dri/i965/brw_fs_combine_constants.cpp | 6 +-
.../drivers/dri/i965/brw_fs_copy_propagation.cpp | 12 ++--
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 16 ++---
src/mesa/drivers/dri/i965/brw
Generated by
sed -i -e 's/\.bits\././g' *.c *.h *.cpp
sed -i -e 's/dw1\.//g' *.c *.h *.cpp
and then reverting changes to comments in gen7_blorp.cpp and
brw_fs_generator.cpp.
There wasn't any utility offered by forcing the programmer to list these
to access their fields. Removing them will
Some fields (file, type, abs, negate) in brw_reg are shadowed by
backend_reg.
---
src/mesa/drivers/dri/i965/brw_shader.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.h
b/src/mesa/drivers/dri/i965/brw_shader.h
index 6a2dfc9..9a516c3
Switching from an implicitly-sized type field to field with an explicit
bit width is safe because we have fewer than 2^4 types, and gcc will
warn if you attempt to set a value that will not fit.
---
src/mesa/drivers/dri/i965/brw_shader.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/
backend_reg (from which fs_reg, src_reg, and dst_reg inherit) includes a
brw_reg that's used for "hardware regs" -- precolored registers or architecture
registers. This leads to properties like source modifiers, the register type,
swizzles, and writemasks being duplicated between the derived classe
---
src/mesa/drivers/dri/i965/brw_defines.h| 10 ++
src/mesa/drivers/dri/i965/brw_eu_emit.c| 2 +-
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 5 +++--
src/mesa/drivers/dri/i965/brw_reg.h| 25 +
4 files changed, 23 insertions(+), 1
Also allows us to handle HW_REGs in the swizzle() and writemask()
functions.
---
src/mesa/drivers/dri/i965/brw_ir_vec4.h | 7 +--
src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 --
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_ir_vec4.h
b/src/mesa/dr
https://bugs.freedesktop.org/show_bug.cgi?id=92783
Bug ID: 92783
Summary: MESA_DEBUG=incomplete_tex prints warnings from glClear
which doesn't use the state
Product: Mesa
Version: git
Hardware: All
OS: All
It is legal to have a texture view of a single layer from a 2D array texture;
you can sample from it, or render to it. Intel hardware needs to be made aware
when it is using a 2d array surface in the surface state. The texture view is
just a 2d surface with the backing miptree actually being a 2d a
Am 02.11.2015 um 22:39 schrieb Dave Airlie:
> On 3 November 2015 at 07:31, Roland Scheidegger wrote:
>> Am 02.11.2015 um 20:55 schrieb Ilia Mirkin:
>>> FTR these are the various operators on nvidia hw:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.nvidia.com_cuda_parallel-2Dthre
On Mon, Nov 2, 2015 at 7:08 PM, Roland Scheidegger wrote:
> Am 02.11.2015 um 14:46 schrieb Oded Gabbay:
>> On Thu, Oct 29, 2015 at 9:37 PM, Roland Scheidegger
>> wrote:
>>> Am 29.10.2015 um 19:44 schrieb Oded Gabbay:
On Thu, Oct 29, 2015 at 5:31 PM, Roland Scheidegger
wrote:
> Am
On Mon, Nov 02, 2015 at 12:05:32PM -0800, Ben Widawsky wrote:
> It is legal to have a texture view of a single layer from a 2D array texture;
> you can sample from it, or render to it. Intel hardware needs to be made aware
> when it is using a 2d array surface in the surface state. The texture view
On 3 November 2015 at 07:31, Roland Scheidegger wrote:
> Am 02.11.2015 um 20:55 schrieb Ilia Mirkin:
>> FTR these are the various operators on nvidia hw:
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.nvidia.com_cuda_parallel-2Dthread-2Dexecution_-23cache-2Doperators&d=BQIFaQ&c=Sqc
On Mon, Nov 2, 2015 at 9:14 PM, Ilia Mirkin wrote:
> On Mon, Nov 2, 2015 at 3:07 PM, Marek Olšák wrote:
>>> diff --git a/src/gallium/include/pipe/p_state.h
>>> b/src/gallium/include/pipe/p_state.h
>>> index 4bf8d46..2843bb6 100644
>>> --- a/src/gallium/include/pipe/p_state.h
>>> +++ b/src/galliu
Am 02.11.2015 um 20:55 schrieb Ilia Mirkin:
> FTR these are the various operators on nvidia hw:
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.nvidia.com_cuda_parallel-2Dthread-2Dexecution_-23cache-2Doperators&d=BQIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJ
On Mon, Nov 2, 2015 at 3:07 PM, Marek Olšák wrote:
>> diff --git a/src/gallium/include/pipe/p_state.h
>> b/src/gallium/include/pipe/p_state.h
>> index 4bf8d46..2843bb6 100644
>> --- a/src/gallium/include/pipe/p_state.h
>> +++ b/src/gallium/include/pipe/p_state.h
>> @@ -684,6 +684,35 @@ struct pip
> diff --git a/src/gallium/include/pipe/p_state.h
> b/src/gallium/include/pipe/p_state.h
> index 4bf8d46..2843bb6 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -684,6 +684,35 @@ struct pipe_compute_state
> unsigned req_input_mem; /**< Require
It is legal to have a texture view of a single layer from a 2D array texture;
you can sample from it, or render to it. Intel hardware needs to be made aware
when it is using a 2d array surface in the surface state. The texture view is
just a 2d surface with the backing miptree actually being a 2d a
On Mon, Nov 2, 2015 at 8:07 PM, Ilia Mirkin wrote:
> I haven't the faintest idea about efficiently, but these things flags
> on the ld/st instructions in the nvidia ISA for SM20+ (and I just
> plain don't know about SM10). I'm moderately sure that's the case for
> GCN as well.
>
> The difficulty w
On 2015-11-02 00:35:36, Jordan Justen wrote:
> Note: The OpenGL 4.3 - 4.5 specification language for DispatchCompute
> appears to have an error regarding the max allowed values. When adding
> the specification citation, we note why the code does not match the
> specification language.
>
> v2:
> *
FTR these are the various operators on nvidia hw:
http://docs.nvidia.com/cuda/parallel-thread-execution/#cache-operators
Most of these map directly to instruction things (ca/cg/cs/cv sound
familiar, dunno about lu, could just be an assembler helper).
How backwards-compatible is TGSI supposed to
Ok, I guess if it's really flagged on the instructions in hw, it seems
reasonable to do it on the instructions in tgsi as well.
Using the last two bits there doesn't sound nice indeed (in particular
if maybe you'd wanted to encode the read/write bits as well at some
point too), but it's not THAT ba
On Mon, Nov 2, 2015 at 9:33 AM, Connor Abbott wrote:
> On Mon, Nov 2, 2015 at 8:35 AM, Emil Velikov wrote:
>> Hi all,
>>
>> From a quick look, it seems that NIR copies (almost ?) all the state
>> from GLSL IR even if it doesn't use it.
>>
>> The particular piece that I'm thinking about is nir_var
Am 02.11.2015 um 15:56 schrieb Oded Gabbay:
> If we don't have any constants, just exit emit_fetch_constat() and don't
> call LLVM functions.
>
> This also prevents a crash that happens when we emit the prologue of the
> fragment shader when DEBUG_EXECUTION is set to 1 and we don't have
> constant
Another fun example to try to express properly in TGSI:
buffer foo {
struct bar {
coherent int a;
int b;
} asdf[10];
}
Now all of a sudden you have to worry about stride for the declarations.
-ilia
On Mon, Nov 2, 2015 at 2:07 PM, Ilia Mirkin wrote:
> I haven't the faintest idea
I haven't the faintest idea about efficiently, but these things flags
on the ld/st instructions in the nvidia ISA for SM20+ (and I just
plain don't know about SM10). I'm moderately sure that's the case for
GCN as well.
The difficulty with TGSI is that you might have something like
layout (std430)
I don't know much about ssbo, but since it looks like in glsl the
coherent etc. bits are on the variables, not the ops, it seems unnatural
to mark the op bits instead. So I'd guess it would be better if the
variables could be marked instead. If this isn't expressible in tgsi
maybe this needs to be
On 11/02/2015 11:14 AM, Roland Scheidegger wrote:
Am 31.10.2015 um 14:37 schrieb Brian Paul:
This primarily means added support for copying between compressed
and uncompressed formats.
---
src/gallium/auxiliary/util/u_surface.c | 106 +++--
1 file changed, 88 inser
Am 31.10.2015 um 14:37 schrieb Brian Paul:
> We disable all 3-channel array formats since we don't support 3-channel
> UNORM8 formats.
>
> Recall that if a 3-channel format is requested by the user, we might
> actually wind up using a 4-channel format instead. In fact, llvmpipe
> does this freque
Am 31.10.2015 um 14:37 schrieb Brian Paul:
> This primarily means added support for copying between compressed
> and uncompressed formats.
> ---
> src/gallium/auxiliary/util/u_surface.c | 106
> +++--
> 1 file changed, 88 insertions(+), 18 deletions(-)
>
> diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=92022
Julien Isorce changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, Nov 2, 2015 at 1:30 AM, Vinson Lee wrote:
> nir/nir_control_flow.c: In function ‘split_block_cursor.isra.11’:
> nir/nir_control_flow.c:460:15: warning: ‘after’ may be used uninitialized in
> this function [-Wmaybe-uninitialized]
>*_after = after;
>^
> nir/nir_contr
On Mon, Nov 2, 2015 at 8:35 AM, Emil Velikov wrote:
> Hi all,
>
> From a quick look, it seems that NIR copies (almost ?) all the state
> from GLSL IR even if it doesn't use it.
>
> The particular piece that I'm thinking about is nir_variable::data.
> Afaict this is a remnant from the early days, w
Reviewed-by: Connor Abbott
On Mon, Nov 2, 2015 at 4:30 AM, Vinson Lee wrote:
> nir/nir_control_flow.c: In function ‘split_block_cursor.isra.11’:
> nir/nir_control_flow.c:460:15: warning: ‘after’ may be used uninitialized in
> this function [-Wmaybe-uninitialized]
>*_after = after;
>
Am 02.11.2015 um 14:46 schrieb Oded Gabbay:
> On Thu, Oct 29, 2015 at 9:37 PM, Roland Scheidegger
> wrote:
>> Am 29.10.2015 um 19:44 schrieb Oded Gabbay:
>>> On Thu, Oct 29, 2015 at 5:31 PM, Roland Scheidegger
>>> wrote:
Am 29.10.2015 um 12:27 schrieb Oded Gabbay:
> Hi Roland, Jose
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=91687
Jon Burgess changed:
What|Removed |Added
See Also||https://bugs.kde.org/show_b
If we don't have any constants, just exit emit_fetch_constat() and don't
call LLVM functions.
This also prevents a crash that happens when we emit the prologue of the
fragment shader when DEBUG_EXECUTION is set to 1 and we don't have
constants (e.g. arb_blend_func_extended-fbo-extended-blend test
On Thu, Oct 29, 2015 at 9:37 PM, Roland Scheidegger wrote:
> Am 29.10.2015 um 19:44 schrieb Oded Gabbay:
>> On Thu, Oct 29, 2015 at 5:31 PM, Roland Scheidegger
>> wrote:
>>> Am 29.10.2015 um 12:27 schrieb Oded Gabbay:
Hi Roland, Jose
I wanted to bring a problem I found to your att
Hi all,
From a quick look, it seems that NIR copies (almost ?) all the state
from GLSL IR even if it doesn't use it.
The particular piece that I'm thinking about is nir_variable::data.
Afaict this is a remnant from the early days, when the intent was to
kill off the GLSL IR and use NIR directly.
Patch sets matrix_stride as 0 for non matrix uniforms that are in a
atomic counter buffer. Matrix stride calculation for actual matrix
uniforms is done during link_assign_uniform_locations.
From ARB_program_interface_query specification:
GL_MATRIX_STRIDE:
"For active variables not declared as
Thanks Eduardo for taking a look at this. Today with a refreshed mind I
noticed that I can fix this with smaller changes since it seems it's
actually only the matrix_stride query that is broken for atomic counter
buffers.
I'll send a new patch and will cc you.
On 10/30/2015 05:35 PM, Eduardo
Timothy Arceri writes:
> From: Timothy Arceri
>
> V2: avoid useless zero-initialization and addition for the first AoA level,
> avoid redundant temporary, make use of type_size_scalar(), rename aoa_size
> to element_size, assign the indirect indexing temporary directly to
> image.reladdr, and re
https://bugs.freedesktop.org/show_bug.cgi?id=92366
--- Comment #4 from Tapani Pälli ---
This test has been randomly failing for me on IVB and HSW as long as I can
remember, I don't think this is specific for BSW and SKL, it just fails on
anything but in a random fashion.
--
You are receiving th
I'm okay with adding flags wherever you want, but please note that if
you add flags to declarations, you may need array support on the
declarations, so that instructions can tell which variable is being
used when indirect addressing is being used. CONSTs don't need array
support because the declara
nir/nir_control_flow.c: In function ‘split_block_cursor.isra.11’:
nir/nir_control_flow.c:460:15: warning: ‘after’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
*_after = after;
^
nir/nir_control_flow.c:458:16: warning: ‘before’ may be used uninitialized i
On 11/02/2015 09:16 AM, Ilia Mirkin wrote:
On Mon, Nov 2, 2015 at 1:58 AM, Tapani Pälli wrote:
Patch changes linker to allocate gl_shader_variable instead of using
ir_variable. This makes it possible to get rid of ir_variables and ir
in memory after linking.
v2: check that we do not create d
On 30/10/15 21:26, Kristian Høgsberg wrote:
On Fri, Oct 30, 2015 at 06:03:31PM +0200, Martin Peres wrote:
First of all, I would like to thank Boyan for his work here. I rebased his patch
series, fixed minor issues here and there and reviewed it. You can check the
changes in every patch but the b
On 30/10/15 18:17, Matt Turner wrote:
On Fri, Oct 30, 2015 at 9:03 AM, Martin Peres
wrote:
diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
index 5c2ba30..cdf2216 100644
--- a/src/egl/Makefile.am
+++ b/src/egl/Makefile.am
@@ -47,12 +47,18 @@ libEGL_la_LDFLAGS = \
$(LD_NO_UNDEFINE
Reviewed-by: Marta Lofstedt
> -Original Message-
> From: Justen, Jordan L
> Sent: Monday, November 2, 2015 9:36 AM
> To: mesa-dev@lists.freedesktop.org
> Cc: Justen, Jordan L; Iago Toral Quiroga; Lofstedt, Marta
> Subject: [PATCH v2 2/2] mesa: Add spec citations for DispatchCompute*
>
>
Reviewed-by: Marta Lofstedt
> -Original Message-
> From: Justen, Jordan L
> Sent: Monday, November 2, 2015 9:36 AM
> To: mesa-dev@lists.freedesktop.org
> Cc: Justen, Jordan L; Iago Toral Quiroga; Lofstedt, Marta
> Subject: [PATCH v2 1/2] mesa: Update DispatchComputeIndirect errors for
>
Note: The OpenGL 4.3 - 4.5 specification language for DispatchCompute
appears to have an error regarding the max allowed values. When adding
the specification citation, we note why the code does not match the
specification language.
v2:
* Updates based on review from Iago
Signed-off-by: Jordan J
There is some discrepancy between the return values for some error
cases for the DispatchComputeIndirect call in the ARB_compute_shader
specification. Regarding the indirect parameter, in one place the
extension spec lists that the error returned for invalid values should
be INVALID_OPERATION, whil
On Sun, Nov 1, 2015 at 3:33 AM, Timothy Arceri wrote:
> Handles the case with function inout params where array elements
> do an assignment to themselves e.g.
>
> void array_mod(inout int b[2])
> {
> b[0] = int(2);
> b[1] = b[1];
> }
>
> Fixes assert in nir for:
> ES31-CTS.arrays_of_a
Reviewed-by: Marta Lofstedt
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Timothy Arceri
> Sent: Sunday, November 1, 2015 9:33 AM
> To: mesa-dev@lists.freedesktop.org
> Subject: [Mesa-dev] [PATCH] glsl: remove redundant function inou
88 matches
Mail list logo
