If a source operand in a MOV has source modifiers, then we cannot
copy-propagate it from the parent instruction and remove the MOV.
---
I noticed this while debugging some regressions introduced with the fp64
code. Basically, I had code similar to this:
vec4 ssa1 = intrincisc1 (...) (...)
vec2 ss
Mesa 11.0.5 is now available.
With this release we have some driver patches for i965 and nouveau, a couple
of llvm 3.7 related fixes and a some bugfixes in the VA state-tracker.
Additionally we have a few new PCI ids for i965 and radeonsi.
The list of exported OSMesa symbols under Windows has bee
Currently if --without-glut is used on a system that has the GLUT libraries
installed, GLUT is used regardless.
Change the logic so that GLUT is searched for if and only if GLUT is requested.
Signed-off-by: Ross Burton
---
configure.ac | 26 +++---
1 file changed, 15 inserti
Reviewed-by: Samuel Iglesias Gonsálvez
On 05/11/15 12:33, Tapani Pälli wrote:
> From: Iago Toral Quiroga
>
> These have scoping rules that match the ones defined for other things such
> as variables, so we want them in the symbol table.
> ---
> src/glsl/glsl_symbol_table.cpp | 24 +
You can either move the function or add the function forward declaration.
In any case,
Reviewed-by: Samuel Iglesias Gonsálvez
Sam
On 05/11/15 12:33, Tapani Pälli wrote:
> From: Iago Toral Quiroga
>
> We will need this to build later patches
> ---
> src/glsl/ast_to_hir.cpp | 71
> ++
Reviewed-by: Samuel Iglesias Gonsálvez
On 05/11/15 12:33, Tapani Pälli wrote:
> From: Iago Toral Quiroga
>
> Notice that the spec requires that a default precision has been set for every
> type used by a shader that can use a precision qualifier and does not have a
> predefined precision, howev
Reviewed-by: Samuel Iglesias Gonsálvez
On 06/11/15 13:03, 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 p
FS_OPCODE_GET_BUFFER_SIZE is calculated with a resinfo's sampler message.
This patch adjusts the number of registers written by the opcode
following what the PRM spec says about the number of registers written
by the SIMD8 and SIMD16's writeback messages for sampler messages.
Signed-off-by: Samue
Nice!
This fixes 12 GLES 3.1 CTS tests.
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Samuel Iglesias Gonsálvez
> Sent: Wednesday, November 11, 2015 4:07 PM
> To: mesa-dev@lists.freedesktop.org
> Subject: [Mesa-dev] [PATCH] i965/fs/ni
Hi Brian,
On 10 November 2015 at 16:48, Brian Paul wrote:
> On 11/09/2015 09:24 PM, Valera Rozuvan wrote:
>>
>> On Tue, Nov 10, 2015 at 4:13 AM, Brian Paul wrote:
>>>
>>> After running depmod, you probably need to update the initramfs with:
>>> 'sudo update-initramfs -u'
>>>
>>> -Brian
>>
>>
>>
Just two minor nits below.
On 11/10/2015 07:34 PM, Dave Airlie wrote:
From: Dave Airlie
This should fix the getteximage-depth test that currently asserts.
I was hitting problem with virgl as well in this area.
This moves the 1D array handling code to a single place.
Signed-off-by: Dave Air
On Wed, Nov 11, 2015 at 12:20 AM, Iago Toral Quiroga wrote:
> If a source operand in a MOV has source modifiers, then we cannot
> copy-propagate it from the parent instruction and remove the MOV.
> ---
>
> I noticed this while debugging some regressions introduced with the fp64
> code. Basically,
On Wed, Nov 11, 2015 at 7:07 AM, Samuel Iglesias Gonsálvez
wrote:
> FS_OPCODE_GET_BUFFER_SIZE is calculated with a resinfo's sampler message.
>
> This patch adjusts the number of registers written by the opcode
> following what the PRM spec says about the number of registers written
> by the SIMD8
On 11/11/2015 08:44 AM, Emil Velikov wrote:
Hi Brian,
On 10 November 2015 at 16:48, Brian Paul wrote:
On 11/09/2015 09:24 PM, Valera Rozuvan wrote:
On Tue, Nov 10, 2015 at 4:13 AM, Brian Paul wrote:
After running depmod, you probably need to update the initramfs with:
'sudo update-initram
On Wed, Nov 11, 2015 at 11:48 AM, Brian Paul wrote:
>> I think there is a hunk missing about --enable-texture-float for
>> ARB_texture_float (and ultimately GL 3.0).
>
>
> N/A; that option defines the TEXTURE_FLOAT_ENABLED symbol which is only
> tested in _mesa_enable_sw_extensions().
boolean
uti
On Wed, Nov 11, 2015 at 11:58 AM, Ilia Mirkin wrote:
> On Wed, Nov 11, 2015 at 11:48 AM, Brian Paul wrote:
>>> I think there is a hunk missing about --enable-texture-float for
>>> ARB_texture_float (and ultimately GL 3.0).
>>
>>
>> N/A; that option defines the TEXTURE_FLOAT_ENABLED symbol which i
On 11/11/2015 09:58 AM, Ilia Mirkin wrote:
On Wed, Nov 11, 2015 at 11:48 AM, Brian Paul wrote:
I think there is a hunk missing about --enable-texture-float for
ARB_texture_float (and ultimately GL 3.0).
N/A; that option defines the TEXTURE_FLOAT_ENABLED symbol which is only
tested in _mesa_e
On 11 November 2015 at 16:48, Brian Paul wrote:
> On 11/11/2015 08:44 AM, Emil Velikov wrote:
>>
>> I have seen similar type of documents in the past, most of which going
>> out of date very quickly due to distribution changes and/or others.
>> Wondering how you'll feel about "check your distro a
On 11/09/2015 09:24 PM, Valera Rozuvan wrote:
On Tue, Nov 10, 2015 at 4:13 AM, Brian Paul wrote:
After running depmod, you probably need to update the initramfs with: 'sudo
update-initramfs -u'
-Brian
Hi Brian. First of all, thank you for your reply. I have tried your
suggestion on my worki
On 11/11/2015 10:44 AM, Emil Velikov wrote:
On 11 November 2015 at 16:48, Brian Paul wrote:
On 11/11/2015 08:44 AM, Emil Velikov wrote:
I have seen similar type of documents in the past, most of which going
out of date very quickly due to distribution changes and/or others.
Wondering how yo
On 11/11/2015 07:07 PM, Brian Paul wrote:
> On 11/11/2015 10:44 AM, Emil Velikov wrote:
>> On 11 November 2015 at 16:48, Brian Paul wrote:
>>> On 11/11/2015 08:44 AM, Emil Velikov wrote:
>>
I have seen similar type of documents in the past, most of which going
out of date very quick
On 11 November 2015 at 18:25, Thomas Hellstrom wrote:
> On 11/11/2015 07:07 PM, Brian Paul wrote:
>> On 11/11/2015 10:44 AM, Emil Velikov wrote:
>>> On 11 November 2015 at 16:48, Brian Paul wrote:
On 11/11/2015 08:44 AM, Emil Velikov wrote:
>>>
>
> I have seen similar type of documen
https://bugs.freedesktop.org/show_bug.cgi?id=92860
Ilia Mirkin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 11/11/2015 11:38 AM, Emil Velikov wrote:
On 11 November 2015 at 18:25, Thomas Hellstrom wrote:
On 11/11/2015 07:07 PM, Brian Paul wrote:
On 11/11/2015 10:44 AM, Emil Velikov wrote:
On 11 November 2015 at 16:48, Brian Paul wrote:
On 11/11/2015 08:44 AM, Emil Velikov wrote:
I have seen
We need to use per-slot offsets when there's non-uniform indexing,
as each SIMD channel could have a different index. We want to use
them for any non-constant index (even if uniform), as it lives in
the message header instead of the descriptor, allowing us to set
offsets in GRFs rather than immedi
The geometry and tessellation control shader stages both read from
multiple URB entries (one per vertex). The thread payload contains
several URB handles which reference these separate memory segments.
In GLSL, these inputs are represented as per-vertex arrays; the
outermost array index selects w
This allows arbitrary non-constant indices on GS input arrays,
both for the vertex index, and any array offsets beyond that.
All indirects are handled via the pull model. We could potentially
handle indirect addressing of pushed data as well, but it would add
additional code complexity, and we us
On Monday, November 09, 2015 12:05:34 PM Matt Turner wrote:
> On Tue, Nov 3, 2015 at 11:53 PM, Kenneth Graunke
> wrote:
> > On Wednesday, October 21, 2015 03:58:17 PM Matt Turner wrote:
> >> ---
> >> src/mesa/drivers/dri/i965/brw_eu_validate.c | 244
> >>
> >> 1 fil
On Mon, Nov 9, 2015 at 8:39 AM, Rob Clark wrote:
> On Mon, Nov 9, 2015 at 8:30 AM, Emil Velikov wrote:
>> On 30 October 2015 at 17:57, Emil Velikov wrote:
>>> On 19 October 2015 at 18:41, Emil Velikov wrote:
On 19 October 2015 at 17:07, Brian Paul wrote:
>>>
>
> I'm not too famili
On Monday, November 02, 2015 04:29:22 PM Matt Turner wrote:
> 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
On Monday, November 02, 2015 04:29:25 PM Matt Turner wrote:
> 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, cal
On Monday, November 02, 2015 04:29:25 PM Matt Turner wrote:
> 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, cal
On Wed, Nov 11, 2015 at 12:46 PM, Kenneth Graunke wrote:
> On Monday, November 02, 2015 04:29:22 PM Matt Turner wrote:
>> 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'
On Wed, Nov 11, 2015 at 1:02 PM, Kenneth Graunke wrote:
> On Monday, November 02, 2015 04:29:25 PM Matt Turner wrote:
>> 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 do
On 11/11/2015 08:51 PM, Brian Paul wrote:
> On 11/11/2015 11:38 AM, Emil Velikov wrote:
>> On 11 November 2015 at 18:25, Thomas Hellstrom
>> wrote:
>>> On 11/11/2015 07:07 PM, Brian Paul wrote:
On 11/11/2015 10:44 AM, Emil Velikov wrote:
> On 11 November 2015 at 16:48, Brian Paul wrote:
On 11 November 2015 at 19:51, Brian Paul wrote:
> On 11/11/2015 11:38 AM, Emil Velikov wrote:
>>
>> On 11 November 2015 at 18:25, Thomas Hellstrom
>> wrote:
>>>
>>> On 11/11/2015 07:07 PM, Brian Paul wrote:
On 11/11/2015 10:44 AM, Emil Velikov wrote:
>
> On 11 November 2015 at 1
Do I need to do something to else to get this committed? Not 100% on process.
--
Jimmy
On Wed, Nov 4, 2015 at 2:32 AM, Samuel Pitoiset
wrote:
> Reviewed-by: Samuel Pitoiset
>
>
>
> On 11/04/2015 06:24 AM, Jimmy Berry wrote:
>>
>> ---
>> docs/envvars.html | 2 ++
>> 1 file changed, 2 inserti
For documentation purposes, we discussed things in IRC and should be
reflected in v6.
--
Jimmy
On Sat, Nov 7, 2015 at 10:49 PM, Ilia Mirkin wrote:
> On Sat, Nov 7, 2015 at 11:42 PM, Jimmy Berry wrote:
>> - env GALLIUM_HUD_VISIBLE: control default visibility
>> - env GALLIUM_HUD_SIGNAL_TOGGLE:
These patches represent the remaining patches for enabling fast color clears on
GEN9+. Mostly they address feedback from Chad. There is one spot where I am
waiting for him to tell me what he wants for a comment [i965/meta/gen9:
Individually fast clear color attachments]. Hopefully we can get that a
Some of the information originally in this commit message is now in the patch
before this.
SKL adds compressible render targets and as a result mutates some of the
programming for fast clears and resolves. There is a new internal surface type
called the CCS. The old AUX_MCS bit becomes AUX_CCS_D.
This reverts commit dcd59a9e322edeea74187bcad65a8e56c0bfaaa2.
Reviewed-by: Neil Roberts
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 8
1 file changed, 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
inde
Background: Prior to Skylake and since Ivybridge Intel hardware has had the
ability to use a MCS (Multisample Control Surface) as auxiliary data in
"compression" operations on the surface. This reduces memory bandwidth. This
hardware was either used for MSAA compression, and fast clear operations.
Patch was originally called:
i965/skl: Enable fast color clears on SKL
Skylake introduces some differences in the way that fast clears are programmed
and in the restrictions for using fast clears. Since some of these are
non-obvious, and fast clears are currently disabled globally, we can enable t
This reverts commit 8a0c85b25853decb4a110b6d36d79c4f095d437b.
It's not a strict revert because I don't want to bring back the gen < 9 check at
this point in time.
Reviewed-by: Neil Roberts
---
src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 5 -
1 file changed, 5 deletions(-)
diff --git
SKL supports the ability to do fast clears and resolves of 32b RGBA as both
integer and floats. This patch only enables float color clears because we
haven't yet enabled integer color clears, (HW support for that was added in
BDW).
Two formats are explicitly disabled because they fail piglit tests
The impetus for this patch comes from a seemingly benign statement within the
spec (quoted within the patch). For me, this patch was at some point critical
for getting stable piglit results (though this did not seem to be the case on a
branch Chad was working on).
It is very important for clearing
On Fri 30 Oct 2015, Nanley Chery wrote:
> From: Nanley Chery
>
> Simplify future updates to the extension struct array by removing
> the sentinel.
>
> Signed-off-by: Nanley Chery
Patch 1 is
Reviewed-by: Chad Versace
Since your series is long and risks suffering from rebase conflicts,
I sugge
This subject used to say Add lossless compression to surface format TO table
somehow, "to" got dropped. It's fixed locally.
On Wed, Nov 11, 2015 at 02:06:16PM -0800, Ben Widawsky wrote:
> Background: Prior to Skylake and since Ivybridge Intel hardware has had the
> ability to use a MCS (Multisamp
On Wed, Nov 11, 2015 at 2:07 PM, Chad Versace
wrote:
> On Fri 30 Oct 2015, Nanley Chery wrote:
> > From: Nanley Chery
> >
> > Simplify future updates to the extension struct array by removing
> > the sentinel.
> >
> > Signed-off-by: Nanley Chery
>
> Patch 1 is
> Reviewed-by: Chad Versace
>
>
T
On Wed, Nov 11, 2015 at 02:10:57PM -0800, Ben Widawsky wrote:
> This subject used to say Add lossless compression to surface format TO table
>
> somehow, "to" got dropped. It's fixed locally.
>
Ignore this, subject looks fine to me and I'm an idiot.
[snip]
_
On Fri 30 Oct 2015, Nanley Chery wrote:
> From: Nanley Chery
>
> Now that we're using macros, remove the redundant text from each entry.
>
> Remove comments between the entries to make editing easier and separate
> the sections with blank lines. Structure the EXT macros in a way that
> helps rev
On Fri 30 Oct 2015, Nanley Chery wrote:
> From: Nanley Chery
>
> With this infrastructure set in place, we can now reuse the entries to
> generate useful code.
>
> v2. Add the new file into Makefile.sources (Emil)
>
> Signed-off-by: Nanley Chery
> ---
> src/mesa/Makefile.sources| 1
On Fri 30 Oct 2015, Nanley Chery wrote:
> From: Nanley Chery
>
> Enable limiting advertised extension support by context version with
> finer granularity.
>
> v2. Use uint*t type for version and note the expected values (Emil)
> Use an 8-bit wide datatype.
> Reformat macro for better rea
From: Dave Airlie
This fixes the corruption on rendering that we are seeing in
certain geometry shaders.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 4
src/gallium/drivers/r600/evergreend.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/src/gal
On Fri 30 Oct 2015, Nanley Chery wrote:
> From: Nanley Chery
>
> Replace open-coded checks for extension support with
> _mesa_extension_supported().
>
> Signed-off-by: Nanley Chery
> ---
> src/mesa/main/extensions.c | 54
>
> src/mesa/main/extens
On Wed, Nov 11, 2015 at 2:06 PM, Ben Widawsky
wrote:
> Patch was originally called:
> i965/skl: Enable fast color clears on SKL
>
> Skylake introduces some differences in the way that fast clears are programmed
> and in the restrictions for using fast clears. Since some of these are
> non-obvious,
On Fri 30 Oct 2015, Nanley Chery wrote:
> From: Nanley Chery
>
> The api_set field has no users outside of _mesa_extension_supported().
> Remove it and allow the version field to take its place.
>
> The brunt of the transformation was performed with the following vim commands:
> s/\(GL [^,]\+\),
On Fri 30 Oct 2015, Nanley Chery wrote:
> From: Nanley Chery
>
> Generate functions which determine if an extension is supported in the
> current context. Initially, enums were going to be explicitly used with
> _mesa_extension_supported(). The idea to embed the function and enums
> into generate
On Wed, Nov 11, 2015 at 5:42 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This fixes the corruption on rendering that we are seeing in
> certain geometry shaders.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/evergreen_state.c | 4
> src/gal
On Fri 30 Oct 2015, Nanley Chery wrote:
> From: Nanley Chery
>
> Generate functions which determine if an extension is supported in the
> current context. Initially, enums were going to be explicitly used with
> _mesa_extension_supported(). The idea to embed the function and enums
> into generate
On Fri 30 Oct 2015, Nanley Chery wrote:
> From: Nanley Chery
>
> Rename the following types and variables:
> * struct extension -> struct mesa_extension,
> like the mesa_format type.
> * extension_table -> _mesa_extension_table,
> like the _mesa_extension_override_{enables,disables} structs.
On Wed, 11 Nov 2015 23:42:18 +0100, Dave Airlie wrote:
From: Dave Airlie
This fixes the corruption on rendering that we are seeing in
certain geometry shaders.
Specifically, this fixes
https://bugs.freedesktop.org/show_bug.cgi?id=91780 and probably others
Signed-off-by: Dave Airlie
-
On Fri 30 Oct 2015, Nanley Chery wrote:
> From: Nanley Chery
>
> Make API context and version checks done by the helper functions pass
> unconditionally while meta is in progress. This transparently makes
> extension checks solely dependent on struct gl_extensions while in meta.
>
> v2. Use 8-bi
On Wednesday, November 11, 2015 01:07:24 PM Matt Turner wrote:
> On Wed, Nov 11, 2015 at 12:46 PM, Kenneth Graunke
> wrote:
> > On Monday, November 02, 2015 04:29:22 PM Matt Turner wrote:
> >> The test (file == BAD_FILE) works on registers for which the constructor
> >> has not run because BAD_FI
On Monday, November 02, 2015 04:29:27 PM Matt Turner wrote:
> 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
On Wed, Nov 11, 2015 at 3:05 PM, Kenneth Graunke wrote:
> On Wednesday, November 11, 2015 01:07:24 PM Matt Turner wrote:
>> On Wed, Nov 11, 2015 at 12:46 PM, Kenneth Graunke
>> wrote:
>> > On Monday, November 02, 2015 04:29:22 PM Matt Turner wrote:
>> >> The test (file == BAD_FILE) works on regi
On Monday, November 02, 2015 04:29:10 PM Matt Turner wrote:
> 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,
On Wednesday, November 11, 2015 03:12:11 PM Matt Turner wrote:
> On Wed, Nov 11, 2015 at 3:05 PM, Kenneth Graunke
> wrote:
> > On Wednesday, November 11, 2015 01:07:24 PM Matt Turner wrote:
> >> On Wed, Nov 11, 2015 at 12:46 PM, Kenneth Graunke
> >> wrote:
> >> > On Monday, November 02, 2015 04
On Wed, Nov 11, 2015 at 4:08 PM, Kenneth Graunke wrote:
> Actually, your earlier statement:
> "if file == BAD_FILE, no other fields mean anything."
> suggests that we should change fs_reg() to simply set BAD_FILE, and
> not bother initializing the other fields. That would eliminate one
> of the r
On Friday, November 06, 2015 05:19:41 PM Matt Turner wrote:
> 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 | 71
>
From: Rob Clark
This will simplify things somewhat in clone.
Signed-off-by: Rob Clark
Reviewed-by: Jason Ekstrand
---
src/glsl/nir/glsl_to_nir.cpp | 5 +
src/glsl/nir/nir.h | 5 +
2 files changed, 10 insertions(+)
diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/gls
On older hardware (Iron Lake and below), we can't support texture rectangle
natively. Sandy Bridge through Haswell can support it but don't support
the GL_CLAMP wrap mode natively. It isn't until Broadwell that GL_CLAMP is
supported together with GL_TEXTURE_RECTANGLE in hardware. In the cases
wh
From: Rob Clark
No users.
Signed-off-by: Rob Clark
Reviewed-by: Jason Ekstrand
---
src/glsl/nir/glsl_to_nir.cpp | 9 -
src/glsl/nir/nir.h | 13 -
2 files changed, 22 deletions(-)
diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index b10
From: Kenneth Graunke
OPT() is the normal macro for passes that return booleans, while OPT_V()
is a variant that works for passes that don't properly report progress.
(Such passes should be fixed to return a boolean, eventually.)
These macros take care of calling nir_validate_shader() and settin
From: Kenneth Graunke
Failing to call nir_metadata_preserve() can have nasty consequences:
some pass breaks dominance information, but leaves it marked as valid,
causing some subsequent pass to go haywire and probably crash.
This pass adds a simple validation mechanism to ensure passes handle
th
At the moment, brw_create_nir just calls the three stages in sequence so
there's not much difference. Soon, however, we will want to start doing
variants in NIR at which point the postprocessing step will have to move
from shader create time to codegen time.
---
src/mesa/drivers/dri/i965/brw_nir.
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 974219f..dad541b 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_gen
Previously, we had a rescale_texcoords helper in the FS backend for
handling rescaling of texture coordinates. Now that we can do variants in
NIR, we can use nir_lower_tex to do the rescaling for us. This allows us
to delete the i965-specific code and gives us proper TEXTURE_RECTANGLE and
GL_CLAM
---
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_visitor.cpp | 6 +-
4 files changed, 18 insertions(+), 5 deleti
---
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 100644
--- a/src/glsl/nir/nir_lower_tex.c
+++ b/src/glsl/nir/nir_lower_tex.c
@@ -134,6 +134,7 @@ get_texture_size(nir_builder *b,
---
src/glsl/nir/nir.h | 2 +-
src/glsl/nir/nir_lower_tex.c | 19 +++
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index 41125b1..2299ece 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -1981,7 +1981,
On Wed, Nov 11, 2015 at 5:23 PM, 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 don't support
> the GL_CLAMP wrap mode natively. It isn't until Broadwell that GL_CLAMP is
> supported
On Tue, Nov 3, 2015 at 10:49 AM, Emil Velikov wrote:
> On 3 November 2015 at 18:10, Matt Turner wrote:
>> On Tue, Nov 3, 2015 at 8:07 AM, Emil Velikov
>> wrote:
>>> On 3 November 2015 at 00:29, Matt Turner wrote:
>>>
index 6eeafd5..3d2b051 100644
--- a/src/mesa/drivers/dri/i965/brw_f
On Thu, Nov 5, 2015 at 9:44 PM, Kristian Høgsberg Kristensen
wrote:
> diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
> index e4e4a3f..5584470 100644
> --- a/src/glsl/ast_function.cpp
> +++ b/src/glsl/ast_function.cpp
> @@ -376,12 +368,8 @@ fix_parameter(void *mem_ctx, ir_rvalue
On Nov 11, 2015 9:10 PM, "Matt Turner" wrote:
>
> On Thu, Nov 5, 2015 at 9:44 PM, Kristian Høgsberg Kristensen
> wrote:
> > diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
> > index e4e4a3f..5584470 100644
> > --- a/src/glsl/ast_function.cpp
> > +++ b/src/glsl/ast_function.cpp
On Wed, Nov 11, 2015 at 8:47 PM, Ilia Mirkin wrote:
> On Nov 11, 2015 9:10 PM, "Matt Turner" wrote:
>>
>> On Thu, Nov 5, 2015 at 9:44 PM, Kristian Høgsberg Kristensen
>> wrote:
>> > diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
>> > index e4e4a3f..5584470 100644
>> > --- a/s
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.
Also not calling the binding validation function will make things
much simpler when adding compile time constant support as we
wont need to resolve the binding
Hi;
Here's one additional change (can be considered as patch 5.1/7) that
was missing from the precision patches.
Tapani Pälli (1):
glsl: set precision qualifier on interface block members
src/glsl/ast_to_hir.cpp | 1 +
1 file changed, 1 insertion(+)
--
2.4.3
___
Signed-off-by: Tapani Pälli
---
src/glsl/ast_to_hir.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 2fd9c5b..51ea183 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -6161,6 +6161,7 @@ ast_process_structure_or_in
Reviewed-by: Samuel Iglesias Gonsálvez
Are you planning to merge it to patch 5/7 or keep it standalone?
Sam
On 12/11/15 07:57, Tapani Pälli wrote:
> Signed-off-by: Tapani Pälli
> ---
> src/glsl/ast_to_hir.cpp | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/glsl/ast_to_hir.cpp b/
On 11/12/2015 09:11 AM, Samuel Iglesias Gonsálvez wrote:
Reviewed-by: Samuel Iglesias Gonsálvez
Are you planning to merge it to patch 5/7 or keep it standalone?
Yeah, I'll merge this to patch 5/7, otherwise there are some failures
between patches when bisecting.
Sam
On 12/11/15 07:57,
On 12/11/15 08:13, Tapani Pälli wrote:
>
>
> On 11/12/2015 09:11 AM, Samuel Iglesias Gonsálvez wrote:
>> Reviewed-by: Samuel Iglesias Gonsálvez
>>
>> Are you planning to merge it to patch 5/7 or keep it standalone?
>
> Yeah, I'll merge this to patch 5/7, otherwise there are some failures
> be
If a source operand in a MOV has source modifiers, then we cannot
copy-propagate it from the parent instruction and remove the MOV.
v2: remove the check for source source modifiers from is_move() (Jason)
---
src/glsl/nir/nir_opt_copy_propagate.c | 17 ++---
1 file changed, 10 insertio
93 matches
Mail list logo
