On Tue, 2018-04-24 at 07:58 -0700, Jason Ekstrand wrote:
> On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga om> wrote:
> > The lowering pass was specialized to act on 64-bit to 32-bit
> > conversions only,
> >
> > but the implementation is valid for other cases.
> >
> > ---
> >
> > src/int
On Tue, 2018-04-24 at 23:11 -0400, Jason Ekstrand wrote:
> On April 24, 2018 18:38:33 Rob Clark wrote:
>
> On Tue, Apr 24, 2018 at 5:45 PM, Jason Ekstrand > wrote:
> On Tue, Apr 24, 2018 at 7:38 AM, Rob Clark
> wrote:
>
> side-note, not sure if it really effects what you are doing here, but
>
On 2018-04-24 22:31:23, Bas Nieuwenhuizen wrote:
> On Wed, Apr 25, 2018 at 6:38 AM, Jordan Justen
> wrote:
> > On 2018-04-24 18:49:10, Mike Lothian wrote:
> >> Can you also add radeon to the amd one? That works on autotools
> >
> > There is already a with_gallium_radeonsi flag. Is that what you me
On Wed, Apr 25, 2018 at 6:38 AM, Jordan Justen
wrote:
> On 2018-04-24 18:49:10, Mike Lothian wrote:
>> Can you also add radeon to the amd one? That works on autotools
>
> There is already a with_gallium_radeonsi flag. Is that what you mean?
I'm guessing that he means that we currently use -Dvulka
Reviewed-by: Tapani Pälli
On 25.04.2018 04:16, Jordan Justen wrote:
Fixes: 5608d0a2cee "meson: use array type options"
Cc: Dylan Baker
Signed-off-by: Jordan Justen
---
meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 52a107
https://bugs.freedesktop.org/show_bug.cgi?id=22973
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 2018-04-24 18:49:10, Mike Lothian wrote:
> Can you also add radeon to the amd one? That works on autotools
There is already a with_gallium_radeonsi flag. Is that what you mean?
This is just a patch to fix the vulkan variables after 5608d0a2cee.
Without this change, setting -Dvulkan-drivers=int
On Monday, April 23, 2018 2:52:44 AM PDT Tapani Pälli wrote:
> Patch enables use of short and unsigned short data for texture uploads,
> rendering and reading of framebuffers within the restrictions specified
> in GL_EXT_texture_norm16 spec.
>
> Patch also enables those 16bit format layout qualifi
https://bugs.freedesktop.org/show_bug.cgi?id=104490
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On April 24, 2018 18:38:33 Rob Clark wrote:
On Tue, Apr 24, 2018 at 5:45 PM, Jason Ekstrand wrote:
On Tue, Apr 24, 2018 at 7:38 AM, Rob Clark wrote:
side-note, not sure if it really effects what you are doing here, but
karol ran into some cases, like 8bit signed imax, which needs to be
"lower
Can you also add radeon to the amd one? That works on autotools
On Wed, 25 Apr 2018 at 02:16 Jordan Justen
wrote:
> Fixes: 5608d0a2cee "meson: use array type options"
> Cc: Dylan Baker
> Signed-off-by: Jordan Justen
> ---
> meson.build | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(
https://bugs.freedesktop.org/show_bug.cgi?id=106209
--- Comment #3 from Jan Vesely ---
Looks like we don't link to libclangFrontend, which is required since r330571.
This should, however, be handled by llvm/clang when listing libraries required
for components.
--
You are receiving this mail bec
Fixes: 5608d0a2cee "meson: use array type options"
Cc: Dylan Baker
Signed-off-by: Jordan Justen
---
meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 52a1075823f..c0e5c94d794 100644
--- a/meson.build
+++ b/meson.build
@@ -213,8 +2
On 2018-04-24 07:01 PM, Drew Davenport wrote:
VASurfaceAttribExternalBuffers.pitches is indexed by
plane. Current implementation only supports single plane layout.
Reviewed-by: Leo Liu
---
src/gallium/state_trackers/va/surface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This comment made more sense when it was above the calls to
intel_miptree_slice_set_needs_depth_resolve(). We stopped using these
functions at commit 554f7d6d02931ea45653c8872565d21c1678a6da
("i965: Move depth to the new resolve functions").
---
src/mesa/drivers/dri/i965/brw_clear.c | 4
1 fi
Determine the predicate for updating the indirect depth value in the
loop which inspects whether or not we need to resolve any slices.
---
src/mesa/drivers/dri/i965/brw_clear.c | 43 +--
1 file changed, 16 insertions(+), 27 deletions(-)
diff --git a/src/mesa/driver
If the aux state is CLEAR and clear color value has changed, only the
surface state must be updated. The bit-pattern in the aux buffer is
exactly the same.
v2: Handle the indirect color on gen10+.
Reviewed-by: Rafael Antognolli
Reviewed-by: Jason Ekstrand
---
src/mesa/drivers/dri/i965/brw_blor
Split out this functionality to enable a fast-clear optimization for
color miptrees in the next commit.
v2: Avoid the additional refactor (Jason).
---
src/mesa/drivers/dri/i965/brw_clear.c | 23 +--
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 22 +++
Reduce complexity and allow the next patch to delete some code. With
this change, clear operations will still be skipped and setting the
aux_state will cause no side-effects.
Remove the associated comment which implies an early return.
---
src/mesa/drivers/dri/i965/brw_clear.c | 5 -
1 file c
On Mon, Apr 23, 2018 at 03:05:27PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> Signed-off-by: Matt Atwood
> ---
> include/pci_ids/i965_pci_ids.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
> index
https://bugs.freedesktop.org/show_bug.cgi?id=99116
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Tue, Apr 24, 2018 at 4:02 PM Drew Davenport
wrote:
> VASurfaceAttribExternalBuffers.pitches is indexed by
> plane. Current implementation only supports single plane layout.
Reviewed-by: Kristian H. Kristensen
> ---
> src/gallium/state_trackers/va/surface.c | 2 +-
> 1 file changed, 1 ins
VASurfaceAttribExternalBuffers.pitches is indexed by
plane. Current implementation only supports single plane layout.
---
src/gallium/state_trackers/va/surface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_tracker
On 25/04/18 07:34, Ian Romanick wrote:
On 04/24/2018 09:28 AM, Ian Romanick wrote:
On 04/23/2018 08:23 PM, Timothy Arceri wrote:
On 24/04/18 10:13, Dieter Nützel wrote:
Hello Timo,
what about 2 and 3, #1 landed.
It turns out the old radeon classic drivers do make use of the param
dropped
Reviewed-by: Leo Liu
And Cc Mesa-stable as well.
On 2018-04-24 04:49 PM, boyuan.zh...@amd.com wrote:
From: Boyuan Zhang
Previous bit-fields assignments are incorrect and will result certain mpeg4
decode failed due to wrong flag values. This patch fixes these assignments.
Signed-off-by: Boy
On Tue, Apr 24, 2018 at 5:45 PM, Jason Ekstrand wrote:
> On Tue, Apr 24, 2018 at 7:38 AM, Rob Clark wrote:
>>
>> side-note, not sure if it really effects what you are doing here, but
>> karol ran into some cases, like 8bit signed imax, which needs to be
>> "lowered" to 16b (or 32b) and converted
For the series:
Reviewed-by: Marek Olšák
Marek
On Tue, Apr 24, 2018 at 12:54 AM, Timothy Arceri
wrote:
> From: Boyan Ding
>
> When draw buffers are changed on a bound framebuffer, DrawBufferAllocate()
> hook should be called. However, it is missing in update_framebuffer with
> window-system
Reviewed-by: Marek Olšák
Marek
On Tue, Apr 24, 2018 at 1:48 PM, Emil Velikov
wrote:
> From: Emil Velikov
>
> As the function says - only the visual is changed.
>
> Signed-off-by: Emil Velikov
> ---
> src/gallium/state_trackers/dri/dri_screen.c | 3 ++-
> src/gallium/state_trackers/dri/dri_s
Reviewed-by: Marek Olšák
Marek
On Tue, Apr 24, 2018 at 5:16 PM, Dylan Baker wrote:
> Because I clearly wasn't thinking and clearly didn't do a good job
> testing. Sigh
>
> Fixes: c5a97d658ec19cc02719d7f86c1b0715e3d9ffc4
>("meson: fix builds against LLVM built without rtti")
> Signed-of
On Wed, Apr 25, 2018 at 12:00 AM, Stefan Schake wrote:
> v2 drops the submit flags, directly moves in fence handling to the
> job submit function and queries for the syncobj cap instead of using
> a separate support parameter.
>
> This series adds support for the native fence fd extension to vc4.
Require a version of libdrm with syncobj support. In the meson build,
this currently introduces a requirement on libdrm_vc4 which we technically
no longer need for vc4.
Signed-off-by: Stefan Schake
---
configure.ac | 2 ++
meson.build | 2 ++
2 files changed, 4 insertions(+)
diff --git a/confi
This gives us access to the fence created for the render job.
v2: Drop flag (Eric)
Signed-off-by: Stefan Schake
---
src/gallium/drivers/vc4/vc4_context.c | 10 --
src/gallium/drivers/vc4/vc4_context.h | 5 -
src/gallium/drivers/vc4/vc4_job.c | 24 +++-
3 fil
We need to know if the kernel supports syncobj submission since otherwise
all the DRM syncobj calls fail.
v2: Use drmGetCap to detect syncobj support (Eric)
Signed-off-by: Stefan Schake
---
src/gallium/drivers/vc4/vc4_screen.c | 6 ++
src/gallium/drivers/vc4/vc4_screen.h | 1 +
2 files chan
With the syncobj support in place, lets use it to implement the
EGL_ANDROID_native_fence_sync extension. This mostly follows previous
implementations in freedreno and etnaviv.
v2: Drop the flags (Eric)
Handle in_fence_fd already in job_submit (Eric)
Drop extra vc4_fence_context_init (Eric)
v2 drops the submit flags, directly moves in fence handling to the
job submit function and queries for the syncobj cap instead of using
a separate support parameter.
This series adds support for the native fence fd extension to vc4.
The implementation relies on a newly introduced kernel interface
v2: Synchronized with kernel v2
Signed-off-by: Stefan Schake
---
include/drm-uapi/vc4_drm.h | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/include/drm-uapi/vc4_drm.h b/include/drm-uapi/vc4_drm.h
index 4117117..bc2d3ed 100644
--- a/include/drm-uapi/vc4_drm.h
+++
This was missed in the move back to the local uapi copy.
libdrm_vc4 only seems to consist of headers that also exist in the
Mesa tree.
Signed-off-by: Stefan Schake
---
configure.ac | 1 -
1 file changed, 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 33c8d08..9a38471 100644
--- a/
9-11 are
Reviewed-by: Jason Ekstrand
On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga
wrote:
> ---
> src/intel/vulkan/anv_device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 7522b7865c2..30
On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga
wrote:
> From: Jose Maria Casanova Crespo
>
> 16-bit immediates are replicated in each word of a 32-bit value
> so we need to negate both.
> ---
> src/intel/compiler/brw_shader.cpp | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Reviewed-by: Jason Ekstrand
On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga
wrote:
> From: Jose Maria Casanova Crespo
>
> ---
> src/intel/compiler/brw_fs_nir.cpp | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_
On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga
wrote:
> From: Jose Maria Casanova Crespo
>
> ---
> src/compiler/nir/nir_opt_constant_folding.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/compiler/nir/nir_opt_constant_folding.c
> b/src/compiler/nir/nir_opt_constant_foldi
On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga
wrote:
> ---
> src/intel/compiler/brw_fs_nir.cpp | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index 5c414e45b61..ad31f7c82d
Reviewed-by: Jason Ekstrand
On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga
wrote:
> ---
> src/intel/compiler/brw_fs_nir.cpp | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index 5e0dd37eefd..5c414e45b6
On Tue, Apr 24, 2018 at 7:38 AM, Rob Clark wrote:
> side-note, not sure if it really effects what you are doing here, but
> karol ran into some cases, like 8bit signed imax, which needs to be
> "lowered" to 16b (or 32b) and converted back for hw that doesn't
> support smaller than 16b (or 32b).
On 04/24/2018 09:28 AM, Ian Romanick wrote:
> On 04/23/2018 08:23 PM, Timothy Arceri wrote:
>> On 24/04/18 10:13, Dieter Nützel wrote:
>>> Hello Timo,
>>>
>>> what about 2 and 3, #1 landed.
>>
>> It turns out the old radeon classic drivers do make use of the param
>> dropped in patch 2 so I've deci
Because I clearly wasn't thinking and clearly didn't do a good job
testing. Sigh
Fixes: c5a97d658ec19cc02719d7f86c1b0715e3d9ffc4
("meson: fix builds against LLVM built without rtti")
Signed-off-by: Dylan Baker
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
On Fri, Apr 13, 2018 at 6:01 AM Daniel Vetter
wrote:
> This tries to align with the X.org communities's long-standing
> tradition of trying to be an inclusive community and handing out
> commit rights fairly freely.
> We also tend to not revoke commit rights for people no longer
> regularly acti
I just sent a patch that fixes the deadlock.
Marek
On Tue, Apr 24, 2018 at 4:40 PM, Marek Olšák wrote:
> On Wed, Apr 18, 2018 at 6:11 AM, Nicolai Hähnle
> wrote:
>
>> How can this possibly deadlock? Is this during process exit, like in the
>> case where we got a deadlock when LLVM called abort
From: Marek Olšák
Cc: 18.0 18.1
---
src/util/u_queue.c | 9 +
src/util/u_queue.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/src/util/u_queue.c b/src/util/u_queue.c
index dba23f96456..da513fd9cc5 100644
--- a/src/util/u_queue.c
+++ b/src/util/u_queue.c
@@ -304,20 +304,21 @@ u
From: Boyuan Zhang
Previous bit-fields assignments are incorrect and will result certain mpeg4
decode failed due to wrong flag values. This patch fixes these assignments.
Signed-off-by: Boyuan Zhang
---
src/gallium/drivers/radeon/radeon_vcn_dec.c | 18 +-
1 file changed, 9 inse
https://bugs.freedesktop.org/show_bug.cgi?id=106157
Mark Janes changed:
What|Removed |Added
Depends on||105938
Referenced Bugs:
https://bugs.fre
On Wed, Apr 18, 2018 at 6:11 AM, Nicolai Hähnle wrote:
> How can this possibly deadlock? Is this during process exit, like in the
> case where we got a deadlock when LLVM called abort()?
>
No. It deadlocks at the start. All threads are waiting on the barrier. The
barrier should unblock all threa
On 24/04/18 17:27, srol...@vmware.com wrote:
From: Roland Scheidegger
The logic was flawed, since mul(x,y) will be <= 0 (exactly 0) when
the sign is the same but both numbers are sufficiently small
(if the product is smaller than 2^-128).
This could apparently lead to emitting a sufficient amou
From: Marek Olšák
v2: require the previous level to be clearable for determining whether
the last unaligned level is clearable
---
src/amd/common/ac_surface.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/amd/common/ac_surface.c b/src/amd/common/a
Correct.
Reviewed-by: Samuel Pitoiset
On 04/24/2018 12:39 PM, Karol Herbst wrote:
Imad needs to set a read barrier.
With significant big work groups I was getting wrong results for div u32. Turns
out the issue was with the sched opcodes.
CC: Samuel Pitoiset
Signed-off-by: Karol Herbst
---
On 04/24/2018 07:21 PM, Bas Nieuwenhuizen wrote:
On Tue, Apr 24, 2018 at 8:06 AM, Samuel Pitoiset
wrote:
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 18 ++
src/amd/vulkan/radv_query.c | 4 ++--
2 files changed, 12 insertions(+), 10 deletion
On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov wrote:
> On 13 April 2018 at 11:00, Daniel Vetter wrote:
>> This tries to align with the X.org communities's long-standing
>> tradition of trying to be an inclusive community and handing out
>> commit rights fairly freely.
>>
>> We also tend to not re
On Tue, Apr 24, 2018 at 8:10 PM, Rob Herring wrote:
> On Sun, Apr 15, 2018 at 5:45 PM, Stefan Schake wrote:
>> We can't use any of the existing implementations in u_debug_stack.
>> Android technically has libunwind, but it's been modified to the point
>> where it no longer compiles with the Mesa
Quoting Emil Velikov (2018-04-24 10:49:22)
> From: Emil Velikov
>
> With the recent rework of converting the shell script to a python one
> the check for actual tests was dropped.
>
> Bring that back, since it was explicitly added considering we had a ~2
> year period, during which the tests wer
If you want to do these all at once that's fine, in meson we execute each mode
individually, that's also pretty easy in meson, and would require more work for
autotools, so this seems fine:
Reviewed-by: Dylan Baker
Quoting Emil Velikov (2018-04-24 10:49:20)
> From: Emil Velikov
>
> As of recent
Sure,
Reviewed-by: Dylan Baker
Quoting Emil Velikov (2018-04-24 10:49:21)
> From: Emil Velikov
>
> Bring back the "detection" of the said variables, to allow
> standalone execution.
>
> Fixes: db8cd8e36771 ("glcpp/tests: Convert shell scripts to a python
> script")
> Cc: Dylan Baker
> Signed-
Quoting Emil Velikov (2018-04-24 10:49:19)
> From: Emil Velikov
>
> Mesa explicitly manages the invocation of all python scripts.
> Do so here, by removing the shebang line alongside the execute bit of
> the newly introduced script.
>
> Fixes: db8cd8e36771 ("glcpp/tests: Convert shell scripts to
On Sun, Apr 15, 2018 at 5:45 PM, Stefan Schake wrote:
> We can't use any of the existing implementations in u_debug_stack.
> Android technically has libunwind, but it's been modified to the point
> where it no longer compiles with the Mesa usage. The library is also
> not meant to be referenced by
From: Emil Velikov
Bring back the "detection" of the said variables, to allow
standalone execution.
Fixes: db8cd8e36771 ("glcpp/tests: Convert shell scripts to a python
script")
Cc: Dylan Baker
Signed-off-by: Emil Velikov
---
src/compiler/glsl/glcpp/tests/glcpp-test.sh | 13 +
1 f
From: Emil Velikov
With the recent rework of converting the shell script to a python one
the check for actual tests was dropped.
Bring that back, since it was explicitly added considering we had a ~2
year period, during which the tests were not run.
Fixes: db8cd8e36771 ("glcpp/tests: Convert sh
From: Emil Velikov
Mesa explicitly manages the invocation of all python scripts.
Do so here, by removing the shebang line alongside the execute bit of
the newly introduced script.
Fixes: db8cd8e36771 ("glcpp/tests: Convert shell scripts to a python
script")
Cc: Dylan Baker
Signed-off-by: Emil V
From: Emil Velikov
As of recently both of these have been reworked so they invoke a python
script. At the same time the latter can be executed with the combined
arguments of both scripts.
AKA we no longer need to have them separate.
Signed-off-by: Emil Velikov
---
src/compiler/Makefile.glsl.a
Sent out the wrong patch, please ignore.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Emil Velikov
As the function says - only the visual is changed.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/dri/dri_screen.c | 3 ++-
src/gallium/state_trackers/dri/dri_screen.h | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_track
Signed-off-by: Emil Velikov
---
meson_options.txt| 2 +-
src/gallium/state_trackers/dri/dri_context.c | 13 ++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/meson_options.txt b/meson_options.txt
index a573290b77..d2fd440b37 100644
--- a/me
On Tue, Apr 24, 2018 at 3:13 AM, Johan Helsing wrote:
> Emil: Your alternative patch won't work because dri_make_current is not
> necessarily called with NULL after a buffer has been destroyed.
>
>
> The problematic sequence is a pattern we use in QtWayland:
>
>
> //create temporary context
>
> s
Eric Anholt writes:
> mesa/st decides whether to update samplers after a program change based on
> whether num_textures is nonzero. By not counting samplers in a uniform
> struct, we would segfault in
> KHR-GLES3.shaders.struct.uniform.sampler_vertex if it was run in the same
> context after a n
On 13 April 2018 at 11:00, Daniel Vetter wrote:
> This tries to align with the X.org communities's long-standing
> tradition of trying to be an inclusive community and handing out
> commit rights fairly freely.
>
> We also tend to not revoke commit rights for people no longer
> regularly active in
Reviewed-by: Bas Nieuwenhuizen
On Tue, Apr 24, 2018 at 7:55 AM, Neil Roberts wrote:
> For all of the OpFOrd* comparisons except OpFOrdNotEqual the hardware
> should probably already return false if one of the operands is NaN so
> we don’t need to have an explicit check for it. This seems to at l
On Tue, Apr 24, 2018 at 8:06 AM, Samuel Pitoiset
wrote:
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_cmd_buffer.c | 18 ++
> src/amd/vulkan/radv_query.c | 4 ++--
> 2 files changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_b
https://bugs.freedesktop.org/show_bug.cgi?id=106197
--- Comment #2 from farmboy0+freedesk...@googlemail.com ---
Created attachment 139066
--> https://bugs.freedesktop.org/attachment.cgi?id=139066&action=edit
build log
As far as I can see GBM is enabled.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=106209
Aaron Watry changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.fre
Dylan Baker writes:
> Since mesa_classic is not build-on-demand the tests will create a demand
> and add a bunch of extra compilation.
s/not //?
Other than that, the series is
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
m
Rob Clark writes:
> Karol hit the same thing (with for example, shift instructions) with
> the work for spv compute/kernel support. I *think* the number of
> special cases isn't too high, so probably vtn should just insert the
> appropriate conversion instruction (ie. u2u32, etc) so that if the
From: Roland Scheidegger
The logic was flawed, since mul(x,y) will be <= 0 (exactly 0) when
the sign is the same but both numbers are sufficiently small
(if the product is smaller than 2^-128).
This could apparently lead to emitting a sufficient amount of
additional bogus vertices to overflow the
From: Roland Scheidegger
Simplifies the logic when to emit null tris (albeit the reasons why we
have to do this remain unclear).
This is strictly just logic simplification, the behavior doesn't change
at all.
---
src/gallium/auxiliary/draw/draw_pipe_clip.c | 19 +--
1 file change
Quoting Juan A. Suarez Romero (2018-04-24 01:59:26)
> On Fri, 2018-04-20 at 10:23 -0700, Dylan Baker wrote:
> > Quoting Juan A. Suarez Romero (2018-04-20 10:18:03)
> > > On Thu, 2018-04-05 at 14:51 -0700, Dylan Baker wrote:
> > > > This ports glcpp-test.sh and glcpp-test-cr-lf.sh to a python script
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 18 ++
src/amd/vulkan/radv_query.c | 4 ++--
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index baab8db617..baa28d408
As the implementation is conservative, we can now enable it
by default. It can be disabled with RADV_DEBUG=nooutoforder.
Don't expect much more than 1% of improvements, but the gain
seems consistent.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_debug.h | 1 +
src/amd/vulkan/radv_devi
On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga
wrote:
> The lowering pass was specialized to act on 64-bit to 32-bit conversions
> only,
> but the implementation is valid for other cases.
> ---
> src/intel/compiler/brw_fs_lower_conversions.cpp | 5 -
> src/intel/compiler/brw_fs_nir.cp
For all of the OpFOrd* comparisons except OpFOrdNotEqual the hardware
should probably already return false if one of the operands is NaN so
we don’t need to have an explicit check for it. This seems to at least
work on Intel hardware. This should reduce the number of instructions
generated for the
Reviewed-by: Jason Ekstrand
On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga
wrote:
> We need to use 16-bit constants with 16-bit instructions,
> otherwise we get the following validation error:
>
> "Destination stride must be equal to the ratio of the sizes of
> the execution data type to
side-note, not sure if it really effects what you are doing here, but
karol ran into some cases, like 8bit signed imax, which needs to be
"lowered" to 16b (or 32b) and converted back for hw that doesn't
support smaller than 16b (or 32b). I think I have the same case with
ir3, which also has 16b bu
Ian Romanick writes:
> On 04/23/2018 09:19 AM, Mark Janes wrote:
>> I enabled these tests, and could not make them fail in CI.
>
> Can I consider that a Tested-by?
Sorry, I should have been more explicit. Yes, tested-by.
>> This bug may also be related:
>>
>> https://bugs.freedesktop.org/show
It may be useful to just use nir_algebraic for this. We already do for
trig workarounds. It's more painful from a build-system perspective but,
in general, the fewer hand-rolled algebraic lowering passes we have, the
better.
On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga
wrote:
> The har
https://bugs.freedesktop.org/show_bug.cgi?id=106209
--- Comment #2 from LoneVVolf ---
Created attachment 139056
--> https://bugs.freedesktop.org/attachment.cgi?id=139056&action=edit
configure / make output
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=106209
--- Comment #1 from LoneVVolf ---
Created attachment 139055
--> https://bugs.freedesktop.org/attachment.cgi?id=139055&action=edit
autoreconf output
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Cont
https://bugs.freedesktop.org/show_bug.cgi?id=106209
Bug ID: 106209
Summary: [opencl] [llvm-svn] build failure undefined
reference to `clang::FrontendTimesIsEnabled'
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
On Tue, Apr 24, 2018 at 6:42 AM, Ian Romanick wrote:
> On 04/24/2018 05:44 AM, Rob Clark wrote:
> > On Tue, Apr 24, 2018 at 4:24 AM, Samuel Iglesias Gonsálvez
> > wrote:
> >> Hello,
> >>
> >> Recently, we have found problems between some SPIRV opcodes and NIR.
> >>
> >> SPIR-V allows opcodes to
Patches 1 and 3 are
Reviewed-by: Ian Romanick
On 04/24/2018 12:54 AM, Timothy Arceri wrote:
> ---
> src/mesa/main/framebuffer.c | 18 +-
> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
> index 249e775
On 04/24/2018 05:44 AM, Rob Clark wrote:
> On Tue, Apr 24, 2018 at 4:24 AM, Samuel Iglesias Gonsálvez
> wrote:
>> Hello,
>>
>> Recently, we have found problems between some SPIRV opcodes and NIR.
>>
>> SPIR-V allows opcodes to mix different bit-sizes for their operands, such as
>> for some bitfie
On 04/23/2018 08:23 PM, Timothy Arceri wrote:
> On 24/04/18 10:13, Dieter Nützel wrote:
>> Hello Timo,
>>
>> what about 2 and 3, #1 landed.
>
> It turns out the old radeon classic drivers do make use of the param
> dropped in patch 2 so I've decided to drop that patch, although the use
> of that p
On 04/23/2018 09:19 AM, Mark Janes wrote:
> I enabled these tests, and could not make them fail in CI.
Can I consider that a Tested-by?
> This bug may also be related:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=95009
If none of these tests fail with this patch, I'm included to close them
https://bugs.freedesktop.org/show_bug.cgi?id=106157
Darek changed:
What|Removed |Added
CC||dz1125.bug.trac...@gmail.co
|
https://bugs.freedesktop.org/show_bug.cgi?id=106157
Daniel Stone changed:
What|Removed |Added
Component|Other |Drivers/X11
--- Comment #2 from Daniel S
1 - 100 of 125 matches
Mail list logo
