On Fri, Jan 16, 2015 at 11:45 PM, Kenneth Graunke 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 described in a c
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:
https://bugs.freedesktop.org/show_bug.cgi?id=88523
Vinson Lee changed:
What|Removed |Added
Status|NEEDINFO|NEW
--
You are receiving this mail because
On Fri, Jan 16, 2015 at 10:48 PM, Dylan Baker 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 wrote:
>> > Hi Conner, I have a couple of things you should change, and a suggestion
>> > for you below, hopefully it
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
On Sat, Jan 17, 2015 at 11:19 AM, Kenneth Graunke wrote:
> I dislike how fs_reg has a constructor that knows about fs_visitor.
> Apart from that
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 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:
Hi Dylan,
On Fri, Jan 16, 2015 at 7:01 PM, Dylan Baker 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 where a file, nir_op
https://bugs.freedesktop.org/show_bug.cgi?id=88519
Matt Turner changed:
What|Removed |Added
QA Contact||mesa-dev@lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=88523
--- Comment #3 from Jonathan Gray ---
If I rename util/sha1.h to util/xsha1.h matching the xserver name the correct
sha1.h is picked up. Otherwise picks up util/sha1.h
--
You are receiving this mail because:
You are the assignee for the bug.
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
> >
> > Some shaders end up with code that looks something like:
> >
> > if (some_condition)
> > result = 1.0;
> > else
> > result = 0.0;
> >
>
https://bugs.freedesktop.org/show_bug.cgi?id=88523
--- Comment #2 from Jonathan Gray ---
SHA1_CTX is defined in sha1.h
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/include/sha1.h?rev=HEAD&content-type=text/plain
The xserver code this was based off builds fine so there must be a Mesa
s
https://bugs.freedesktop.org/show_bug.cgi?id=88523
Carl Worth changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Carl Worth --
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=88478
Vinson Lee changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=88519
Carl Worth changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |cwo...@cworth.org
|org
https://bugs.freedesktop.org/show_bug.cgi?id=88519
Carl Worth changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Carl Worth --
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 v
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:
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
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 Jan 16
On Jan 16, 2015 4:19 PM, "Kenneth Graunke" 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 just that. Al
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 co
With the previous commits in place, it just works.
Signed-off-by: Kenneth Graunke
---
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
index 6490788..786e4e0 100
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
---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 91 +++-
1 file changed, 32 i
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 "vg
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
SHA
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 wrote:
> Hi,
>
> This is a series I had floating around a while. The idea is to have all the
> opcode stuff, including constant folding, derive
Reviewed-by: Jason Ekstrand
Signed-off-by: Connor Abbott
---
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 4df9bdd..cdf0023 100644
--- a/src/glsl/nir/nir_
Signed-off-by: Connor Abbott
---
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
+++ b/src/glsl/nir/.gitignore
@@ -0,
Signed-off-by: Connor Abbott
---
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 6c02582..496aa41 100644
--- a/
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 cons
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 w
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 before
On Thursday, January 15, 2015 07:12:20 AM Jason Ekstrand wrote:
> On Jan 15, 2015 12:27 AM, "Eero Tamminen" wrote:
> >
> > Hi,
> >
> > On 01/15/2015 03:04 AM, Matt Turner wrote:
> >>
> >> On Wed, Jan 14, 2015 at 1:52 PM, Matt Turner wrote:
> >>>
> >>> On Wed, Jan 14, 2015 at 1:29 PM, Matt Turner
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.
---
src/gallium/drivers/r
The first three are
Reviewed-by: Matt Turner
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
I meant to make this comment earlier but have been busy with other stuff.
I like these optimizations in terms of the code they generate. Good work on
figuring those out! That said, I'm a little pensive about adding more
GLSL-IR-specific stuff to fs_visitor that we'll just have to rewrite for
NIR.
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" wrote:
>
> Jason Ekstrand writes:
>
> > This looks fine to me. We should probably also do this for snorm
formats.
> > I do
On Jan 16, 2015 5:09 AM, "Iago Toral" wrote:
>
> Looks good to me.
> Jason: does this get your R-b?
Sure.
>
> 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 suppo
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 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 wrote:
>> Looks good to me.
>> Ja
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 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 and the w
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 . I left some comments on 4 but
nothing functional.
On Jan 16, 2015 5:29 AM, "Kenneth Graunke" wrote:
>
> In order to support calling lower
On Jan 16, 2015 5:30 AM, "Kenneth Graunke" wrote:
>
> Signed-off-by: Kenneth Graunke
> ---
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=88480
Brian Paul changed:
What|Removed |Added
Component|Other |New Accounts
Assignee|mesa-dev@li
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 1
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.
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:18
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 builds,
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 th
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
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 t
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
---
configure.ac| 2 ++
m4/ax_gcc_func_attribute.m4 | 9 +
2 files changed, 11 insertions(+)
diff --
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 usin
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 future.
https://bugs.freedesktop.org/show_bug.cgi?id=88488
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Reviewed-by: Tapani Pälli
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 to decide if there
is
Signed-off-by: Kenneth Graunke
---
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 a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/dr
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:
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 "vg
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 seems
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 th
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
ES3-CTS.
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
Sev
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 wrote:
> Thanks Roland and everyone else for the input. Based on the feedback
> I'll in
64 matches
Mail list logo
