The caller to brw_next_insn() could be brw_send_indirect_message()
as a result of creating a SEND instruction after the OR
used to load the indirect descriptor to an address register.
In that case, the pointer to the OR instruction is
p->store[p->nr_insn - 1] and as it will be saved to specify add
Hello,
I have found several invalid memory accesses when running
dEQP-GLES31.functional.ssbo.* tests on i965 driver (and gen7+). That
invalid memory accesses were unluckily happening when generating the
assembly instructions for SSBO stores for different compute shaders.
However it looks like thi
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 extension of the mask_control field. Setting the pair of
>> bits to 0b11 enables "NoCMask".
>
> I
On Wed, Oct 21, 2015 at 12:50 AM, Matt Turner wrote:
> I've got a snapshot of the internal BSpec as PDFs that still has
> useful Ironlake information, and that's where the "NoCMask"
> information comes from. The G45 docs simply say that 0b11 is
> "Reserved", but it's unclear whether that's actuall
On 21/10/2015 00:10, Bas Nieuwenhuizen wrote:
DCC is disabled for textures that can be shared as sharing the
DCC buffers has not been implemented yet.
+ surf->dcc_enabled = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER) &&
+!(surf->flags & RADEON_SURF_SCANOUT) &&
+
On Tue, Oct 20, 2015 at 7:19 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> OpenGL ES 3.1 spec. section 10.5:
> "An INVALID_OPERATION error is generated if zero is bound
> to VERTEX_ARRAY_BINDING, DRAW_INDIRECT_BUFFER or to
> any enabled vertex array."
>
> Signed-off-by: Marta Lofstedt
> -
Just realized that I sent this email with extra comments off-list.
Sending to the list now. Additionally, just a gentle reminder that this
is the only patch pending to be reviewed in this series, that have
already 5 patches reviewed.
Thanks in advance.
On 19/10/15 19:38, Alejandro Piñeiro wrote:
On Monday, October 12, 2015 02:49:03 PM Kenneth Graunke wrote:
> In the vec4 backend, we have a vec4_instruction::urb_write_flags field.
> There are many kinds of flags for SIMD4x2 messages.
>
> However, there are really only two (per-slot offset, use channel masks)
> for SIMD8 messages. Rather t
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 ssbo loads in situations
> >> > that are safe (i
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 extension of the mask_control field
Ilia Mirkin writes:
>> - if (tex_inst->opcode == SHADER_OPCODE_TG4 ||
>> + if (tex_inst->opcode == SHADER_OPCODE_TXS ||
>> + tex_inst->opcode == SHADER_OPCODE_LOD ||
>> + tex_inst->opcode == SHADER_OPCODE_TG4 ||
>> tex_inst->opcode == SHADER_OPCODE_TG4_OFFSET)
>
> Do you a
On Tue, Oct 20, 2015 at 02:02:21PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 20, 2015 at 08:15:32AM +, Predut, Marius wrote:
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > > Sent: Monday, October 19, 2015 6:04 PM
> > > To: Predut, Marius
>
On Wed, Oct 21, 2015 at 9:56 AM, Axel Davy wrote:
> On 21/10/2015 00:10, Bas Nieuwenhuizen wrote:
>>
>>
>> DCC is disabled for textures that can be shared as sharing the
>> DCC buffers has not been implemented yet.
>>
>>
>> + surf->dcc_enabled = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER) &&
>>
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, Francisco Jerez wrote:
>> >> Iago Toral Quiroga writes:
>> >>
>> >> > This allows us to re-use the results of previous ssbo loads in
>
Timothy Arceri writes:
> On Fri, 2015-10-16 at 10:28 +1100, Timothy Arceri wrote:
>> Cc: Francisco Jerez
>
> Hi Curro,
>
> Just pinging you on this patch and patch 5. These are the final two
> patches remaining unreviewed before I can enable arrays of arrays.
>
> If your not able to review these
Ben Widawsky writes:
> Cc: Francisco Jerez
> Signed-off-by: Ben Widawsky
> ---
> src/mesa/drivers/dri/i965/brw_defines.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
> b/src/mesa/drivers/dri/i965/brw_defines.h
> index 393
Commit f24e5e did not take into account arrays of named shader
storage blocks.
Fixes 20 dEQP-GLES31.functional.ssbo.* tests:
dEQP-GLES31.functional.ssbo.layout.single_struct_array.per_block_buffer.shared_instance_array
dEQP-GLES31.functional.ssbo.layout.single_struct_array.per_block_buffer.packed
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:06 +0300, Francisco Jerez wrote:
> Timothy Arceri writes:
>
> > On Fri, 2015-10-16 at 10:28 +1100, Timothy Arceri wrote:
> > > Cc: Francisco Jerez
> >
> > Hi Curro,
> >
> > Just pinging you on this patch and patch 5. These are the final two
> > patches remaining unrevi
The back buffers need to be scanout-able in case
the compositor wants to use the buffer (once sent)
as display framebuffer.
Signed-off-by: Axel Davy
---
src/egl/drivers/dri2/platform_wayland.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/egl/drivers/dri2/platfo
Add a new bind flag to differentiate shared resources
that must be readable after any flush, or that can afford
being readable only after flush_resource.
Previously the two cases were mixed, and implictly things were done
such that there would be no issues.
flush_resource is called for:
. st/nine
The PIPE_BIND_SHARED flag should be added whenever
the resource may be shared with another process.
In particular if the resource is imported, or may
be exported, the flag should be used.
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/dri/dri2.c | 9 +++--
src/gallium/state
Add __DRI_IMAGE_USE_BACKBUFFER to indicate the
image is going to be used as a backbuffer.
Backbuffers are going to be attached as
__DRI_BUFFER_BACK_LEFT or
__DRI_BUFFER_BACK_RIGHT.
This flag enables the driver to assume the
buffer will only be read by an external process after
a swapbuffer, in co
On Wed, Oct 21, 2015 at 7:16 AM, Tapani Pälli wrote:
> On 10/20/2015 08:54 PM, Marek Olšák wrote:
>>
>> On Tue, Oct 20, 2015 at 4:19 PM, Marta Lofstedt
>> wrote:
>>>
>>> From: Marta Lofstedt
>>>
>>> OpenGL ES 3.1 spec. section 10.5:
>>> "An INVALID_OPERATION error is generated if zero is bound
>
Timothy Arceri writes:
> On Wed, 2015-10-21 at 13:06 +0300, Francisco Jerez wrote:
>> Timothy Arceri writes:
>>
>> > On Fri, 2015-10-16 at 10:28 +1100, Timothy Arceri wrote:
>> > > Cc: Francisco Jerez
>> >
>> > Hi Curro,
>> >
>> > Just pinging you on this patch and patch 5. These are the fin
On Wed, Oct 21, 2015 at 12:28 PM, Axel Davy wrote:
> +/* This flag indicates that in addition to being shared, the resource won't
> be
> + * read by any external process before we call flush_resource. This allows
> + * things like compressing the buffer when drawing, while uncompressing on
> + *
On 10/21/2015 01:41 PM, Marek Olšák wrote:
On Wed, Oct 21, 2015 at 7:16 AM, Tapani Pälli wrote:
On 10/20/2015 08:54 PM, Marek Olšák wrote:
On Tue, Oct 20, 2015 at 4:19 PM, Marta Lofstedt
wrote:
From: Marta Lofstedt
OpenGL ES 3.1 spec. section 10.5:
"An INVALID_OPERATION error is generated
On 21/10/2015 13:16, Bas Nieuwenhuizen wrote:
On Wed, Oct 21, 2015 at 12:28 PM, Axel Davy wrote:
+/* This flag indicates that in addition to being shared, the resource won't be
+ * read by any external process before we call flush_resource. This allows
+ * things like compressing the buffer whe
Ben Widawsky writes:
> Gen9 adds the ability to write out a stencil value, so we need to expand the
> virtual payload by one. Abstracting this now makes that change easier to read.
>
> I was admittedly confused early on about some of the hardcoding. If people
> believe the resulting code is infer
My apologies, wrong term. I meant the front buffer of the X server in
the non-compositing case.
- Bas
On Wed, Oct 21, 2015 at 1:26 PM, Axel Davy wrote:
> On 21/10/2015 13:16, Bas Nieuwenhuizen wrote:
>>
>> On Wed, Oct 21, 2015 at 12:28 PM, Axel Davy wrote:
>>>
>>> +/* This flag indicates that i
Bump. Does anybody have some time to review this patch? I think it's the
only one holding up landing 16x MSAA support.
The following three only have an ack-by but I'm hoping it is reasonable
to just push the branch with that.
i965/meta: Support 16x MSAA in the meta stencil blit
http://patchwork.f
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, Francisco Jerez wrote:
> >> >> Iago Toral Quiroga writes:
> >>
On 21/10/2015 13:36, Bas Nieuwenhuizen wrote:
My apologies, wrong term. I meant the front buffer of the X server in
the non-compositing case.
- Bas
I think only glamor uses mesa for X rendering.
Depending on the DDX, the front buffer will either be created with gbm,
or imported as an EGLIma
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 at 14:18 +0300, Francisco Jerez wrote:
>> >> Iago Toral writes:
>> >>
>> >> > On Tue, 2015-10-20 at 13:22 +0300, Francisco Jerez wrote:
>> >> >>
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Tapani Pälli
> Sent: Wednesday, October 21, 2015 1:25 PM
> To: Marek Olšák
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH 2/4] mesa: Draw Indirect is not allowed
> whe
https://bugs.freedesktop.org/show_bug.cgi?id=92437
Jose Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
These helpers are ran for same case the same loop. Here joined
their operation so the loop is ran just once. Also fixed
out-of-memory condition here.
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/linker.cpp | 112 +---
1 file changed, 37 insertio
You still have to check all enabled vertex attributes. If you don't want to
loop, use bitmasks. See u_vbuf.c as an example of how to avoid loops.
Marek
On Oct 21, 2015 2:33 PM, "Lofstedt, Marta" wrote:
> > -Original Message-
> > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.o
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 at 14:18 +0300, Francisco Jerez wrote:
> >> >> Iago Toral writes:
> >> >
On 9 October 2015 at 23:35, Nanley Chery wrote:
> From: Nanley Chery
>
> The refactoring commit, c6bf1cd, accidentally reverted cd49b97
> and 99b1f47. These changes caused more code to be added to the
> function and removed the existing support for ASTC. This patch
> reverts those modifications.
https://bugs.freedesktop.org/show_bug.cgi?id=92570
Bug ID: 92570
Summary: 10 bit h264 OMX UVD decode outputs NV12
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: n
On 10/20/2015 10:22 AM, Ilia Mirkin wrote:
> On Tue, Oct 20, 2015 at 10:19 AM, Marta Lofstedt
> wrote:
>> From: Marta Lofstedt
>>
>> From OpenGL ES 3.1 specification, section 10.5:
>> "DrawArraysIndirect requires that all data sourced for the
>> command, including the DrawArraysIndirectCommand
>>
https://bugs.freedesktop.org/show_bug.cgi?id=92570
Christian König changed:
What|Removed |Added
Status|NEW |ASSIGNED
Severity|normal
On 10/21/2015 07:32 AM, Lofstedt, Marta wrote:
>> -Original Message-
>> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
>> Behalf Of Tapani Pälli
>> Sent: Wednesday, October 21, 2015 1:25 PM
>> To: Marek Olšák
>> Cc: mesa-dev@lists.freedesktop.org
>> Subject: Re: [Mesa-dev
On 10/20/2015 01:03 PM, Ilia Mirkin wrote:
> On Tue, Oct 20, 2015 at 10:19 AM, Marta Lofstedt
> wrote:
>> From: Marta Lofstedt
>>
>> From OpenGL 4.4 specification, section 10.4 and
>> Open GL Es 3.1 section 10.5:
>> "An INVALID_VALUE error is generated if indirect is not a multiple
>> of the size
On 09/29/2015 07:57 AM, Neil Roberts wrote:
> Previously there was a problem in i965 where if 16x MSAA is used then
> some of the sample positions are exactly on the 0 x or y axis. When
> the MSAA copy blit shader interpolates the texture coordinates at
> these sample positions it was possible that
On 20 October 2015 at 19:58, Connor Abbott wrote:
> On Tue, Oct 20, 2015 at 12:55 PM, Emil Velikov
> wrote:
[snip]
>> +/*
>> + * Shader clock intrinsic with semantics analogous to the clock2x32ARB()
>> + * GLSL intrinsic.
>> + * The latter can be used as code motion barrier, which is currently n
From: Emil Velikov
v2: Add flags and inline comment/description.
v3: None of the input/outputs are variables
v4: Drop clockARB reference, relate code motion barrier comment wrt
intrinsic flag.
v5: Drop the "thus we can eliminate..." comment (Connor)
Signed-off-by: Emil Velikov
Reviewed-by: Conn
From: Emil Velikov
We're about to reuse get_timestamp() for the nir_intrinsic_shader_clock.
In the latter the generalisation does not apply, so move the smear()
where needed. This also makes the function analogous to the vec4 one.
v2: Tweak the comment - The caller -> We (Matt, Connor).
v3: More
From: Emil Velikov
v2:
- Add a few const qualifiers for good measure.
- Drop unneeded retype()s (Matt)
- Convert timestamp to SIMD8/16, as fs_visitor::get_timestamp() returns
SIMD4 (Connor)
v3:
- Remove unneeded temporary + MOV (Connor)
Signed-off-by: Emil Velikov
Reviewed-by: Connor Abbot
This should prevent disparity between features Mesa and LLVM
believe are supported by the CPU.
http://lists.freedesktop.org/archives/mesa-dev/2015-October/thread.html#96990
Tested on a i7-3720QM w/ LLVM 3.3 and 3.6.
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 34 +
I am just a bystander, but I have one suggestion to this patch.
2015-10-21 18:25 GMT+02:00 Jose Fonseca :
> This should prevent disparity between features Mesa and LLVM
> believe are supported by the CPU.
>
> http://lists.freedesktop.org/archives/mesa-dev/2015-October/thread.html#96990
>
> Tested
Thanks for fixing this up.
Reviewed-by: Roland Scheidegger
Am 21.10.2015 um 18:25 schrieb Jose Fonseca:
> This should prevent disparity between features Mesa and LLVM
> believe are supported by the CPU.
>
> http://lists.freedesktop.org/archives/mesa-dev/2015-October/thread.html#96990
>
> Teste
Hello list,
The candidate for the Mesa 11.0.4 is now available. Currently we have:
- 36 queued
- 18 nominated (outstanding)
- and 0 rejected/obsolete patches
The current queue consists on various mesa, glsl and driver fixes, a few
build related patches and an omx bugfix.
Take a look at secti
Gen8+ lifted the register region restriction that an instruction whose
destination spans two registers must have sources that also span two
registers.
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/br
Not a functional difference, but register is loaded with a signed
immediate (V) and added to a signed type (D) producing a signed result
(D).
Also change the type of g0 to allow for compaction.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 4 ++--
src/mesa/drivers/dri/i965/brw_fs_generator
The AND and SHR produce a scalar value that we had been replicating
across $dispatch_width channels. The immediate MOV produces only four
useful channels of data.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/driv
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 9a5992e1..15d0430 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_g
On Wed, Oct 21, 2015 at 7:23 AM, Emil Velikov
wrote:
> On 9 October 2015 at 23:35, Nanley Chery wrote:
> > From: Nanley Chery
> >
> > The refactoring commit, c6bf1cd, accidentally reverted cd49b97
> > and 99b1f47. These changes caused more code to be added to the
> > function and removed the ex
On Wed, Oct 21, 2015 at 1:29 AM, Kenneth Graunke wrote:
> On Monday, October 12, 2015 02:49:03 PM Kenneth Graunke wrote:
>> In the vec4 backend, we have a vec4_instruction::urb_write_flags field.
>> There are many kinds of flags for SIMD4x2 messages.
>>
>> However, there are really only two (per-s
https://bugs.freedesktop.org/show_bug.cgi?id=92221
Nanley Chery changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, Oct 20, 2015 at 02:48:41PM -0700, Matt Turner wrote:
> On Tue, Oct 20, 2015 at 2:41 PM, Ben Widawsky wrote:
> > On Tue, Oct 20, 2015 at 11:56:15AM +0200, Neil Roberts wrote:
> >> In bfdae9149e0 I disabled the opt_sampler_eot optimisation for TG4
> >> message types because I found by experi
On Wed, Oct 21, 2015 at 1:29 AM, Kenneth Graunke wrote:
> On Monday, October 12, 2015 02:49:03 PM Kenneth Graunke wrote:
>> In the vec4 backend, we have a vec4_instruction::urb_write_flags field.
>> There are many kinds of flags for SIMD4x2 messages.
>>
>> However, there are really only two (per-s
Ian Romanick writes:
>> To fix that this patch makes it use interpolateAtOffset in the blit
>> shader whenever 16x MSAA is used and the GL_ARB_gpu_shader5 extension
>> is available. This forces it to interpolate the texture coordinates at
>> the pixel center to avoid these problematic positions.
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 null register to
load the LOD argument.
Essentially the same logic applies to texture. A vertex shader cann
On Wednesday, October 21, 2015 10:05:27 AM Matt Turner wrote:
> Not a functional difference, but register is loaded with a signed
> immediate (V) and added to a signed type (D) producing a signed result
> (D).
>
> Also change the type of g0 to allow for compaction.
> ---
> src/mesa/drivers/dri/i9
v2: Add a uses_streams boolean
---
src/glsl/nir/glsl_to_nir.cpp | 4
src/glsl/nir/nir.h | 12
2 files changed, 16 insertions(+)
diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index c9cdf35..9b50a93 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+
Previously, we were pulling bits from GL data structures in order to set up
the prog_data. However, in this brave new world of NIR, we want to be
pulling it out of the NIR shader whenever possible. This way, we can move
all this setup code into brw_compile_gs without depending on the old GL
stuff
On Wednesday, October 21, 2015 12:44:31 PM Jason Ekstrand wrote:
> v2: Add a uses_streams boolean
>
> ---
> src/glsl/nir/glsl_to_nir.cpp | 4
> src/glsl/nir/nir.h | 12
> 2 files changed, 16 insertions(+)
>
> diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/g
On Wednesday, October 21, 2015 12:45:27 PM Jason Ekstrand wrote:
> Previously, we were pulling bits from GL data structures in order to set up
> the prog_data. However, in this brave new world of NIR, we want to be
> pulling it out of the NIR shader whenever possible. This way, we can move
> all
On Monday, October 19, 2015 02:54:56 PM Emil Velikov wrote:
> Ping on these two trivial patches ?
>
> -Emil
Oh, sorry, I thought I'd sent R-bs for these...
Both are
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
On Wed, Oct 21, 2015 at 12:28 PM, Axel Davy wrote:
> The PIPE_BIND_SHARED flag should be added whenever
> the resource may be shared with another process.
>
> In particular if the resource is imported, or may
> be exported, the flag should be used.
This can't be enforced. EGL_MESA_image_dma_buf_e
https://bugs.freedesktop.org/show_bug.cgi?id=92570
--- Comment #2 from Andy Furniss ---
(In reply to Christian König from comment #1)
> Yeah, that's a known issue/unimplemented feature.
>
> On pre Tonga hardware UVD can actually decode 10 bit h264, but still outputs
> NV12.
So you mean it produ
On 20 October 2015 at 05:08, Matt Turner wrote:
> Otherwise we'd emit a MOV from the null register (which isn't allowed).
>
Would you say it's a good idea to push the check down to the MOV()
implementation ? If not perhaps we should add an assert() to easily
catch cases like these in the future ?
On Wed, Oct 21, 2015 at 1:52 PM, Emil Velikov wrote:
> On 20 October 2015 at 05:08, Matt Turner wrote:
>> Otherwise we'd emit a MOV from the null register (which isn't allowed).
>>
> Would you say it's a good idea to push the check down to the MOV()
> implementation ? If not perhaps we should add
On Oct 21, 2015 10:28 AM, "Jason Ekstrand" wrote:
>
> On Wed, Oct 21, 2015 at 1:29 AM, Kenneth Graunke
wrote:
> > On Monday, October 12, 2015 02:49:03 PM Kenneth Graunke wrote:
> >> In the vec4 backend, we have a vec4_instruction::urb_write_flags field.
> >> There are many kinds of flags for SIMD
On 21 October 2015 at 21:33, Kenneth Graunke wrote:
> On Monday, October 19, 2015 02:54:56 PM Emil Velikov wrote:
>> Ping on these two trivial patches ?
>>
>> -Emil
>
> Oh, sorry, I thought I'd sent R-bs for these...
>
> Both are
> Reviewed-by: Kenneth Graunke
Thanks Ken. I was wondering if peopl
Gen9 adds the ability to write out a stencil value, so we need to expand the
virtual payload by one. Abstracting this now makes that change easier to read.
I was admittedly confused early on about some of the hardcoding. If people
believe the resulting code is inferior, I am not super attached to
On Wed, Oct 21, 2015 at 2:16 PM, Emil Velikov wrote:
> On 21 October 2015 at 21:33, Kenneth Graunke wrote:
>> On Monday, October 19, 2015 02:54:56 PM Emil Velikov wrote:
>>> Ping on these two trivial patches ?
>>>
>>> -Emil
>>
>> Oh, sorry, I thought I'd sent R-bs for these...
>>
>> Both are
>> R
From: Nanley Chery
In OpenGL ES, the COMPRESSED_TEXTURE_FORMATS query returns the set of
supported specific compressed formats. Since ASTC formats fit within
that category, include them in the set and update the
NUM_COMPRESSED_TEXTURE_FORMATS query as well.
This enables GLES2-based ASTC dEQP tes
Before the change "tgsi/scan: use properties for clip/cull distance
writemasks", the tgsi_shader_info::num_written_culldistance field
was a multiple of four, now it's an accurate count. In the svga
driver, we need a minor change to the loop test.
---
src/gallium/drivers/svga/svga_tgsi_vgpu10.c |
> On Oct 20, 2015, at 2:03 PM, Roland Scheidegger wrote:
>
> Certainly looks interesting...
> From a high level point of view, seems quite similar to llvmpipe (both
> tile based, using llvm for jitting shaders, ...). Of course llvmpipe
> isn't well suited for these kind of workloads (the most im
Instead of calling memcpy() 'n' times, we can do it all at once since
the source and dest regions are all contiguous.
---
src/mesa/vbo/vbo_exec_api.c | 16 +++-
src/mesa/vbo/vbo_save_api.c | 15 +++
2 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/src/mesa/v
---
src/mesa/drivers/common/driverfuncs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/common/driverfuncs.c
b/src/mesa/drivers/common/driverfuncs.c
index 3d1fccb..752aaf6 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/dri
---
src/mesa/Makefile.sources | 1 -
src/mesa/tnl/t_rasterpos.c | 478 -
2 files changed, 479 deletions(-)
delete mode 100644 src/mesa/tnl/t_rasterpos.c
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index 34fb446..4bcaa62 100644
We'll remove it from the tnl module next. By lifting this code into core
Mesa we can use it from the gallium state tracker.
---
src/mesa/main/rastpos.c | 441
src/mesa/main/rastpos.h | 3 +
2 files changed, 444 insertions(+)
diff --git a/src/mes
The st_RasterPos() function goes to great pains to implement the
rasterpos transformation. It basically uses gallium's draw module to
execute the vertex shader to draw a point, then capture that point's
attributes.
But glRasterPos isn't typically used with a vertex shader so we can
usually use th
---
src/mesa/main/lines.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/lines.c b/src/mesa/main/lines.c
index c020fb3..93b80af 100644
--- a/src/mesa/main/lines.c
+++ b/src/mesa/main/lines.c
@@ -45,6 +45,10 @@ _mesa_LineWidth( GLfloat width )
if (MESA_
On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote:
> Although write-after-write dependencies have the same latency as
> read-after-write dependencies due to how the register scoreboard works,
> write-after-read dependencies aren't checked by the EU at all, so
> they're purely a constraint on how
Reviewed-by: Jason Ekstrand
Let's add the perf numbers and get this pushed.
On Sat, Oct 3, 2015 at 6:13 PM, Jason Ekstrand wrote:
> On Sat, Oct 3, 2015 at 11:13 AM, Jason Ekstrand wrote:
>> On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote:
>>> Before, we would only do scheduling after regi
Inspired by a bug this summer, I've written a basic assembly validation
pass. The series currently checks only three things:
- that instruction sources are not null (when they shouldn't be);
- that the Gen supports the instruction opcode; and
- that the various accumulator restrictions ar
We were leaving it undefined, even though we were writing a string to
*str.
---
src/util/ralloc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/util/ralloc.c b/src/util/ralloc.c
index e07fce7..bb4cf96 100644
--- a/src/util/ralloc.c
+++ b/src/util/ralloc.c
@@ -499,6 +499,7 @@ ralloc_vaspr
Often annotations are identical between sets of consecutive
instructions. We can perhaps avoid some memory allocations by reusing
the previous annotation.
---
src/mesa/drivers/dri/i965/intel_asm_annotation.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/s
And why did IFF have a destination?
I suspect that once upon a time the disassembler used this information
to know which fields to find the jump targets in. The jump targets have
moved, so the disassembler has to know how to handle these
per-generation anyway.
---
src/mesa/drivers/dri/i965/brw_di
---
src/mesa/drivers/dri/i965/brw_eu_validate.c | 244
1 file changed, 244 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_validate.c
b/src/mesa/drivers/dri/i965/brw_eu_validate.c
index eb57962..3d16f90 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_valida
Will allow annotations to contain error messages (indicating an
instruction violates a rule for instance) that are printed after the
disassembly of the block.
---
src/mesa/drivers/dri/i965/intel_asm_annotation.c | 60
src/mesa/drivers/dri/i965/intel_asm_annotation.h | 7 +
Add some instructions: illegal, movi, sends, sendsc.
Remove some instructions with reused opcodes: msave, mrestore, push,
pop, goto. I did have some gross code for disassembling opcodes
per-generation, but there's very little meaningful overlap so it's
probably not needed.
---
src/mesa/drivers/dr
Initially just checks that sources are non-NULL, which would have
alerted us to the problem fixed by commit 6c846dc5.
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_eu.h | 4 +
src/mesa/drivers/dri/i965/brw_eu_validate.c | 150 +
---
src/mesa/drivers/dri/i965/brw_eu_validate.c | 257
1 file changed, 257 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_validate.c
b/src/mesa/drivers/dri/i965/brw_eu_validate.c
index 85d4c19..eb57962 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_valida
It was being memset to 0 previously.
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 2 +-
src/mesa/drivers/dri/i965/intel_asm_annotation.c | 3 +++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i
1 - 100 of 124 matches
Mail list logo
