Using the GLSL spec's definition (or something with equivalent
precision) is also required for ARB_shader_precision, which we'll have
really soon, so +1 from me too.
On Fri, Jan 16, 2015 at 8:01 PM, Iago Toral ito...@igalia.com wrote:
Thanks Roland and everyone else for the input. Based on the
https://bugs.freedesktop.org/show_bug.cgi?id=88488
Bug ID: 88488
Summary: osmesa build with msys2 on Windows7 64 fails
Product: Mesa
Version: 10.4
Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: NEW
Commit 8ec6534 changed texture upload path and the way how texture
format is being checked, this commit adds support for GL_RGB with
GL_UNSIGNED_INT_2_10_10_10_REV as specified by the extension
EXT_texture_type_2_10_10_10_REV specification.
This fixes regression in ES3 conformance test
Looks good to me.
Jason: does this get your R-b?
Iago
On Fri, 2015-01-16 at 12:48 +0200, Tapani Pälli wrote:
Commit 8ec6534 changed texture upload path and the way how texture
format is being checked, this commit adds support for GL_RGB with
GL_UNSIGNED_INT_2_10_10_10_REV as specified by the
brw_fs_nir.cpp creates almost all of its registers via:
fs_reg reg = fs_reg(GRF, virtual_grf_alloc(num_components));
When we add SIMD16 support, we'll need to set reg-width = 16 and
double the VGRF size...on pretty much every VGRF it allocates.
This patch replaces that pattern with a new
Previously, we generated this for FB writes in SIMD16 mode:
load_payload(16) vgrf5@8+0.0:F, vgrf1:F, vgrf2:F, vgrf3:F, vgrf4:F
fb_write(8) (null):UD, vgrf5@8+0.0:F 1sthalf
The LOAD_PAYLOAD's destination had its register width set to 8, and the
FB_WRITE had its execution size set to 8. This
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 5 +--
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 73 +---
2 files changed, 50 insertions(+), 28 deletions(-)
That was easy
diff --git
In order to support calling lower_load_payload() inside a condition,
this patch makes OPT() a statement expression:
https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
We recently did the equivalent change in the vec4 backend (commit
9b8bd67768769b685c25e1276e053505aede5f93).
Signed-off-by:
Reviewed-by: Tapani Pälli tapani.pa...@intel.com
On 01/07/2015 11:08 AM, Iago Toral Quiroga wrote:
Rendering with a GS and then using transform feedback with a program that does
not have a GS can crash in gen6. The reason for this is that
brw_begin_transform_feedback checks brw-geometry_program
https://bugs.freedesktop.org/show_bug.cgi?id=88488
José Fonseca jfons...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Just general suggestions.
If you don't want to map the buffer and synchronize with the CPU, you
can use the WRITE_DATA packet to write the data.
I wouldn't use buffer_unmap for buffers that can be mapped/unmapped
often. Even though buffer_unmap is a no-op right now, it might change
in the
The target attribute allows for function or file specific compiler target
specification. This will be useful when compiling with LTO enabled.
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
configure.ac| 2 ++
m4/ax_gcc_func_attribute.m4 | 9 +
2 files changed, 11
The GCC specific target function attribute or pragma can be used to enable
architecture depended optimisation options (e.g. SSE) directly in source files
instead of specifing them on the compiler command line. This is useful when
linking files with different compiler options which happens when
If the compiler supports the target attribute (or pragma), we can specify the
target architecture directly in the source. In this case we don't need to
parse the compiler flag via the command line. This is usefull when compiling
with LTO enabled, where all files will be recompiled during the link
Ah that's neat, thanks.
If I compile the existing patch with gcc -O3 it seems to optimize the
division into shifts anyway like this (for 8-bit to 5-bit):
0: 89 f8 mov%edi,%eax
2: ba 81 80 80 80 mov$0x80808081,%edx
7: c1 e0 05shl
Interesting. I wonder if I leave the division by 255 LLVM will do
similar magic. The risk in llvmpipe is most of these operations are
with i8x16 and i16x8 vector types which don't even have division in x86.
Jose
On 16/01/15 13:40, Neil Roberts wrote:
Ah that's neat, thanks.
If I compile
On 15/01/15 19:46, Carl Worth wrote:
On Thu, Jan 08 2015, Jose Fonseca wrote:
Note that Windows build is only supported with SCons. Never with
autobuild.
OK. That's good for me to learn. I've requested that the folks doing our
automated build testing here will also start testing scons
On Thu, 2015-01-15 at 20:49 +0100, Tobias Klausmann wrote:
On 15.01.2015 19:35, Jan Vesely wrote:
On Thu, 2015-01-15 at 19:26 +0100, Tobias Klausmann wrote:
I: Program returns random data in a function
E: Mesa no-return-in-nonvoid-function
../../src/mesa/main/format_utils.c:180
E: Mesa
On Fri, Jan 16, 2015 at 11:44:36AM +0900, Michel Dänzer wrote:
On 16.01.2015 09:48, Tom Stellard wrote:
- Use context global scratch buffers, one for each shader type.
AFAICT the code actually uses a single buffer for all shader types. As
we discussed before, that needs to be fixed.
I
On Wed, Jan 14, 2015 at 11:06:50AM +0900, Michel Dänzer wrote:
On 14.01.2015 04:07, Tom Stellard wrote:
On Tue, Jan 13, 2015 at 06:47:00PM +0900, Michel Dänzer wrote:
On 07.01.2015 10:10, Michel Dänzer wrote:
On 07.01.2015 06:33, Tom Stellard wrote:
On Wed, Dec 24, 2014 at 12:48:31PM
https://bugs.freedesktop.org/show_bug.cgi?id=88480
Brian Paul bri...@vmware.com changed:
What|Removed |Added
Component|Other |New Accounts
On Jan 16, 2015 5:30 AM, Kenneth Graunke kenn...@whitecape.org wrote:
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 5 +--
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 73
+---
2 files changed, 50
Thanks for picking this up! I don't know that much about statement
expressions, so I'm giving this one an ACK only. 2 and 3 are Reviewed-by:
Jason Ekstrand jason.ekstr...@intel.com. I left some comments on 4 but
nothing functional.
On Jan 16, 2015 5:29 AM, Kenneth Graunke kenn...@whitecape.org
Doesn't this need to be added to the mesa/st switch's in st_format.c?
On Fri, Jan 16, 2015 at 6:09 AM, Iago Toral ito...@igalia.com wrote:
Looks good to me.
Jason: does this get your R-b?
Iago
On Fri, 2015-01-16 at 12:48 +0200, Tapani Pälli wrote:
Commit 8ec6534 changed texture upload path
Actually nevermind. There's no matching PIPE_FORMAT for that, so it'll
have to get added.
On Fri, Jan 16, 2015 at 10:44 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
Doesn't this need to be added to the mesa/st switch's in st_format.c?
On Fri, Jan 16, 2015 at 6:09 AM, Iago Toral
Looks good to me. My initial reaction was that we could simplify it but
you're right about the rounding. This one gets my r-b too.
On Jan 15, 2015 10:52 AM, Neil Roberts n...@linux.intel.com wrote:
Jason Ekstrand ja...@jlekstrand.net writes:
This looks fine to me. We should probably also
The first three are
Reviewed-by: Matt Turner matts...@gmail.com
Looks like Jason's got some comments on #4.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
v2:
- Only emit write SPI_TMPRING_SIZE once per packet.
- Use context global scratch buffer.
v3:
- Patch shaders using WRITE_DATA packet instead of map/unmap.
- Emit ICACHE_FLUSH, CS_PARTIAL_FLUSH, PS_PARTIAL_FLUSH, and
VS_PARTIAL_FLUSH when patching shaders.
---
On Thursday, January 15, 2015 07:12:20 AM Jason Ekstrand wrote:
On Jan 15, 2015 12:27 AM, Eero Tamminen eero.t.tammi...@intel.com wrote:
Hi,
On 01/15/2015 03:04 AM, Matt Turner wrote:
On Wed, Jan 14, 2015 at 1:52 PM, Matt Turner matts...@gmail.com wrote:
On Wed, Jan 14, 2015 at
Before, we used a system where a file, nir_opcodes.h, defined some macros that
were included to generate the enum values and the nir_op_infos structure. This
worked pretty well, but for development the error messages were never very
useful, Python tools couldn't understand the opcode list, and it
Add a required field to the Opcode class, const_expr, that contains an
expression or statement that computes the result of the opcode given known
constant inputs. Then take those const_expr's and expand them into a function
that takes an opcode and an array of constant inputs and spits out the
Hi,
This is a series I had floating around a while. The idea is to have all the
opcode stuff, including constant folding, derived from a single Python file.
I've cleaned it up a little by using {}-style Python formatting instead of the
pile of text-replacement and regular expressions we had
Signed-off-by: Connor Abbott cwabbo...@gmail.com
---
src/glsl/nir/nir_opt_constant_folding.c | 179
1 file changed, 21 insertions(+), 158 deletions(-)
diff --git a/src/glsl/nir/nir_opt_constant_folding.c
b/src/glsl/nir/nir_opt_constant_folding.c
index
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
Signed-off-by: Connor Abbott cwabbo...@gmail.com
---
src/glsl/nir/nir_lower_vars_to_ssa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/nir/nir_lower_vars_to_ssa.c
b/src/glsl/nir/nir_lower_vars_to_ssa.c
index
Signed-off-by: Connor Abbott cwabbo...@gmail.com
---
src/glsl/nir/.gitignore | 1 +
1 file changed, 1 insertion(+)
create mode 100644 src/glsl/nir/.gitignore
diff --git a/src/glsl/nir/.gitignore b/src/glsl/nir/.gitignore
new file mode 100644
index 000..6d954fe
--- /dev/null
+++
Oh, and I forgot... the series is also available at
https://github.com/cwabbott0/mesa nir-opcodes-cleanup
On Fri, Jan 16, 2015 at 4:46 PM, Connor Abbott cwabbo...@gmail.com wrote:
Hi,
This is a series I had floating around a while. The idea is to have all the
opcode stuff, including constant
On Fri, Jan 16 2015, Jose Fonseca wrote:
Oh, just saying that in fact I got it to build that module on Windows.
Thanks. That's good to know. I appreciate that testing.
I've just pushed this series along with your fixes.
And for the sake of everyone that contributed to the discussion on the
brw_fs_nir.cpp creates almost all of its registers via:
fs_reg reg = fs_reg(GRF, virtual_grf_alloc(num_components));
When we add SIMD16 support, we'll need to set reg-width = 16 and
double the VGRF size...on pretty much every VGRF it allocates.
This patch replaces that pattern with a new
offset() properly handles reg_width, so it'll work for SIMD16.
While we're in the area, simplify a few cases, and use retype() to cut a
few more lines of code.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 91 +++-
With the previous commits in place, it just works.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
I dislike how fs_reg has a constructor that knows about fs_visitor.
Apart from that, it stands alone, with no need to interact with the
rest of the compiler. Which is sensible - a class that represents
a register should do just that. Allocating virtual register numbers
should be left up to the
On Jan 16, 2015 4:19 PM, Kenneth Graunke kenn...@whitecape.org wrote:
I dislike how fs_reg has a constructor that knows about fs_visitor.
Apart from that, it stands alone, with no need to interact with the
rest of the compiler. Which is sensible - a class that represents
a register should do
Two stupid questions:
1) Did you gun piglit with INTEL_USE_NIR and did everything check out OK?
2) Did you grep fs_nir.cpp for virtual_grf_alloc and reg_offset to make
sure you didn't miss anything?
If the answer to both of the above is yes, this series is
Reviewed-by: Jason Ekstrand
On Friday, January 16, 2015 02:43:12 PM Jason Ekstrand wrote:
Two stupid questions:
1) Did you gun piglit with INTEL_USE_NIR and did everything check out OK?
Yes, I did before/after Piglit runs on Haswell GT3e with and without
INTEL_USE_NIR (to make sure both paths keep working).
2) Did you
https://bugs.freedesktop.org/show_bug.cgi?id=88519
Bug ID: 88519
Summary: sha1.c:210:22: error: 'grcy_md_hd_t' undeclared (first
use in this function)
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS:
Hi Conner, I have a couple of things you should change, and a suggestion
for you below, hopefully it all makes sense.
On Friday, January 16, 2015 04:46:07 PM Connor Abbott wrote:
Before, we used a system where a file, nir_opcodes.h, defined some macros that
were included to generate the enum
https://bugs.freedesktop.org/show_bug.cgi?id=88519
Carl Worth cwo...@cworth.org changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1
https://bugs.freedesktop.org/show_bug.cgi?id=88519
Carl Worth cwo...@cworth.org changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |cwo...@cworth.org
https://bugs.freedesktop.org/show_bug.cgi?id=88478
Vinson Lee v...@freedesktop.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=88523
Bug ID: 88523
Summary: sha1.c:37: error: 'SHA1_CTX' undeclared (first use in
this function)
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: OpenBSD
https://bugs.freedesktop.org/show_bug.cgi?id=88523
Carl Worth cwo...@cworth.org changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1
https://bugs.freedesktop.org/show_bug.cgi?id=88523
--- Comment #2 from Jonathan Gray j...@openbsd.org ---
SHA1_CTX is defined in sha1.h
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/include/sha1.h?rev=HEADcontent-type=text/plain
The xserver code this was based off builds fine so there
On Friday, January 16, 2015 05:53:09 PM Ian Romanick wrote:
On 01/16/2015 08:15 AM, Matt Turner wrote:
From: Ian Romanick ian.d.roman...@intel.com
Some shaders end up with code that looks something like:
if (some_condition)
result = 1.0;
else
result =
https://bugs.freedesktop.org/show_bug.cgi?id=88523
--- Comment #3 from Jonathan Gray j...@openbsd.org ---
If I rename util/sha1.h to util/xsha1.h matching the xserver name the correct
sha1.h is picked up. Otherwise sha1.h picks up util/sha1.h
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=88519
Matt Turner matts...@gmail.com changed:
What|Removed |Added
QA Contact|
Hi Dylan,
On Fri, Jan 16, 2015 at 7:01 PM, Dylan Baker baker.dyla...@gmail.com wrote:
Hi Conner, I have a couple of things you should change, and a suggestion
for you below, hopefully it all makes sense.
On Friday, January 16, 2015 04:46:07 PM Connor Abbott wrote:
Before, we used a system
On Friday, January 16, 2015 10:18:43 PM Connor Abbott wrote:
Hi Dylan,
On Fri, Jan 16, 2015 at 7:01 PM, Dylan Baker baker.dyla...@gmail.com wrote:
Hi Conner, I have a couple of things you should change, and a suggestion
for you below, hopefully it all makes sense.
On Friday, January
The vec4 side is similarly tangled, except there are 3 constructors
like this spread across the src_reg and dst_reg classes.
Reviewed-by: Chris Forbes chr...@ijw.co.nz
On Sat, Jan 17, 2015 at 11:19 AM, Kenneth Graunke kenn...@whitecape.org wrote:
I dislike how fs_reg has a constructor that
On Fri, Jan 16, 2015 at 10:48 PM, Dylan Baker baker.dyla...@gmail.com wrote:
On Friday, January 16, 2015 10:18:43 PM Connor Abbott wrote:
Hi Dylan,
On Fri, Jan 16, 2015 at 7:01 PM, Dylan Baker baker.dyla...@gmail.com wrote:
Hi Conner, I have a couple of things you should change, and a
https://bugs.freedesktop.org/show_bug.cgi?id=88523
Vinson Lee v...@freedesktop.org changed:
What|Removed |Added
Status|NEEDINFO|NEW
--
You are
On Tuesday, January 13, 2015 03:35:57 PM Matt Turner wrote:
This is a fix for a regression introduced in commit a9f8296d (i965/fs:
Preserve the CFG in a few more places.).
The errata this code works around is described in a comment before the
function:
[DevBW, DevCL] Errata: A
On Fri, Jan 16, 2015 at 11:45 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On Tuesday, January 13, 2015 03:35:57 PM Matt Turner wrote:
This is a fix for a regression introduced in commit a9f8296d (i965/fs:
Preserve the CFG in a few more places.).
The errata this code works around is
62 matches
Mail list logo
