On 24/07/18 14:24, Marek Olšák wrote:
On Mon, Jul 23, 2018 at 11:33 PM, Timothy Arceri wrote:
On 24/07/18 11:15, Marek Olšák wrote:
On Fri, Jul 20, 2018 at 12:53 AM, Dave Airlie wrote:
On 20 July 2018 at 13:12, Marek Olšák wrote:
From: Marek Olšák
To make
On Mon, Jul 23, 2018 at 11:33 PM, Timothy Arceri wrote:
> On 24/07/18 11:15, Marek Olšák wrote:
>>
>> On Fri, Jul 20, 2018 at 12:53 AM, Dave Airlie wrote:
>>>
>>> On 20 July 2018 at 13:12, Marek Olšák wrote:
From: Marek Olšák
To make
From: Marek Olšák
v2: need to do MAX{start+count} instead of MAX{count}
added piglit tests
---
src/gallium/auxiliary/util/u_vbuf.c | 199
1 file changed, 175 insertions(+), 24 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_vbuf.c
From: Marek Olšák
---
src/mesa/main/draw_validate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/draw_validate.c b/src/mesa/main/draw_validate.c
index c0a234a2bc2..29304bd5144 100644
--- a/src/mesa/main/draw_validate.c
+++ b/src/mesa/main/draw_validate.c
From: Marek Olšák
This will be used by indirect multidraws.
v2: clean up the function further, change return types to unsigned
---
src/gallium/auxiliary/util/u_vbuf.c | 101 ++--
1 file changed, 51 insertions(+), 50 deletions(-)
diff --git
On 24/07/18 11:15, Marek Olšák wrote:
On Fri, Jul 20, 2018 at 12:53 AM, Dave Airlie wrote:
On 20 July 2018 at 13:12, Marek Olšák wrote:
From: Marek Olšák
To make dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.23
finish sooner on the older CPUs. (otherwise it gets killed and we
On Fri, Jul 20, 2018 at 12:53 AM, Dave Airlie wrote:
> On 20 July 2018 at 13:12, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> To make dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.23
>> finish sooner on the older CPUs. (otherwise it gets killed and we fail
>> the test)
>
> I
On Thu, Jul 19, 2018 at 8:48 AM, Daniel Schürmann
wrote:
> Signed-off-by: Daniel Schürmann
> ---
> src/amd/common/ac_llvm_build.c | 25 +
> src/amd/common/ac_llvm_build.h | 8
> src/amd/common/ac_nir_to_llvm.c | 21 ++---
> 3 files changed, 51
From: Marek Olšák
in order to support ASTC
---
src/mesa/state_tracker/st_cb_texture.c | 41 +++---
src/mesa/state_tracker/st_texture.h| 13
2 files changed, 31 insertions(+), 23 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
From: Marek Olšák
---
src/mesa/Makefile.sources |2 +
src/mesa/main/formats.c| 42 +
src/mesa/main/formats.h|3 +
src/mesa/main/texcompress_astc.cpp | 1871
src/mesa/main/texcompress_astc.h | 47 +
src/util/half_float.c
From: Marek Olšák
in order to support ASTC
---
src/mesa/state_tracker/st_cb_copyimage.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_copyimage.c
b/src/mesa/state_tracker/st_cb_copyimage.c
index 5230b61877f..f5d8c047800
From: Marek Olšák
---
src/mesa/state_tracker/st_format.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 9ae796eca9e..45513e8683e 100644
--- a/src/mesa/state_tracker/st_format.c
From: Marek Olšák
---
src/mesa/state_tracker/st_cb_texture.c | 17 +++-
src/mesa/state_tracker/st_context.c| 3 ++
src/mesa/state_tracker/st_context.h| 1 +
src/mesa/state_tracker/st_extensions.c | 5 +++
src/mesa/state_tracker/st_format.c | 56 ++
5
From: Marek Olšák
Not sure if GL/GLES can hit this path, but it's just decompression.
---
src/mesa/state_tracker/st_cb_texture.c | 41 ++
1 file changed, 41 insertions(+)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index
Hi,
This series enables ASTC texture compression for all Gallium drivers
that don't support it in hardware. The works the same as the ETC2
fallback, i.e. it decompresses ASTC inside glCompressedTexImage to
a supported uncompressed format.
RadeonSI now finally supports the following:
-
From: Marek Olšák
for ASTC support later
---
src/mesa/state_tracker/st_cb_copyimage.c | 4 ++--
src/mesa/state_tracker/st_cb_texture.c | 24 ++--
src/mesa/state_tracker/st_texture.h | 2 +-
3 files changed, 17 insertions(+), 13 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=107351
--- Comment #10 from Bas Nieuwenhuizen ---
If you're in a position to get more useful info, it would be great if you could
dump the *pCreateInfo arg of the crashing radv_CreateImage.
--
You are receiving this mail because:
You are the QA
https://bugs.freedesktop.org/show_bug.cgi?id=107351
--- Comment #9 from Bas Nieuwenhuizen ---
Yes, images not explicitly using the path for Android cross-api interop should
just follow the normal path.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA
https://bugs.freedesktop.org/show_bug.cgi?id=107351
--- Comment #8 from Mauro Rossi ---
In the code between ANDROID braces, is it correct that code falls through in
case of !gralloc_info or should it bail out?
Just a question as I may be very wrong and confused
#ifdef ANDROID
const
https://bugs.freedesktop.org/show_bug.cgi?id=107351
--- Comment #7 from Bas Nieuwenhuizen ---
Looking at the full backtrace it looks like plain texture creation, nothing
Android specific so I'll need to debug the specific app sometime.
07-22 21:31:16.071 5007 5007 F DEBUG : backtrace:
07-22
On 23/07/18 22:48, Alejandro Piñeiro wrote:
On 21/07/18 05:15, Timothy Arceri wrote:
On 21/07/18 13:09, Timothy Arceri wrote:
Reviewed-by: Timothy Arceri
Actually I take that back. This introduces a dependency on GL in NIR,
Hmm, but that dependency is already there. nir.h includes
https://bugs.freedesktop.org/show_bug.cgi?id=107351
--- Comment #6 from Mauro Rossi ---
Created attachment 140802
--> https://bugs.freedesktop.org/attachment.cgi?id=140802=edit
extended logcat to see what happens before and after
extended logcat to see what happens before and after
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=107351
--- Comment #5 from Mauro Rossi ---
>Is ANDROID properly defined?
Yes, because it is defined by the build system itself,
without need of passing the LOCAL_CFLAGS := -DANDROID
Mauro
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=107295
Roland Scheidegger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107351
--- Comment #4 from Bas Nieuwenhuizen ---
No, on ANDROID, the call to radv_image_from_gralloc should happen for wsi
images and wsi_info should be always NULL.
Is ANDROID properly defined?
--
You are receiving this mail because:
You are the
On Jul 23, 2018 22:05, Dave Airlie wrote:On 20 July 2018 at 13:39, Gurchetan Singh wrote:
> Reviewed-by: Gurchetan Singh
> On Wed, Jul 18, 2018 at 4:06 AM Erik Faye-Lund
> wrote:
>>
>> The IOCTLs doesn't pass this along, so computing them in the first
>> place is kinda pointless.
>>
>>
https://bugs.freedesktop.org/show_bug.cgi?id=107351
--- Comment #3 from Mauro Rossi ---
Hi Bas,
the problem was obeserved in the last month, but the relevant parts
radv_image.c and radv_android.c did not change,
so anything between 3da693b and HEAD
the addr2line output is not always reliable
On Monday, July 23, 2018 1:24:08 PM PDT Rob Clark wrote:
> On Mon, Jul 23, 2018 at 1:25 PM, Eric Anholt wrote:
> > Eric Anholt writes:
> >
> >> This is controlled by a new nir_shader_compiler_options flag, and fixes
> >> dEQP-GLES3.functional.shaders.builtin_variable.pointcoord on V3D.
> >> ---
On Monday, July 23, 2018 10:46:31 AM PDT Jason Ekstrand wrote:
> The original pass only looked for load_uniform intrinsics but there are
> a number of other places that could end up loading a push constant. One
> obvious omission was images which always implicitly use a push constant.
> Legacy VS
On Mon, Jul 23, 2018 at 08:20:15PM +0100, Chris Wilson wrote:
> Quoting Nanley Chery (2018-07-23 18:17:15)
> > Satisfy the BLT engine's row pitch limitation on the destination
> > miptree. The destination miptree is untiled, so its row_pitch will be
> > slightly less than or equal to the source
https://bugs.freedesktop.org/show_bug.cgi?id=107351
--- Comment #2 from Bas Nieuwenhuizen ---
Do you have a hash of the upstream git version you based this on? (just so I
can see how the lines correlate in radv_image.c)
--
You are receiving this mail because:
You are the QA Contact for the
On Mon, Jul 23, 2018 at 1:25 PM, Eric Anholt wrote:
> Eric Anholt writes:
>
>> This is controlled by a new nir_shader_compiler_options flag, and fixes
>> dEQP-GLES3.functional.shaders.builtin_variable.pointcoord on V3D.
>> ---
>
> Ken, Rob, any chance you could take a quick look at this? I
These new methods return for a instruction register source/destination
the read/write byte pattern of the 32-byte GRF as an unsigned int.
The returned pattern takes into account the exec_size of the instruction,
the type bitsize, the register stride and a relative offset inside the
register.
The
El 20/07/18 a las 22:10, Francisco Jerez escribió:
> Chema Casanova writes:
>
>> El 20/07/18 a las 00:34, Francisco Jerez escribió:
>>> Chema Casanova writes:
>>>
El 14/07/18 a las 00:14, Francisco Jerez escribió:
> Jose Maria Casanova Crespo writes:
>
>> For a register
Karol Herbst writes:
> On Mon, Jul 23, 2018 at 7:02 PM, Eric Anholt wrote:
>> Karol Herbst writes:
>>
>>> this allows to replace some nir_load_system_value calls with the specific
>>> system value constructor
>>>
>>> Reviewed-by: Jason Ekstrand
>>> Signed-off-by: Karol Herbst
>>> ---
>>>
On 20 July 2018 at 13:39, Gurchetan Singh wrote:
> Reviewed-by: Gurchetan Singh
> On Wed, Jul 18, 2018 at 4:06 AM Erik Faye-Lund
> wrote:
>>
>> The IOCTLs doesn't pass this along, so computing them in the first
>> place is kinda pointless.
>>
>> Signed-off-by: Erik Faye-Lund
>> ---
>>
>> This
On 24 July 2018 at 03:14, Gert Wollny wrote:
> Am Montag, den 23.07.2018, 21:17 +1000 schrieb Dave Airlie:
>> On 23 July 2018 at 17:28, Gert Wollny
>> wrote:
>> > Am Montag, den 23.07.2018, 17:13 +1000 schrieb Dave Airlie:
>> > > On 23 July 2018 at 16:46, Gert Wollny
>> > > wrote:
>> > > > Am
https://bugs.freedesktop.org/show_bug.cgi?id=107351
--- Comment #1 from Mauro Rossi ---
Created attachment 140797
--> https://bugs.freedesktop.org/attachment.cgi?id=140797=edit
logcat of slingshot extreeme vulkan test
--
You are receiving this mail because:
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=107351
Bug ID: 107351
Summary: Android 8.1: radv segfault with 3Dmark vulkan
benchmarks
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: other
Quoting Nanley Chery (2018-07-23 18:17:15)
> Satisfy the BLT engine's row pitch limitation on the destination
> miptree. The destination miptree is untiled, so its row_pitch will be
> slightly less than or equal to the source miptree's row_pitch. Use the
> source miptree's row_pitch in
https://bugs.freedesktop.org/show_bug.cgi?id=107305
Caio Marcelo de Oliveira Filho changed:
What|Removed |Added
Resolution|--- |FIXED
On 23/07/18 18:46, Jason Ekstrand wrote:
The original pass only looked for load_uniform intrinsics but there are
a number of other places that could end up loading a push constant. One
obvious omission was images which always implicitly use a push constant.
Legacy VS clip planes also get pushed
Looks reasonable,
Reviewed-By: Gert Wollny
Am Donnerstag, den 19.07.2018, 14:42 +1000 schrieb Dave Airlie:
> From: Dave Airlie
>
> There might be a nicer way to do this, but this is at least correct.
>
> This fixes:
> KHR-GL44.tessellation_shader.single.max_patch_vertices
> KHR-
>
The original pass only looked for load_uniform intrinsics but there are
a number of other places that could end up loading a push constant. One
obvious omission was images which always implicitly use a push constant.
Legacy VS clip planes also get pushed into the shader.
Cc:
Funny thing about this... this is how i915 implements ABS. :)
Reviewed-by: Ian Romanick
On 07/23/2018 12:02 AM, Jason Ekstrand wrote:
> Spotted in a shader in Batman: Arkham City.
> ---
> src/compiler/nir/nir_opt_algebraic.py | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
Reviewed-by: Matt Turner
and pushed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Eric Anholt writes:
> This is controlled by a new nir_shader_compiler_options flag, and fixes
> dEQP-GLES3.functional.shaders.builtin_variable.pointcoord on V3D.
> ---
Ken, Rob, any chance you could take a quick look at this? I think this
is the last change I need in Mesa for GLES2
Satisfy the BLT engine's row pitch limitation on the destination
miptree. The destination miptree is untiled, so its row_pitch will be
slightly less than or equal to the source miptree's row_pitch. Use the
source miptree's row_pitch in can_blit_slice instead of its blt_pitch.
Fixes
On Mon, Jul 23, 2018 at 7:02 PM, Eric Anholt wrote:
> Karol Herbst writes:
>
>> this allows to replace some nir_load_system_value calls with the specific
>> system value constructor
>>
>> Reviewed-by: Jason Ekstrand
>> Signed-off-by: Karol Herbst
>> ---
>>
Am Montag, den 23.07.2018, 21:17 +1000 schrieb Dave Airlie:
> On 23 July 2018 at 17:28, Gert Wollny
> wrote:
> > Am Montag, den 23.07.2018, 17:13 +1000 schrieb Dave Airlie:
> > > On 23 July 2018 at 16:46, Gert Wollny
> > > wrote:
> > > > Am Montag, den 23.07.2018, 09:04 +1000 schrieb Dave
Instead of using _mesa_is_winsys_fbo or
_mesa_is_user_fbo to infer if an fbo is
flipped use the InvertedY flag.
v2:
* additional window-system framebuffer checks [for jason]
v3:
* s/inverted_y/flip_y/g [for chadv]
* s/InvertedY/FlipY/g [for chadv]
---
src/mesa/drivers/dri/i965/brw_blorp.c
Adds an extension to glFramebufferParameteri
that will specify if the framebuffer is vertically
flipped. Historically system framebuffers are
vertically flipped and user framebuffers are not.
Checking to see the state was done by looking at
the name field. This adds an explicit field.
v2:
*
Hi Ville,
> I noticed a while back that xonotic had started to misrender the gun
> models on i915. Yesterday I bisected it down to commit 64d2a2048054
> ("mesa: Make gl_vertex_array contain pointers to first order VAO
> members."). Actually that commit broke things even worse (and the
> game
Karol Herbst writes:
> this allows to replace some nir_load_system_value calls with the specific
> system value constructor
>
> Reviewed-by: Jason Ekstrand
> Signed-off-by: Karol Herbst
> ---
> src/compiler/nir/nir_builder_opcodes_h.py | 21 +++--
> 1 file changed, 19
On 2018-07-23 03:29:21, Eero Tamminen wrote:
> Hi,
>
> Should this fix also:
> https://bugs.freedesktop.org/show_bug.cgi?id=106382
> ?
>
It helped a bit. For me, on a simple test program, it allowed shader
time to work once, even when the cache had a non-shader-time program.
But,
On Thu, Jul 19, 2018 at 2:48 PM, Daniel Schürmann
wrote:
> Signed-off-by: Daniel Schürmann
> ---
> src/compiler/glsl_types.h | 15 +++
> src/compiler/nir_types.cpp | 12
> src/compiler/nir_types.h | 1 +
> 3 files changed, 28 insertions(+)
>
> diff --git
Acked-by: Dylan Baker
Quoting Juan A. Suarez Romero (2018-07-23 02:22:06)
> Reviewed-by: Juan A. Suarez
>
> Reviewed/Acked/Agreed, whatever makes more sense :)
>
>
>
> J.A.
>
> On Thu, 2018-07-19 at 16:00 +0300, Andres Gomez wrote:
> > As discussed at:
> >
https://bugs.freedesktop.org/show_bug.cgi?id=54971
Julien Isorce changed:
What|Removed |Added
CC||julien.iso...@gmail.com
--
You are
Hi Mathias,
I noticed a while back that xonotic had started to misrender the gun
models on i915. Yesterday I bisected it down to commit 64d2a2048054
("mesa: Make gl_vertex_array contain pointers to first order VAO
members."). Actually that commit broke things even worse (and the
game would even
On 07/23/2018 04:02 PM, Bas Nieuwenhuizen wrote:
On Mon, Jul 23, 2018 at 1:50 PM, Samuel Pitoiset
wrote:
When we keep shader info for eg. RADV_TRACE_FILE, we don't
free the NIR when creating the pipelines. Though, we have to
free it when destroying the shader module.
Signed-off-by: Samuel
Behavior wrt firstInstance got changed, and a divisor of 0 has been
disallowed.
The new version of the ext got published in specification 1.1.81.
---
src/amd/vulkan/radv_extensions.py | 2 +-
src/amd/vulkan/radv_nir_to_llvm.c | 7 ---
2 files changed, 5 insertions(+), 4 deletions(-)
diff
On Mon, Jul 23, 2018 at 1:08 AM Timothy Arceri
wrote:
> Ian and I have been looking at these type of things recently. Ian has
> started work on a pass to cover this stuff without having to add dozens
> of these types of opts.
>
>
Reviewed-by: Jason Ekstrand
On Mon, Jul 23, 2018 at 4:05 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> Thanks Alex!
>
> Reviewed-by: Lionel Landwerlin
>
> On 23/07/18 09:51, Alex Smith wrote:
> > According to the spec, these should apply to all read/write access
> > types (so
On Mon, Jul 23, 2018 at 1:50 PM, Samuel Pitoiset
wrote:
> When we keep shader info for eg. RADV_TRACE_FILE, we don't
> free the NIR when creating the pipelines. Though, we have to
> free it when destroying the shader module.
>
> Signed-off-by: Samuel Pitoiset
> ---
>
On 21/07/18 05:15, Timothy Arceri wrote:
> On 21/07/18 13:09, Timothy Arceri wrote:
>> Reviewed-by: Timothy Arceri
>
> Actually I take that back. This introduces a dependency on GL in NIR,
Hmm, but that dependency is already there. nir.h includes GL/gl.h, and
in fact, there is a comment
https://bugs.freedesktop.org/show_bug.cgi?id=106893
--- Comment #14 from Alex Smith ---
If ever there is a need to get a trace, I've given Samuel details of a game
option that can be set to disable the background pipeline preloading.
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=106893
John changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #13 from John ---
I'm
Kernel (for ppgtt) requires memory address to be
aligned to page size (4096).
Added such alignment for buffers marked with EXEC_OBJECT_PINNED.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106997
Fixes: a363bb2cd0e2 (i965: Allocate VMA in userspace for full-PPGTT systems.)
Signed-off-by:
When we keep shader info for eg. RADV_TRACE_FILE, we don't
free the NIR when creating the pipelines. Though, we have to
free it when destroying the shader module.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_shader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 22/07/18 00:09, srol...@vmware.com wrote:
From: Roland Scheidegger
The pt emit path can only handle 65535 - the number of vertices is
truncated to a ushort, resulting in a too small buffer allocation, which
will crash.
Forcing the pipeline path looks suboptimal, then again this bug is
https://bugs.freedesktop.org/show_bug.cgi?id=106893
Samuel Pitoiset changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On 23 July 2018 at 17:28, Gert Wollny wrote:
> Am Montag, den 23.07.2018, 17:13 +1000 schrieb Dave Airlie:
>> On 23 July 2018 at 16:46, Gert Wollny
>> wrote:
>> > Am Montag, den 23.07.2018, 09:04 +1000 schrieb Dave Airlie:
>> > >
>> > > > > + uint32_t max_shader_buffer = shader ==
>> > > > >
On 23 July 2018 at 20:48, Erik Faye-Lund wrote:
> New versions of virglrenderer supports the precise-flag, so let's
> forward it from TGSI if that's the case.
Reviewed-by: Dave Airlie
>
> This fixes a few dEQP-GLES31 tests:
> -
Thanks Alex!
Reviewed-by: Lionel Landwerlin
On 23/07/18 09:51, Alex Smith wrote:
According to the spec, these should apply to all read/write access
types (so would be equivalent to specifying all other access types
individually). Currently, they were doing nothing.
v2: Handle
New versions of virglrenderer supports the precise-flag, so let's
forward it from TGSI if that's the case.
This fixes a few dEQP-GLES31 tests:
- dEQP-GLES31.functional.tessellation.common_edge.quads_equal_spacing_precise
-
This patch is:
Reviewied-By: Karol Herbst
forgot to add that
On Mon, Jul 23, 2018 at 11:40 AM, Rhys Perry wrote:
> This hits the shader-db numbers a good bit, though a few xmads is way
> faster than an imul or imad and the cost is mitigated by the next commit,
> which optimizes many
Signed-off-by: Rhys Perry
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 26 ++
.../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 18 +--
.../drivers/nouveau/codegen/nv50_ir_print.cpp | 19
Strongly mitigates the harm from the previous commit, which made many
integer multiplications much more heavy on the register and instruction
count.
total instructions in shared programs : 5839715 -> 5801926 (-0.65%)
total gprs used in shared programs: 670553 -> 669853 (-0.10%)
total shared
Changes in v3:
- stylistic changes
- simplify createMulMethod2()
- update shader-db statistics
- use util_bitcount64 and util_next_power_of_two64 instead of
reimplementing them
Changes in v2:
- rebase
- bring back constant folding for multiplication by power-of-twos for nv50
- remove TODO in
This hits the shader-db numbers a good bit, though a few xmads is way
faster than an imul or imad and the cost is mitigated by the next commit,
which optimizes many multiplications by immediates into shorter and less
register heavy instructions than the xmads.
total instructions in shared
Signed-off-by: Rhys Perry
---
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 65 ++
.../nouveau/codegen/nv50_ir_target_gm107.cpp | 6 +-
.../nouveau/codegen/nv50_ir_target_nvc0.cpp| 1 +
3 files changed, 71 insertions(+), 1 deletion(-)
diff --git
On 20/07/18 18:32, Jason Ekstrand wrote:
> This should already be handled by nir_gather_info. Is there some
> reason why we need to do it here as well?
Seems so. I have just tried to remove this patch, and I got no
regressions with run our specific tests, and a full run with the
borrowed tests.
Hi,
Should this fix also:
https://bugs.freedesktop.org/show_bug.cgi?id=106382
?
- Eero
On 23.07.2018 07:27, Jordan Justen wrote:
Since various options within INTEL_DEBUG could impact code generation,
we need to set the disk cache driver_flags parameter based on the
INTEL_DEBUG
On Fri, Jul 20, 2018 at 10:59:03AM +0100, Lionel Landwerlin wrote:
> On 20/07/18 09:32, aravindan.muthuku...@intel.com wrote:
> >diff --git a/src/egl/generate/egl.xml b/src/egl/generate/egl.xml
> >index 9250f93..52b0c9f 100644
> >--- a/src/egl/generate/egl.xml
> >+++ b/src/egl/generate/egl.xml
>
Reviewed-by: Juan A. Suarez
J.A.
On Thu, 2018-07-19 at 15:21 -0700, Dylan Baker wrote:
> Quoting Andres Gomez (2018-07-19 06:03:11)
> > Additionally, I've extended the 18.1 cycle by one more release,
> > tentatively assigned to Dylan, due to the ~2 weeks delay for 18.2.
>
> This seems
Reviewed-by: Juan A. Suarez
Reviewed/Acked/Agreed, whatever makes more sense :)
J.A.
On Thu, 2018-07-19 at 16:00 +0300, Andres Gomez wrote:
> As discussed at:
> https://lists.freedesktop.org/archives/mesa-dev/2018-March/188525.html
>
> Cc: Emil Velikov
> Cc: Juan A. Suarez Romero
https://bugs.freedesktop.org/show_bug.cgi?id=106590
--- Comment #3 from Zhaowei Yuan ---
I posted patch v2 to cc more maintainer:
https://patchwork.freedesktop.org/patch/240324/
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107156
Gregor Münch changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|REOPENED
https://bugs.freedesktop.org/show_bug.cgi?id=107276
Gregor Münch changed:
What|Removed |Added
CC||ximi...@mail.ru
--- Comment #6 from
According to the spec, these should apply to all read/write access
types (so would be equivalent to specifying all other access types
individually). Currently, they were doing nothing.
v2: Handle VK_ACCESS_MEMORY_WRITE_BIT in dstAccessMask.
Signed-off-by: Alex Smith
Cc:
Line number of a predefined macro should be set
as where it is referenced rather than declared
Patch v2 does nothing more except ccing more maintainers
Signed-off-by: zhaowei yuan
Bugzilla: https://patchwork.freedesktop.org/patch/225818/
---
src/compiler/glsl/glcpp/glcpp-lex.l | 1 +
On 20 July 2018 at 19:01, Jason Ekstrand wrote:
> On Fri, Jul 20, 2018 at 8:37 AM Lionel Landwerlin <
> lionel.g.landwer...@intel.com> wrote:
>
>> On 20/07/18 11:44, Alex Smith wrote:
>>
>> According to the spec, these should apply to all read/write access
>> types (so would be equivalent to
Ian and I have been looking at these type of things recently. Ian has
started work on a pass to cover this stuff without having to add dozens
of these types of opts.
https://lists.freedesktop.org/archives/mesa-dev/2018-July/200583.html
On 23/07/18 17:36, Jason Ekstrand wrote:
Spotted in a
In order to be sure loop_terminator_list is an accurate
representation of all the jumps in the loop we need to be sure we
didn't encounter any other complex behaviour such as continues,
nested breaks, etc during analysis.
This will be used in the following patch.
---
src/compiler/nir/nir.h
In GLSL IR we cheat with switch statements and simply convert them
into loops with a single iteration. This allowed us to make use of
the existing jump instruction handling provided by the loop handing
code, it also allows dead code to be cleaned up once we have
wrapped the code in a loop.
Now that SSA values can be derefs and they have special rules, we have
to be a bit more careful about our LCSSA phis. In particular, we need
to clean up in case LCSSA ended up creating a phi node for a deref.
This avoids validation issues with some CTS tests with the following
patch, but its
The innermost check was added to stop us from unrolling multiple
loops in a single pass, and to stop outer loops from unrolling.
When we successfully unroll a loop we need to run the analysis
pass again before deciding if we want to go ahead an unroll a
second loop.
However the logic was flawed
This adds support for unrolling the classic
do {
// ...
} while (false)
that is used to wrap multi-line macros. GLSL IR also wraps switch
statements in a loop like this.
shader-db results IVB:
total loops in shared programs: 2515 -> 2512 (-0.12%)
loops in affected programs: 33
This will help later patches with unrolling loops that end with a
break i.e. loops the always exit on their first interation.
---
src/compiler/nir/nir_loop_analyze.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/compiler/nir/nir_loop_analyze.c
v2:
- make use of nir_block_dominates() in the if-statement opts as suggested
by Connor. This allowed for a reduction in code required but also allowed
me to implemented some extra optimisations.
- implement feedback from Jason on loop unrolling opts.
1 - 100 of 118 matches
Mail list logo
