On Sun, 2015-10-18 at 21:31 -0700, Kristian Høgsberg Kristensen wrote:
> I've been giving the SSBO functionality a closer look and I found a
> few problems, each addressed by a patch in this series. The commit
> messages describe the issues and the fixes, but the net effect takes
> my vertex shader
On Tue, 2015-10-20 at 00:12 -0700, Jordan Justen wrote:
> An untyped surface read is volatile because it might be affected by a
> write.
>
> In the ES31-CTS.compute_shader.resources-max test, two back to back
> read/modify/writes of an SSBO variable looked something like this:
>
> r1 = untyped_
es sense to me,
Reviewed-by: Iago Toral Quiroga
Out of curiosity, does moving from the null register have any actual
consequences?
Iago
> ---
> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp| 18 +-
> src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp | 2 +-
&g
On Mon, 2015-10-19 at 23:11 -0700, Matt Turner wrote:
> On Mon, Oct 19, 2015 at 9:09 PM, Matt Turner wrote:
> > We implement textureQueryLevels (which takes no arguments, save the
> > sampler) using the resinfo message (which takes an argument of LOD).
> > Without initializing it, we'd generate a
Reviewed-by: Iago Toral Quiroga
On Mon, 2015-10-19 at 21:09 -0700, Matt Turner wrote:
> The next commit will add assertions dependent on devinfo->gen.
>
> Use compact()/uncompact() macros where possible, like the 3-src code
> does.
> ---
> src/mesa/drivers/dri/i965/b
On Mon, 2015-10-19 at 21:09 -0700, Matt Turner wrote:
> It only exists on Gen6+, and the next patches will add compaction
> support for the (unused) field in the same location on earlier
> platforms.
The docs say that this exists also in ILK at least. See Page 131 of:
https://01.org/sites/default/
On Tue, 2015-10-20 at 13:22 +0300, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> > This allows us to re-use the results of previous ssbo loads in situations
> > that are safe (i.e. when there are no stores, atomic operations or
> > memory barriers in b
On Tue, 2015-10-20 at 14:18 +0300, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Tue, 2015-10-20 at 13:22 +0300, Francisco Jerez wrote:
> >> Iago Toral Quiroga writes:
> >>
> >> > This allows us to re-use the results of previous ssbo loads in
On Tue, 2015-10-20 at 10:51 +0200, Iago Toral wrote:
> On Mon, 2015-10-19 at 21:09 -0700, Matt Turner wrote:
> > It only exists on Gen6+, and the next patches will add compaction
> > support for the (unused) field in the same location on earlier
> > platforms.
>
> Th
Reviewed-by: Iago Toral Quiroga
On Mon, 2015-10-19 at 21:09 -0700, Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i965/brw_inst.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_inst.h
> b/src/mesa/drivers/dri/i965/
Reviewed-by: Iago Toral Quiroga
On Mon, 2015-10-19 at 21:09 -0700, Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i965/brw_inst.h | 32
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_inst.
On Tue, 2015-10-20 at 11:38 -0700, Matt Turner wrote:
> On Tue, Oct 20, 2015 at 1:51 AM, Iago Toral wrote:
> > On Mon, 2015-10-19 at 21:09 -0700, Matt Turner wrote:
> >> It only exists on Gen6+, and the next patches will add compaction
> >> support for the (unused) fi
On Mon, 2015-10-19 at 21:09 -0700, Matt Turner wrote:
> Documentation is sparse, but it appears to have existed on G45 and ILK
> as a second bit extension of the mask_control field. Setting the pair of
> bits to 0b11 enables "NoCMask".
It shows up in the compacted table for g45 in bit 23, but bit
Hi Curro,
On Tue, 2015-10-20 at 14:18 +0300, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Tue, 2015-10-20 at 13:22 +0300, Francisco Jerez wrote:
> >> Iago Toral Quiroga writes:
> >>
> >> > This allows us to re-use the results of previous ssb
On Wed, 2015-10-21 at 00:50 -0700, Matt Turner wrote:
> On Tue, Oct 20, 2015 at 11:46 PM, Iago Toral wrote:
> > On Mon, 2015-10-19 at 21:09 -0700, Matt Turner wrote:
> >> Documentation is sparse, but it appears to have existed on G45 and ILK
> >> as a second bit ex
Hi,
The problem is with code like this (see brw_send_indirect_message):
setup = brw_OR(p, addr, desc, brw_imm_ud(0));
send = next_insn(p, BRW_OPCODE_SEND);
...
return setup;
If next_insn triggers a realloc of the instruction store, then the setup
instruction pointer is no longer valid. Notice th
On Wed, 2015-10-21 at 13:00 +0300, Francisco Jerez wrote:
> Iago Toral writes:
>
> > Hi Curro,
> >
> > On Tue, 2015-10-20 at 14:18 +0300, Francisco Jerez wrote:
> >> Iago Toral writes:
> >>
> >> > On Tue, 2015-10-20 at 13:22 +0300, Fra
On Wed, 2015-10-21 at 14:58 +0300, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Wed, 2015-10-21 at 13:00 +0300, Francisco Jerez wrote:
> >> Iago Toral writes:
> >>
> >> > Hi Curro,
> >> >
> >> > On Tue, 2015-10-20
Reviewed-by: Iago Toral Quiroga
On Wed, 2015-10-21 at 12:30 -0700, Matt Turner wrote:
> We implement textureQueryLevels (which takes no arguments, save the
> sampler) using the resinfo message (which takes an argument of LOD).
> Without initializing it, we'd generate a MOV from the
On Wed, 2015-10-21 at 23:24 -0700, Jordan Justen wrote:
> On 2015-10-20 00:43:13, Iago Toral wrote:
> > On Tue, 2015-10-20 at 00:12 -0700, Jordan Justen wrote:
> > > An untyped surface read is volatile because it might be affected by a
> > > writ
On Thu, 2015-10-22 at 09:39 -0400, Connor Abbott wrote:
> On Thu, Oct 22, 2015 at 7:21 AM, Iago Toral Quiroga wrote:
> > I implemented this first as a separate optimization pass in GLSL IR [1], but
> > Curro pointed out that this being pretty much a restricted form of a CSE
> &
On Thu, 2015-10-22 at 16:38 +0200, Iago Toral wrote:
> On Thu, 2015-10-22 at 09:39 -0400, Connor Abbott wrote:
> > On Thu, Oct 22, 2015 at 7:21 AM, Iago Toral Quiroga
> > wrote:
> > > I implemented this first as a separate optimization pass in GLSL IR [1],
> > >
On Thu, 2015-10-22 at 09:09 -0700, Jason Ekstrand wrote:
> On Thu, Oct 22, 2015 at 4:21 AM, Iago Toral Quiroga wrote:
> > I implemented this first as a separate optimization pass in GLSL IR [1], but
> > Curro pointed out that this being pretty much a restricted form of a CSE
On Fri, 2015-10-23 at 09:26 -0700, Jason Ekstrand wrote:
> On Thu, Oct 22, 2015 at 11:13 PM, Iago Toral wrote:
> > On Thu, 2015-10-22 at 09:09 -0700, Jason Ekstrand wrote:
> >> On Thu, Oct 22, 2015 at 4:21 AM, Iago Toral Quiroga
> >> wrote:
> >> >
Reviewed-by: Iago Toral Quiroga
On Sat, 2015-10-24 at 13:20 -0700, Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> b/src/mes
On Tue, 2015-10-27 at 14:33 +0200, Pohjolainen, Topi wrote:
> On Tue, Oct 27, 2015 at 10:28:58AM +0100, Iago Toral Quiroga wrote:
> > We need this so we can configure different behaviors for passes that
> > cannot deal with side-effectful instructions (CSE) and passes that can
>
Yeah, this makes things more consistent:
Reviewed-by: Iago Toral Quiroga
On Tue, 2015-10-27 at 22:38 -0700, Jordan Justen wrote:
> Signed-off-by: Jordan Justen
> Cc: Samuel Iglesias Gonsálvez
> Cc: Iago Toral Quiroga
> ---
> src/glsl/link_uniform_initializers.cpp | 2
On Wed, 2015-10-28 at 09:11 +0100, Iago Toral wrote:
> Yeah, this makes things more consistent:
> Reviewed-by: Iago Toral Quiroga
I meant:
Reviewed-by: Iago Toral Quiroga
>
> On Tue, 2015-10-27 at 22:38 -0700, Jordan Justen wrote:
> > Signed-off-by: Jordan Justen
>
On Tue, 2015-10-27 at 22:38 -0700, Jordan Justen wrote:
> Signed-off-by: Jordan Justen
> Cc: Samuel Iglesias Gonsálvez
> Cc: Iago Toral Quiroga
> ---
> src/glsl/linker.cpp | 14 ++
> src/glsl/standalone_scaffolding.cpp | 5 +
> s
65.
>
> Signed-off-by: Jordan Justen
> Cc: Samuel Iglesias Gonsálvez
> Cc: Iago Toral Quiroga
> ---
> src/mesa/main/uniforms.c | 30 --
> 1 file changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/src/mesa/main/uniforms.c b/src/mes
the SSBO
definition, so maybe it is redundant... if we don't want to add that
check, then maybe it is worth amending the comment to explain why though
(and even in that case maybe we want to add an assert).
With these changes:
Reviewed-by: Iago Toral Quiroga
> + const g
t fall in that case anyway.
Reviewed-by: Iago Toral Quiroga
> ---
> src/mesa/drivers/dri/i965/brw_disasm.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c
> b/src/mesa/drivers/dri/i965/brw_disasm.c
>
> + /* Which patch inputs are actually read */
> + uint64_t patch_inputs_read;
> + /* Which patch outputs are actually written */
> + uint64_t patch_outputs_written;
These two should be fine as uint32_t since we set them from a GLBitfield
which is 32-bit after all... or maybe you wer
7;t generally
need to hold pointers to previous instructions and the places where we
do, like in brw_ENDIF or brw_WHILE we are careful to create the
instructions we need before we look for pointers to others (which we do
using indices into the store anyway).
Reviewed-by: Iago Toral Quiroga
I'
Reviewed-by: Iago Toral Quiroga
On Thu, 2015-10-29 at 00:46 -0700, Jordan Justen wrote:
> Signed-off-by: Jordan Justen
> ---
> src/glsl/builtin_variables.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/glsl/builtin_variab
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.
Maybe expand the commit log to make explicit that this is for GLES 3.1
and desktop GL since 4.2
Reviewed-by: Iago
Reviewed-by: Iago Toral Quiroga
On Thu, 2015-10-29 at 00:47 -0700, Jordan Justen wrote:
> Signed-off-by: Jordan Justen
> ---
> src/mesa/main/get_hash_params.py | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/main/get_hash_params.py
> b/src/mesa/ma
s_abo_surfaces,
> &brw_texture_surfaces,
> diff --git a/src/mesa/drivers/dri/i965/gen7_cs_state.c
> b/src/mesa/drivers/dri/i965/gen7_cs_state.c
> index 6aeb0cb..da1d05f 100644
> --- a/src/mesa/drivers/dri/i965/gen7_cs_state.c
> +++ b/src/mesa/drivers/dri/i965/gen
On Thu, 2015-10-29 at 00:50 -0700, Jordan Justen wrote:
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 6 --
> src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 6 --
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/
nstead of %d here. The same in a bunch
of of the other hunks in this patch.
Either way,
Reviewed-by: Iago Toral Quiroga
> if (!pipe) {
>_mesa_error(ctx, GL_INVALID_OPERATION, "glUseProgramStages(pipeline)");
>return;
> @@ -345,6 +349,9 @@ _mesa_ActiveSh
SA_SHADER_COMPUTE] == NULL) {
>_mesa_error(ctx, GL_INVALID_OPERATION,
>"%s(no active compute shader)",
This hunk won't apply on current master, there is no such comment before
this line. Maybe this is part of another series of patches?
For the rest
On Wed, 2015-10-14 at 13:46 -0700, Jordan Justen wrote:
> There is a discrepancy between the ARB_compute_shader specification,
> and the OpenGL 4.3 and OpenGLES 3.1 specifications. With regards to
> the indirect dispatch parameter, unsupported value errors should
> return INVALID_VALUE according to
On Thu, 2015-10-29 at 10:06 -0700, Jordan Justen wrote:
> On 2015-10-29 03:04:38, Iago Toral wrote:
> > On Thu, 2015-10-29 at 00:52 -0700, Jordan Justen wrote:
> > > Signed-off-by: Jordan Justen
> > > ---
> > > src/mesa/main/api_validate.c | 2 +-
>
On Thu, 2015-10-29 at 10:44 -0700, Jordan Justen wrote:
> On 2015-10-29 02:17:20, Iago Toral wrote:
> > On Thu, 2015-10-29 at 00:50 -0700, Jordan Justen wrote:
> > > Signed-off-by: Jordan Justen
> > > ---
> > > src/mesa/drivers/dri/i965/brw_fs_nir.cpp |
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
> spec
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 A
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
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 dir
On Tue, 2015-11-03 at 15:28 +0200, Francisco Jerez wrote:
> Iago Toral writes:
>
> > 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 indexi
On Tue, 2015-11-03 at 09:19 -0800, Mark Janes wrote:
> Francisco Jerez writes:
>
> > Iago Toral writes:
> >
> >> On Tue, 2015-11-03 at 15:28 +0200, Francisco Jerez wrote:
> >>> Iago Toral writes:
> >>>
> >>> > On Fri, 201
Hi,
Currently, NIR defines vecN operations as unsigned (integer). The fp64
patches from Connor change this to float (I guess because we need to
know the case where we are packing vectors of 64-bit floats). However,
this makes it so that nir_lower_source_to_mods turns this:
vec1 ssa_2 = f
x->Const.ShaderCompilerOptions[i].LowerBufferInterfaceBlocks) {
for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
if (prog->_LinkedShaders[i] != NULL)
lower_ubo_reference(prog->_LinkedShaders[i]);
}
}
With that change, and assuming that this change is not respon
Reviewed-by: Iago Toral Quiroga
On Wed, 2015-11-04 at 15:33 -0800, Kristian Høgsberg Kristensen wrote:
> We always pass in shader->ir and we already pass in the shader, so just
> drop the exec_list. Most passes either take just a exec_list or a
> shader, so this seems mor
On Mon, 2015-11-09 at 16:52 +0100, Iago Toral wrote:
> On Wed, 2015-11-04 at 15:33 -0800, Kristian Høgsberg Kristensen wrote:
> > All GLSL IR consumers run this lowering pass so we can move it to the
> > linker. This moves the pass up quite a bit, but that's the point: it
>
On Mon, 2015-11-09 at 12:27 -0500, Connor Abbott wrote:
> On Mon, Nov 9, 2015 at 10:41 AM, Jason Ekstrand wrote:
> >
> > On Nov 9, 2015 7:24 AM, "Connor Abbott" wrote:
> >>
> >> On Mon, Nov 9, 2015 at 6:55 AM, Iago Toral wrote:
> >> > Hi,
On Fri, 2015-11-06 at 14:03 +0200, Tapani Pälli wrote:
> From: Iago Toral Quiroga
>
> We will need this later on when we implement proper support for
> precision qualifiers in the drivers and also to do link time checks for
> uniforms as indicated by the spec.
>
> This pa
s/loose/lose
Reviewed-by: Iago Toral Quiroga
On Thu, 2015-11-05 at 13:33 +0200, Tapani Pälli wrote:
> This information will be used by cross stage validation of varyings
> for pipeline objects.
>
> Signed-off-by: Tapani Pälli
> ---
> src/glsl/lower_packed_varyings.cpp | 1 +
On Tue, 2015-11-10 at 12:41 +0200, Tapani Pälli wrote:
>
> On 11/10/2015 12:26 PM, Iago Toral wrote:
> > On Fri, 2015-11-06 at 14:03 +0200, Tapani Pälli wrote:
> >> From: Iago Toral Quiroga
> >>
> >> We will need this later on when we implement proper suppo
On Thu, 2015-11-05 at 13:33 +0200, Tapani Pälli wrote:
> Fixes following failing ES3.1 CTS tests:
>
>ES31-CTS.sepshaderobjs.InterfacePrecisionMatchingFloat
>ES31-CTS.sepshaderobjs.InterfacePrecisionMatchingInt
>ES31-CTS.sepshaderobjs.InterfacePrecisionMatchingUInt
>
> Signed-off-by: T
On Tue, 2015-11-10 at 12:10 +0100, Iago Toral wrote:
> On Thu, 2015-11-05 at 13:33 +0200, Tapani Pälli wrote:
> > Fixes following failing ES3.1 CTS tests:
> >
> >ES31-CTS.sepshaderobjs.InterfacePrecisionMatchingFloat
> >ES31-CTS.sepshaderobjs.InterfacePreci
On Thu, 2015-11-05 at 13:33 +0200, Tapani Pälli wrote:
> From: Iago Toral Quiroga
>
> The GLSL ES spec specifies default precision qualifiers for certain types,
> so populate the symbol table with these.
>
> Notice that the desktop GLSL spec also indicates defaults for some t
On Tue, 2015-11-10 at 13:34 +0200, Tapani Pälli wrote:
>
> On 11/10/2015 01:15 PM, Iago Toral wrote:
> > On Tue, 2015-11-10 at 12:10 +0100, Iago Toral wrote:
> >> On Thu, 2015-11-05 at 13:33 +0200, Tapani Pälli wrote:
> >>> Fixes following failing ES3.
Reviewed-by: Iago Toral Quiroga
On Thu, 2015-11-12 at 00:44 -0800, Jordan Justen wrote:
> This commit accidentally used a '==' when '=' was intended.
>
> commit 96b22fb080894ba1840af2372f28a46cc0f40c76
> Author: Kristian Høgsberg Kristensen
> Date: Wed Nov
On Thu, 2015-11-12 at 16:13 +1100, Timothy Arceri wrote:
> From: Timothy Arceri
>
> We already give the location of the qualifier so there is
> no need to list all the identifiers in the error message.
However, there can be multiple layout qualifiers in the same declaration
and in that case, wit
Patches 1-4 are,
Reviewed-by: Iago Toral Quiroga
Patch 5 seems to be missing.
Iago
On Wed, 2015-11-11 at 17:23 -0800, Jason Ekstrand wrote:
> On older hardware (Iron Lake and below), we can't support texture rectangle
> natively. Sandy Bridge through Haswell can support it but do
On Thu, 2015-11-12 at 16:23 +0100, Iago Toral wrote:
> Patches 1-4 are,
> Reviewed-by: Iago Toral Quiroga
>
> Patch 5 seems to be missing.
Oh never mind, I've just seen your reply to the thread pointing to the
repository.
Iago
> Iago
>
> On Wed, 2015-11-11 at 1
s/satages/stages in the shortlog. Other than that it looks good to me:
Reviewed-by: Iago Toral Quiroga
On Wed, 2015-11-11 at 17:26 -0800, Jason Ekstrand wrote:
> At the moment, brw_create_nir just calls the three stages in sequence so
> there's not much difference. Soon, however, w
oreach_overload(shader, overload) {
>if (overload->impl)
> nir_lower_tex_impl(overload->impl, &state);
> }
> +
> + return state.progress;
> }
If we are making this change then we also want to make the call to this
pass use OPT() instead of OPT
Reviewed-by: Iago Toral Quiroga
On Wed, 2015-11-11 at 17:26 -0800, Jason Ekstrand wrote:
> ---
> src/glsl/nir/nir_lower_tex.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/glsl/nir/nir_lower_tex.c b/src/glsl/nir/nir_lower_tex.c
> index 21ed103..6dea837 10064
ot sampled. Instead, the
width, height, depth, and MIP count of the surface are returned as
indicated in the table below. The format of the returned data is UINT32"
I see the same text for HSW and BDW. Either way:
Reviewed-by: Iago Toral Quiroga
> + if (inst->opcode == SHADER_O
On Wed, 2015-11-11 at 17:26 -0800, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 11 +--
> src/mesa/drivers/dri/i965/brw_nir.c | 1 -
> src/mesa/drivers/dri/i965/brw_vec4.cpp| 5 -
> src/mesa/drivers/dri/i965/brw_vec4_gs_v
Ian, does this version get your R-b?
On Tue, 2015-01-20 at 17:07 +0100, Iago Toral Quiroga wrote:
> v2 (Ian Romanick)
> - Move the check to the lexer before rallocing a copy of the large string.
>
> Fixes the following 2 dEQP tests:
On Tue, 2015-01-20 at 12:34 +0100, Iago Toral wrote:
> On Mon, 2015-01-19 at 19:39 -0800, Ian Romanick wrote:
> > On 01/19/2015 03:32 AM, Eduardo Lima Mitev wrote:
> > > From: Iago Toral Quiroga
> > >
> > > Currently, we only consider precision qualifier
Hi,
I think I have found a bug that can even produce a GPU hang in the i965
code that handles 1DArray textures and that is related to the miptree
structure that supports them. At least IvyBridge and Haswell are
affected.
The problem happens when we need to drop the initial miptree to create a
new
On Wed, 2015-01-28 at 10:48 +0100, Iago Toral wrote:
> Hi,
>
> I think I have found a bug that can even produce a GPU hang in the i965
> code that handles 1DArray textures and that is related to the miptree
> structure that supports them. At least IvyBridge and Haswell are
>
On Wed, 2015-01-28 at 13:39 +0100, Iago Toral wrote:
> On Wed, 2015-01-28 at 10:48 +0100, Iago Toral wrote:
> > Hi,
> >
> > I think I have found a bug that can even produce a GPU hang in the i965
> > code that handles 1DArray textures and that is related to the miptree
On Fri, 2015-02-06 at 10:47 +0200, Ian Romanick wrote:
> On 01/26/2015 10:09 AM, Iago Toral wrote:
> > On Tue, 2015-01-20 at 12:34 +0100, Iago Toral wrote:
> >> On Mon, 2015-01-19 at 19:39 -0800, Ian Romanick wrote:
> >>> On 01/19/2015 03:32 AM, Eduardo Lima Mitev
Hi,
Eduardo and I have been looking into a few dEQP test failures that deal
with wide line rendering. There are a few of them that fail because of
how clipping is implemented for this case.
The problem in these cases seems to be that the hw renders the wide line
as a parallelogram so that if an e
On Fri, 2015-02-06 at 21:27 +0100, Roland Scheidegger wrote:
> Am 06.02.2015 um 13:11 schrieb Iago Toral:
> > Hi,
> >
> > Eduardo and I have been looking into a few dEQP test failures that deal
> > with wide line rendering. There are a few of them that fail bec
On Sat, 2015-02-07 at 13:41 +0100, Erik Faye-Lund wrote:
> On Fri, Feb 6, 2015 at 1:11 PM, Iago Toral wrote:
> > Hi,
> >
> > Eduardo and I have been looking into a few dEQP test failures that deal
> > with wide line rendering. There are a few of them that fail bec
On Tue, 2015-02-10 at 09:24 -0800, Ian Romanick wrote:
> On 02/10/2015 08:10 AM, Brian Paul wrote:
> > On 02/10/2015 08:40 AM, Eduardo Lima Mitev wrote:
> >> From: Iago Toral Quiroga
> >>
> >> ---
> >> src/mesa/main/teximage.c | 22 ++
On Tue, 2015-02-10 at 09:33 -0800, Ian Romanick wrote:
> On 02/10/2015 07:40 AM, Eduardo Lima Mitev wrote:
> > From: Iago Toral Quiroga
> >
> > The intel driver code, and apparently all other Mesa drivers, call
> > _mesa_initialize_context early in the CreateContext h
Hi,
is this assertion in ir_assignment::ir_assignment() src/glsl/ir.cpp
correct?
assert(lhs_components == this->rhs->type->vector_elements);
We will hit this any time we emit code such as this:
assign(var1, expr, WRITEMASK_XY)
where expr and var1 are vec3. At least if we emit that code from
lo
On Thu, 2015-02-12 at 08:05 -0800, Ian Romanick wrote:
> On 02/12/2015 06:19 AM, Iago Toral wrote:
> > Hi,
> >
> > is this assertion in ir_assignment::ir_assignment() src/glsl/ir.cpp
> > correct?
> >
> > assert(lhs_components == this->rhs->type->
On Fri, 2015-02-13 at 10:18 -0800, Ian Romanick wrote:
> On 02/13/2015 03:56 AM, Iago Toral Quiroga wrote:
> > Some old format conversion code in pack.c implemented byte-swapping like
> > this:
> >
> > GLint comps = _mesa_components_in_format(dst
) when buffer is not
> color or stencil
> mesa: Add missing error checks to GetProgramInfoLog, GetShaderInfoLog
> and GetProgramiv
> mesa: Fix error validating args for TexSubImage3D
> mesa: Return INVALID_OPERATION when querying a never bound Query obj
> mesa: Return error i
On Fri, 2015-02-06 at 15:03 +0100, Iago Toral Quiroga wrote:
> Currently, we only consider precision qualifiers at compile-time. This patch
> adds precision information to ir_variable so we can also do link time checks.
> Specifically, from the GLSL ES3 spec, 4.5.3 Precision Qualifiers:
On Wed, 2015-02-25 at 10:01 +0100, Iago Toral wrote:
> On Fri, 2015-02-06 at 15:03 +0100, Iago Toral Quiroga wrote:
> > Currently, we only consider precision qualifiers at compile-time. This patch
> > adds precision information to ir_variable so we can also do link t
This looks good. Sorry for the missing break :-(
Iago
On Sat, 2015-02-28 at 11:02 -0800, Matt Turner wrote:
> Always indenting break statements makes spotting missing ones easier.
>
> Cc: 10.5
> ---
> src/mesa/main/pack.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
>
On Sat, 2015-02-28 at 11:10 -0800, Matt Turner wrote:
> ---
> src/mesa/main/readpix.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
> index 2e4a460..ed0104c 100644
> --- a/src/mesa/main/readpix.c
> +++ b/src/mesa/main/readpix.c
> @@ -59
0
>
>
> Perhaps shader-db doesn't account for some other GL state
> required for dual-source because I doubt only one shader uses
> it. Ken?
>
>
>
> --Jason
&
utput.46
Reviewed-by: Iago Toral Quiroga
> Cc: "17.0"
> Cc: Iago Toral
> Cc: Jason Ekstrand
> Signed-off-by: Nanley Chery
> ---
> src/intel/vulkan/genX_cmd_buffer.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/
Reviewed-by: Iago Toral Quiroga
On Tue, 2017-01-31 at 15:20 -0500, Robert Foss wrote:
> Add assert checking that num_sources is never larger than 3.
>
> This prevents Coverity from concluding that the unhandled
> cases of num_sources not being 0-3 are relevant.
>
> Coverity-I
os... Maybe add a FIXME
indicating this situation so we know we have not verified that this is
actually needed.
Reviewed-by: Iago Toral Quiroga
> Reported-by: Mark Janes
> Tested-by: Mark Janes
> ---
> src/intel/vulkan/genX_cmd_buffer.c | 5 ++---
> 1 file changed, 2 inserti
Both patches are:
Reviewed-by: Iago Toral Quiroga
On Wed, 2017-02-08 at 12:35 +1100, Timothy Arceri wrote:
> V2: actually use PRIu64
> ---
> src/mesa/main/uniform_query.cpp | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/uniform
This patch is missing to actually change the implementation in
brw_shader.cpp to not return a uint32_t result.
With that fixed, this patch is:
Reviewed-by: Iago Toral Quiroga
On Tue, 2017-02-07 at 15:03 -0800, Jason Ekstrand wrote:
> It doesn't really matter what order the binding table
inding_table.size_bytes =
> - MAX2(prog_data->binding_table.size_bytes, (surf_index + 1) *
> 4);
> -}
> -
> enum brw_reg_type
> brw_type_for_base_type(const struct glsl_type *type)
> {
> @@ -1155,7 +1145,7 @@ backend_shader::calculate_cfg()
> * unused but
This patch is:
Reviewed-by: Iago Toral Quiroga
On Sat, 2017-02-11 at 02:36 -0800, Kenneth Graunke wrote:
> For GS input arrays, we may turn a packed_type of ivec4 into an
> array of ivec4s. We still want flat qualification.
>
> Found by inspection. Not known to help anything.
>
On Sat, 2017-02-11 at 02:36 -0800, Kenneth Graunke wrote:
> In ES 3.0, interpret_interpolation_qualifier() defaults unset
> interpolation qualifiers to "smooth"...which has the strange result
> of marking some integer variables "smooth".
>
> Interpolation qualifiers really only matter for fragment
On Mon, 2017-02-13 at 16:29 +, Lionel Landwerlin wrote:
> Run this by our CI earlier today and got a few failures :
>
> dEQP-VK.image.load_store.buffer.r8g8b8a8_snorm
> dEQP-VK.image.load_store.buffer.r8g8b8a8_unorm
> dEQP-VK.image.format_reinterpret.buffer.r32_uint_r8g8b8a8_snorm
> dEQP-VK.im
101 - 200 of 3167 matches
Mail list logo
