On 22 January 2015 at 11:35, Matt Turner wrote:
> On Wed, Jan 21, 2015 at 5:28 PM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> anonymous structs/union don't work with c99 but do work with gnu99
>> on gcc 4.4.
>>
>> This on top of Jason's designated initialisers changes, make
>> Mesa build on R
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
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,
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
We can do this now that we have opcode info available in Python.
Signed-off-by: Connor Abbott
---
src/glsl/nir/nir_algebraic.py | 38 ++
src/glsl/nir/nir_opt_algebraic.py | 6 ++
2 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/src/gls
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 878436b..e8a361f 100644
--- a/
On Wed, Jan 21, 2015 at 11:03 PM, Jason Ekstrand wrote:
> Connor wrote *exactly* the same patch:
>
> http://lists.freedesktop.org/archives/mesa-dev/2015-January/074522.html
>
> This version can have my R-B too. And, fwiw, I like your commit message
> better.
Indeed... let's push this version, si
On Wed, 2015-01-21 at 15:55 -0800, Matt Turner wrote:
> On Wed, Jan 21, 2015 at 3:49 PM, Jan Vesely wrote:
> > On Wed, 2015-01-21 at 12:34 -0800, Ian Romanick wrote:
> >> On 01/21/2015 10:33 AM, Jan Vesely wrote:
> >> > NFC.
> >>
> >> NFC? I'm assuming this doesn't mean Near Field Communications
Emil Velikov, le Thu 22 Jan 2015 16:52:06 +, a écrit :
> On 14/01/15 19:36, Axel Davy wrote:
> > To fix build when libdrm is not found,
> > commit a594cec7e3ef275c386054127a357110a19dd823 did put several
> > parts of egl code under #ifdef HAVE_DRM_PLATFORM.
> >
> > HAVE_DRM_PLATFORM means the
> -Original Message-
> From: Ian Romanick [mailto:i...@freedesktop.org]
> Sent: Wednesday, January 21, 2015 5:22 AM
> To: Predut, Marius; mesa-dev@lists.freedesktop.org
> Cc: mesa-sta...@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [mesa-dev][PATCH] Remove UINT_AS_FLT, INT_AS_FLT,
> FL
> -Original Message-
> From: Neil Roberts [mailto:n...@linux.intel.com]
> Sent: Thursday, January 22, 2015 3:32 PM
> To: Predut, Marius; mesa-dev@lists.freedesktop.org
> Cc: mesa-sta...@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH v1] Remove UINT_AS_FLT, INT_AS_FLT,
> FLOAT_AS_FLT
> -Original Message-
> From: Kenneth Graunke [mailto:kenn...@whitecape.org]
> Sent: Thursday, January 22, 2015 8:02 AM
> To: mesa-dev@lists.freedesktop.org
> Cc: Predut, Marius; mesa-sta...@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH v1] Remove UINT_AS_FLT, INT_AS_FLT,
> FLOAT_
Hi Emil,
On Thu, Jan 22, 2015 at 4:38 PM, Emil Velikov wrote:
> On 22/01/15 22:23, Haixia Shi wrote:
>> Hi Emil
>>
>> On Thu, Jan 22, 2015 at 1:36 PM, Emil Velikov
>> wrote:
>>> Hi Haixia Shi,
>>>
>>> On 22/01/15 17:35, Haixia Shi wrote:
Try the render node first and use it if available. O
Argh, nevermind, I was reading it wrong...
On Thu, Jan 22, 2015 at 8:18 PM, Connor Abbott wrote:
> What happens if you have something like foo = vec3(foo.z, bar.x,
> foo.x)? I don't think emitting vector mov's for only the contiguous
> components is enough.
>
> On Thu, Jan 22, 2015 at 4:51 PM, Er
What happens if you have something like foo = vec3(foo.z, bar.x,
foo.x)? I don't think emitting vector mov's for only the contiguous
components is enough.
On Thu, Jan 22, 2015 at 4:51 PM, Eric Anholt wrote:
> It now emits vector MOVs instead of a series of individual MOVs, which
> should be usefu
On Thu, Jan 22, 2015 at 4:36 PM, Emil Velikov wrote:
>> +static const char* node_path_fmt_card = "/dev/dri/card%d";
> You can reuse the DRM_DIR_NAME + DRM_DEV_NAME macros (from xf86drm.h)
> for this.
>
>> +static const char* node_path_fmt_render = "/dev/dri/renderD%d";
> There is no macro for the
Hello list,
A candidate for the stable 10.4.3 release has been pushed. It covers
more than 40 fixes for the nine state-tracker, amongst others.
A brief log (for non-nine related changes)
Jason Ekstrand (1):
mesa: Fix clamping to -1.0 in snorm_to_float
Jonathan Gray (1):
glsl: Link g
On 22/01/15 22:23, Haixia Shi wrote:
> Hi Emil
>
> On Thu, Jan 22, 2015 at 1:36 PM, Emil Velikov
> wrote:
>> Hi Haixia Shi,
>>
>> On 22/01/15 17:35, Haixia Shi wrote:
>>> Try the render node first and use it if available. Otherwise fall back to
>>> normal nodes.
>>>
>> What is the use-case for s
Also, Could we rename this to nir_lower_alu_to_scalar? That's more
descriptive.
--Jason
On Thu, Jan 22, 2015 at 4:27 PM, Jason Ekstrand
wrote:
>
>
> On Thu, Jan 22, 2015 at 2:52 PM, Eric Anholt wrote:
>
>> This is the equivalent of brw_fs_channel_expressions.cpp, which I wanted
>> for vc4.
>>
On Thu, Jan 22, 2015 at 2:52 PM, Eric Anholt wrote:
> This is the equivalent of brw_fs_channel_expressions.cpp, which I wanted
> for vc4.
>
> v2: Use the nir_src_for_ssa() helper, and another instance of
> nir_alu_src_copy().
> v3: Drop the non-SSA support. All intended callers will have SSA
On Thu, Jan 22, 2015 at 3:51 PM, Jason Ekstrand wrote:
> When emitting texturing from indirect texture units, we need to be able to
> scratch around in the header message. Since we only do this for >= HSW,
> this is ok since there are no MRFs.
> ---
> src/mesa/drivers/dri/i965/brw_eu_emit.c | 2
On Thursday, January 22, 2015 03:51:28 PM Jason Ekstrand wrote:
> When emitting texturing from indirect texture units, we need to be able to
> scratch around in the header message. Since we only do this for >= HSW,
> this is ok since there are no MRFs.
> ---
> src/mesa/drivers/dri/i965/brw_eu_emi
When emitting texturing from indirect texture units, we need to be able to
scratch around in the header message. Since we only do this for >= HSW,
this is ok since there are no MRFs.
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sr
Ugh, I'd thinko'd this on first reading and assumed that the
adjustment was header.3 += temp -- but it's not; it's header.3 = r0.3
+ temp so this is fine.
Reviewed-by: Chris Forbes
On Fri, Jan 23, 2015 at 10:50 AM, Jason Ekstrand wrote:
> Prior to this commit, the adjust_sampler_state_pointer f
This is the equivalent of brw_fs_channel_expressions.cpp, which I wanted
for vc4.
v2: Use the nir_src_for_ssa() helper, and another instance of
nir_alu_src_copy().
v3: Drop the non-SSA support. All intended callers will have SSA-only ALU
ops.
v4: Use insert_before, drop stale bcsel/fcsel
The NULL platform is for off-screen rendering only.
Try the render node first and use it if available. Otherwise fall back to
normal nodes.
Signed-off-by: Haixia Shi
---
src/egl/drivers/dri2/Makefile.am | 5 +
src/egl/drivers/dri2/egl_dri2.c | 13 ++-
src/egl/drivers/dri2/egl_dri2.h
Hi Emil
On Thu, Jan 22, 2015 at 1:36 PM, Emil Velikov wrote:
> Hi Haixia Shi,
>
> On 22/01/15 17:35, Haixia Shi wrote:
>> Try the render node first and use it if available. Otherwise fall back to
>> normal nodes.
>>
> What is the use-case for such a platform - I assume it's worth
> mentioning in
Jason,
This can't work. We care about the existing value in header.3 (it's a
pointer to the base of the sampler state table) -- you can't just
clobber it.
- Chris
On Fri, Jan 23, 2015 at 10:50 AM, Jason Ekstrand wrote:
> Prior to this commit, the adjust_sampler_state_pointer function took an
>
Jason Ekstrand writes:
> Overall this looks correct. I've got a few nits below and I'd like to take
> a look at it with fresh eyes before giving an R-B as it's complicated
> especially with all of the stuff to handle non-ssa. Not sure if it's
> really worth doing non-ssa now that I see how much
It now emits vector MOVs instead of a series of individual MOVs, which
should be useful to any vector backends. This pushes the problem of
src/dest aliasing of channels on a scalar chip to the backend, but if
there are any vector operations in your shader then you needed to be
handling this alread
Prior to this commit, the adjust_sampler_state_pointer function took an
extra register that it could use as scratch space. The usual candidate was
the destination of the sampler instruction. However, if that register ever
aliased anything important such as the sampler index, this would scratch
al
https://bugs.freedesktop.org/show_bug.cgi?id=88219
Emil Velikov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Haixia Shi,
On 22/01/15 17:35, Haixia Shi wrote:
> Try the render node first and use it if available. Otherwise fall back to
> normal nodes.
>
What is the use-case for such a platform - I assume it's worth
mentioning in the commit message ?
No other platform picks the device at random as seen
On 19/01/15 20:54, Vinson Lee wrote:
> Mac OS X XQuartz places X11 headers at /opt/X11/include.
>
> This patch fixes this Mac OS X SCons build error.
>
> Compiling src/gallium/state_trackers/glx/xlib/glx_api.c ...
> In file included from src/gallium/state_trackers/glx/xlib/glx_api.c:34:
> inclu
https://bugs.freedesktop.org/show_bug.cgi?id=88467
--- Comment #18 from Emil Velikov ---
(In reply to Jason Ekstrand from comment #13)
> (In reply to Emil Velikov from comment #12)
> > Jason,
> >
> > MSVC 2013 supports designated initialisers yet the VMWare guys cannot
> > migrate to it yet iirc
On Thu, 2015-01-22 at 21:11 +0100, Niels Ole Salscheider wrote:
> On Thursday 22 January 2015, 13:46:14, Jan Vesely wrote:
> > On Thu, 2015-01-22 at 16:45 +, Emil Velikov wrote:
> > > On 15/01/15 21:38, Tom Stellard wrote:
> > > > On Thu, Jan 15, 2015 at 07:25:56PM +0100, Niels Ole Salscheider
Try the render node first and use it if available. Otherwise fall back to
normal nodes.
Signed-off-by: Haixia Shi
---
src/egl/drivers/dri2/Makefile.am | 5 +
src/egl/drivers/dri2/egl_dri2.c | 13 ++-
src/egl/drivers/dri2/egl_dri2.h | 3 +
src/egl/drivers/dri2/platform_null.c |
https://bugs.freedesktop.org/show_bug.cgi?id=88720
--- Comment #1 from Axel Davy ---
Created attachment 112685
--> https://bugs.freedesktop.org/attachment.cgi?id=112685&action=edit
GPG public key
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=88720
Bug ID: 88720
Summary: Account request
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
On Thursday 22 January 2015, 13:46:14, Jan Vesely wrote:
> On Thu, 2015-01-22 at 16:45 +, Emil Velikov wrote:
> > On 15/01/15 21:38, Tom Stellard wrote:
> > > On Thu, Jan 15, 2015 at 07:25:56PM +0100, Niels Ole Salscheider wrote:
> > >> Since 8e7df519bd8556591794b2de08a833a67e34d526, we initial
https://bugs.freedesktop.org/show_bug.cgi?id=88275
--- Comment #24 from Timothy Arceri ---
What does it say when you run:
LIBGL_DEBUG=verbose glxinfo | grep direct
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=88467
--- Comment #17 from Jason Ekstrand ---
(In reply to Connor Abbott from comment #16)
> (In reply to Jason Ekstrand from comment #15)
> > (In reply to Connor Abbott from comment #14)
> > > I definitely don't want to remove the anonymous union from
https://bugs.freedesktop.org/show_bug.cgi?id=88467
--- Comment #16 from Connor Abbott ---
(In reply to Jason Ekstrand from comment #15)
> (In reply to Connor Abbott from comment #14)
> > I definitely don't want to remove the anonymous union from nir_src. We use
> > it all over the place, and it r
https://bugs.freedesktop.org/show_bug.cgi?id=88467
--- Comment #14 from Connor Abbott ---
I definitely don't want to remove the anonymous union from nir_src. We use it
all over the place, and it really helps with readability and writeability.
Without it, we would have to say "src[n].src.src.ssa"
https://bugs.freedesktop.org/show_bug.cgi?id=88467
--- Comment #15 from Jason Ekstrand ---
(In reply to Connor Abbott from comment #14)
> I definitely don't want to remove the anonymous union from nir_src. We use
> it all over the place, and it really helps with readability and
> writeability. Wi
This saves about 0.5k in the text section for a gallium driver
on amd64.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 2ed7a3b..f1131d
Haixia Shi writes:
> Try the render node first and use it if available. Otherwise fall back to
> normal nodes.
>
> Signed-off-by: Haixia Shi
> +/*
> + * Mesa 3-D graphics library
> + *
> + * Copyright (c) 2014 The Chromium OS Authors. All rights reserved.
> + *
> + * Based on platform_x11, which
On 10/01/15 07:07, Kenneth Graunke wrote:
> Sandybridge requires the post-sync non-zero workaround in a ton of
> places, and if you ever miss one, the GPU usually hangs.
>
Would it be worth including this in the stable branch ?
Cc:
Thanks
Emil
___
mes
https://bugs.freedesktop.org/show_bug.cgi?id=88467
--- Comment #13 from Jason Ekstrand ---
(In reply to Emil Velikov from comment #12)
> Jason,
>
> MSVC 2013 supports designated initialisers yet the VMWare guys cannot
> migrate to it yet iirc.
>
> On the anonymous unions - perhaps we can nuke t
https://bugs.freedesktop.org/show_bug.cgi?id=88467
--- Comment #12 from Emil Velikov ---
Jason,
MSVC 2013 supports designated initialisers yet the VMWare guys cannot migrate
to it yet iirc.
On the anonymous unions - perhaps we can nuke them by naming them ? There have
been similar problems in t
Jason Ekstrand writes:
> On Wed, Jan 21, 2015 at 5:26 PM, Eric Anholt wrote:
>
>> There aren't many users yet, but I wanted to do this from my scalarizing
>> pass.
>> ---
>> src/glsl/nir/nir.c | 18 ++
>> src/glsl/nir/nir.h | 5 -
>>
On Thu, 2015-01-22 at 16:45 +, Emil Velikov wrote:
> On 15/01/15 21:38, Tom Stellard wrote:
> > On Thu, Jan 15, 2015 at 07:25:56PM +0100, Niels Ole Salscheider wrote:
> >> Since 8e7df519bd8556591794b2de08a833a67e34d526, we initialise all targets
> >> in
> >> clover. This fixes bug 85189.
> >>
On 20/01/15 15:30, marius.pre...@intel.com wrote:
> From: Marius Predut
>
Hi Marius,
Can you rework the lengthy "Remove ." commit summary. Please try to
explain briefly what you've done. Adding the relevant prefix is also
recommended - here is a wild guess:
mesa: correctly interpret integer
From: Michael Olbrich
es2_info, es2gears_x11 and es2tri require X11, so don't build them if X11
is disabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88618
Reviewed-by: Emil Velikov
---
Noticed this patch in bugzilla. Not sure how many people keep an eye on
it so I've decided to
On Thu, Jan 22, 2015 at 9:06 AM, Matt Turner wrote:
> On Thu, Jan 22, 2015 at 7:27 AM, Jason Ekstrand
> wrote:
> > On Jan 22, 2015 3:41 AM, "Kenneth Graunke"
> wrote:
> >> diff --git a/src/glsl/nir/nir_opt_algebraic.py
> >> b/src/glsl/nir/nir_opt_algebraic.py
> >> index 169bb41..cf16b19 100644
On Tue, 2014-12-02 at 14:52 -0500, Jan Vesely wrote:
> On Tue, 2014-12-02 at 11:33 -0500, Tom Stellard wrote:
> > On Mon, Nov 03, 2014 at 08:29:37PM -0500, Jan Vesely wrote:
> > > Signed-off-by: Jan Vesely
> > > ---
> > >
> > > moreover, the condition is never true now that clover appends dim inf
On 15/12/14 12:08, Eduardo Lima Mitev wrote:
> On 12/15/2014 12:21 PM, Emil Velikov wrote:
>>
>> Above you've mentioned "test failures were gathered ... against 10.3.3",
>> which brings the question:
>> Should we include those in either one of the 10.3 and 10.4 stable
>> branches ? Or are they so i
On 11/01/15 08:31, Mathias Fröhlich wrote:
>
>
> Hi,
>
>
>
> On Sunday, January 04, 2015 20:53:59 Emil Velikov wrote:
>
>> Adding Mathias and Frank Binns to the Cc list.
>
>>
>
>> So taking into account the discussion so far, including Mathias's input
>
>> that the official nvidia driver
Hi Kalyan,
On 08/01/15 04:30, Kalyan Kondapally wrote:
[...]
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index b95dfb9..8553a6c 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -1220,6 +1220,8 @@ struct gl_texture_object
> GLboolean Purgeable;
The XExtensionInfo is allocated dynamically (if the pointer is NULL)
in the XEXT_GENERATE_FIND_DISPLAY macro. On the other hand the
macro XEXT_GENERATE_CLOSE_DISPLAY does not check/free the memory.
Follow the example set by dri1 and appledri, and use a static variable.
Spotted while hunting "stil
Try the render node first and use it if available. Otherwise fall back to
normal nodes.
Signed-off-by: Haixia Shi
---
src/egl/drivers/dri2/Makefile.am | 5 +
src/egl/drivers/dri2/egl_dri2.c | 13 ++-
src/egl/drivers/dri2/egl_dri2.h | 3 +
src/egl/drivers/dri2/platform_null.c |
On 05/01/15 17:45, Laura Ekstrand wrote:
> This comment is vague. Do you have a specific recommendation for the
> code here?
>
Seems like I'm way too subtle - yes I have a few.
1. Add ARB_direct_state_access to struct gl_extension
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -37
8-10 are
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 21/12/14 20:08, Ian Romanick wrote:
> From: Ian Romanick
>
Hi Ian,
Imho the series looks like a worthy candidate for 10.4 branch.
Do you have any objections if I scoop it up ?
-Emil
> Signed-off-by: Ian Romanick
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87516
> ---
> src/me
On Thu, Jan 22, 2015 at 3:41 AM, Kenneth Graunke wrote:
> The GLSL IR optimization pass contained these; we may as well include
> them too.
>
> No change in the number of NIR instructions on a shader-db run.
>
> total i965 instructions in shared programs: 6035397 -> 6035393 (-0.00%)
> i965 instruc
On Thu, Jan 22, 2015 at 7:27 AM, Jason Ekstrand wrote:
> On Jan 22, 2015 3:41 AM, "Kenneth Graunke" wrote:
>> diff --git a/src/glsl/nir/nir_opt_algebraic.py
>> b/src/glsl/nir/nir_opt_algebraic.py
>> index 169bb41..cf16b19 100644
>> --- a/src/glsl/nir/nir_opt_algebraic.py
>> +++ b/src/glsl/nir/nir
On 12/01/15 19:27, Adam Jackson wrote:
> This just queries our context, it doesn't attempt to enumerate all the
> available renderers.
>
Hi Adam,
Does this mean that we have anyone outside of mesa exposing the
extension :-) But seriously thanks for doing this.
> Signed-off-by: Adam Jackson
> --
On 14/01/15 19:36, Axel Davy wrote:
> To fix build when libdrm is not found,
> commit a594cec7e3ef275c386054127a357110a19dd823 did put several
> parts of egl code under #ifdef HAVE_DRM_PLATFORM.
>
> HAVE_DRM_PLATFORM means the egl drm platform is being built.
> What should have been used instead i
On 15/01/15 21:38, Tom Stellard wrote:
> On Thu, Jan 15, 2015 at 07:25:56PM +0100, Niels Ole Salscheider wrote:
>> Since 8e7df519bd8556591794b2de08a833a67e34d526, we initialise all targets in
>> clover. This fixes bug 85189.
>>
>> Signed-off-by: Niels Ole Salscheider
> Reviewed-by: Tom Stellard
H
Both do_vs_prog and do_gs_prog initialize brw_stage_prog_data::nr_params to
the number of uniform *vectors* required by the shader rather than the number
of uniform components, contradicting the comment. This is inconsistent with
what the state upload code and scalar path expect but it happens to
I like this, but it's going to conflict with the universe as far as other
i965 not changes are concerned so I'm not sure when we want to land it.
Other than that and the handful of comments, this series is
Reviewed-by: Jason Ekstrand
On Jan 22, 2015 3:41 AM, "Kenneth Graunke" wrote:
> We want t
On Jan 22, 2015 3:41 AM, "Kenneth Graunke" wrote:
>
> This allows us to count NIR instructions via shader-db.
>
> Use "run" as normal. The results file will contain both NIR and
> assembly.
>
> Then, to generate a NIR report:
> ./report.py <(grepNIR results/foo) <(grepNIR results/bar)
>
>
On Jan 22, 2015 3:41 AM, "Kenneth Graunke" wrote:
>
> These also exist in opt_algebraic.cpp.
>
> total NIR instructions in shared programs: 2011430 -> 2011211 (-0.01%)
> NIR instructions in affected programs: 42221 -> 42002 (-0.52%)
> helped:198
>
> total i9
On Jan 22, 2015 3:41 AM, "Kenneth Graunke" wrote:
>
> Matt and I noticed a bunch of "val <- ior a a" operations in a shader,
> so we decided to add an algebraic optimization for that. While there,
> I decided to add a bunch more of them.
>
> total NIR instructions in shared programs: 2023511 -> 2
This series looks really good to me. I can confirm it gives a 241%
transfer rate increase in that little pboUnpack test on BayTrail.
Assuming the minor comments I made are fixed and the v2 patch for the
pthread_once thingy is used then the series is:
Reviewed-by: Neil Roberts
Regards,
- Neil
Ja
Jason Ekstrand writes:
> - }
> + if (_mesa_meta_pbo_GetTexSubImage(ctx, 3, texImage, 0, 0, 0,
> + texImage->Width, texImage->Height,
> + texImage->Depth, format, type,
> + pixels, &ctx-
Jason Ekstrand writes:
> diff --git a/src/mesa/drivers/dri/i965/intel_pixel_read.c
> b/src/mesa/drivers/dri/i965/intel_pixel_read.c
> index 688a919..a64a5f4 100644
> --- a/src/mesa/drivers/dri/i965/intel_pixel_read.c
> +++ b/src/mesa/drivers/dri/i965/intel_pixel_read.c
> @@ -172,15 +58,11 @@ int
Jason Ekstrand writes:
> Since the meta path can do strictly more than the blitter path, we just
> remove the blitter path entirely.
> ---
> src/mesa/drivers/dri/i965/intel_pixel_read.c | 130
> ++-
> 1 file changed, 6 insertions(+), 124 deletions(-)
>
> diff --git a/src
Jason Ekstrand writes:
> ---
> src/mesa/main/dd.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
> index 2f40915..eb30847 100644
> --- a/src/mesa/main/dd.h
> +++ b/src/mesa/main/dd.h
> @@ -415,6 +415,21 @@ struct dd_function_tabl
https://bugs.freedesktop.org/show_bug.cgi?id=88275
--- Comment #23 from Eugene ---
Just a little update. Latest Mesa git and drm-intel-nightly #201501220251.
Issue with mouse is gone and now it's ok. But OGL rendering still not starting:
$glxinfo | grep error
libGL error: failed to create dri sc
Hi,
The COPY_CLEAN_4V_TYPE_AS_FLOAT still doesn't look right because as the
last step it calls COPY_SZ_4V which will copy its float arguments using
floating-point registers. It seems the piglit test case is still failing
and if I step through with GDB I can see that it is hitting this code
and usi
This should not be a change in behavior, as all current cases that
potentially answer "yes" require SSA.
The next patch will introduce another case that requires SSA.
Signed-off-by: Kenneth Graunke
---
src/glsl/nir/nir_opt_cse.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
Sug
Matt and I noticed that one of the shaders hurt by INTEL_USE_NIR=1 had
load_input and load_uniform intrinsics repeated several times, with the
same parameters, but each one generating a distinct SSA value. This
made ALU operations on those values appear distinct as well.
Generating distinct SSA v
We want to run CSE and algebraic optimizations again after lowering IO.
Some of the passes in the optimization loop don't handle saturates and
other modifiers, so run it before lowering to source modifiers.
total instructions in shared programs: 6046190 -> 6045768 (-0.01%)
instructions in affected
Matt and I noticed a bunch of "val <- ior a a" operations in a shader,
so we decided to add an algebraic optimization for that. While there,
I decided to add a bunch more of them.
total NIR instructions in shared programs: 2023511 -> 2020814 (-0.13%)
NIR instructions in affected programs: 149
This allows us to count NIR instructions via shader-db.
Use "run" as normal. The results file will contain both NIR and
assembly.
Then, to generate a NIR report:
./report.py <(grepNIR results/foo) <(grepNIR results/bar)
Or, to generate an i965 report:
./report.py <(grep -v NIR results/f
The GLSL IR optimization pass contained these; we may as well include
them too.
No change in the number of NIR instructions on a shader-db run.
total i965 instructions in shared programs: 6035397 -> 6035393 (-0.00%)
i965 instructions in affected programs: 772 -> 768 (-0.52%)
helped:
Most of these exist in the GLSL IR algebraic pass already. However,
SSA allows us to find more instances of the patterns.
total NIR instructions in shared programs: 2015593 -> 2011430 (-0.21%)
NIR instructions in affected programs: 124189 -> 120026 (-3.35%)
helped:
This is useful for debugging and looking for optimization opportunities.
It will need to be expanded when we add support for other scalar stages.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 11 +++
1 file changed, 11 insertions(+)
Yeah, I was lazy. Ad
These also exist in opt_algebraic.cpp.
total NIR instructions in shared programs: 2011430 -> 2011211 (-0.01%)
NIR instructions in affected programs: 42221 -> 42002 (-0.52%)
helped:198
total i965 instructions in shared programs: 6020554 -> 6020118 (-0.01%)
i
The first batch removes bonus fnot/inot operations, possibly allowing
other optimizations to better recognize patterns.
The next batch replaces a fadd and constant 0.0 with an fneg - negation
is usually free on GPUs, while addition is not.
total NIR instructions in shared programs: 2020814 -> 201
Michel Dänzer writes:
> From: Michel Dänzer
>
> That's what device::ir_target() returns. Fixes reading beyond allocated
> memory:
>
> ==1936== Invalid read of size 1
> ==1936==at 0x4C2C1B4: strlen (vg_replace_strmem.c:412)
> ==1936==by 0x9E00C30: std::basic_string,
> std::allocator >::b
93 matches
Mail list logo
