On 23.04.2018 21:45, Samuel Pitoiset wrote:
On 04/23/2018 08:42 PM, Marek Olšák wrote:
On Mon, Apr 23, 2018 at 1:12 PM, Samuel Pitoiset
mailto:samuel.pitoi...@gmail.com>> wrote:
On 04/23/2018 06:55 PM, Nicolai Hähnle wrote:
On 23.04.2018 17:52, Samuel Pitoiset 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
surface1 = eglCreateWindowSurface() <-- dri_drawable pointer is malloce
https://bugs.freedesktop.org/show_bug.cgi?id=106144
Inad changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hey Chih-Wei,
On 04/23/2018 04:17 AM, Chih-Wei Huang wrote:
What's the impact to drm_gralloc?
I'm not terribly familiar with drm_gralloc, but as far as I understand it
depends on flink name support at the moment.
The overarching idea here is to make mesa gralloc independent, but also at the
On Tue, Apr 24, 2018 at 4:26 PM Robert Foss
wrote:
> Hey Chih-Wei,
> On 04/23/2018 04:17 AM, Chih-Wei Huang wrote:
> > What's the impact to drm_gralloc?
> I'm not terribly familiar with drm_gralloc, but as far as I understand it
> depends on flink name support at the moment.
> The overarching
On Fri, 2018-04-20 at 16:42 +0200, Juan A. Suarez Romero wrote:
> Commit fa328456e8f29 added VP9 config support, but this needs a newer
> libva version, 1.7.0 or above.
>
> Fixes: fa328456e8f ("st/va: add VP9 config to enable profile2")
Besides requesting R-B, CCing to @stable, as this fixes 18.1
https://bugs.freedesktop.org/show_bug.cgi?id=106126
Johan Helsing changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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 bitfield operations and other ops like bitwise shifts.
In NIR, when the ALU opcode doesn't have specified bitsizes for their operands
On 2018-04-24 09: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
>
> surfac
If the call to dri_destroy_buffer is delayed until the next eglMakeCurrent,
that would also solve the problem (I'm not sure how that would affect other
things, though).
As long as dri_make_current doesn't compare against a dangling pointer, I'm
happy.
Johan
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 that
> > > accepts arguments for each line ending type. Thi
Hi Johan,
On 24 April 2018 at 09:44, Johan Helsing wrote:
> If the call to dri_destroy_buffer is delayed until the next eglMakeCurrent,
> that would also solve the problem (I'm not sure how that would affect other
> things, though).
It _must_ be:
If the EGL surface surface is not current to an
Please don't top-post.
On 2018-04-24 10:44 AM, Johan Helsing wrote:
> If the call to dri_destroy_buffer is delayed until the next eglMakeCurrent,
> that would also solve the problem (I'm not sure how that would affect other
> things, though).
Looking at the EGL spec, section 3.5.5 "Destroying R
https://bugs.freedesktop.org/show_bug.cgi?id=106197
--- Comment #1 from Daniel Stone ---
Please check the config.log or Meson output from your Mesa build to ensure that
you are building with the DRM/GBM platform.
--
You are receiving this mail because:
You are the QA Contact for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=61933
Daniel Stone changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEEDINFO
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 bitfield operations and other ops like bitwise shifts.
>
Hi Christian,
On Fri, 2018-04-20 at 14:55 +0200, Christian Gmeiner wrote:
> Signed-off-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_translate.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_translate.h
> b/src/gallium/driver
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
---
src/gallium/drivers/nouveau/codegen/lib/gm107.asm | 4 ++--
src/gallium/drivers/nouv
On 24 April 2018 at 08:13, 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.
>
Interesting, the trace attached in the bugreport does a proper
makecurrent/surface dance.
Namely, MakeCurren
Hi Rob,
Thanks for doing this.
There's a couple of small nits, but the patch looks good IMHO.
On the topic of keeping the old code behind a #define or just removing
it, it'll be great if interested parties can reach a consensus.
On 19 April 2018 at 22:09, Rob Herring wrote:
> --- a/src/egl/dr
On 24 April 2018 at 12:28, Emil Velikov wrote:
> On the topic of keeping the old code behind a #define or just removing
> it, it'll be great if interested parties can reach a consensus.
>
Actually one can simply drop this code and drm_gralloc users can add a
drm_ioctl_permit() hack.
Namely: loose
Move to per-generation backend, since these are likely to be fairly
generation specific, and that is nicer than having it split between
freedreno_screen (for the global case) and fd5_compute (for the
kernel-specific limits case)
Signed-off-by: Rob Clark
---
Not totally working yet, so there might
Some limits, such as max # of threads in a work-group, vary depending
on the resources (ie. registers) used by a kernel. OpenCL provides
clGetKernelWorkGroupInfo() for querying these kernel specific limits.
To implement this properly, we need a variant of get_compute_param()
which takes the comput
Not all drivers care when cs.reg_*_mem change. (ir3 only cares about
req_input_mem and removing that dependency should be easy.) Add some
caps to let clover make better decisions about when it needs to re-
create the compute-state CSO.
This way, if the kernel is compiled early for clGetKernelWor
https://bugs.freedesktop.org/show_bug.cgi?id=106157
--- Comment #1 from Darek ---
Description:
Some apps crash on startup (chromium, thunderbird, glxgears, eglgears_x11)
Additional info:
* package version(s)
mesa-18.1.0rc1 (tested also with mesa-git-18.2.0_devel.101822.4559aefb5c)-meson
build
xo
https://bugs.freedesktop.org/show_bug.cgi?id=106157
Daniel Stone changed:
What|Removed |Added
Component|Other |Drivers/X11
--- Comment #2 from Daniel S
https://bugs.freedesktop.org/show_bug.cgi?id=106157
Darek changed:
What|Removed |Added
CC||dz1125.bug.trac...@gmail.co
|
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
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/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
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 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
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)
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
--- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=106209
Aaron Watry changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.fre
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:
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
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 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
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 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
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
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
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 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
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
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
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
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
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
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-
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
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
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
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 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
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
---
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=106157
Mark Janes changed:
What|Removed |Added
Depends on||105938
Referenced Bugs:
https://bugs.fre
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
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
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
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
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 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
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).
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 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
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
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
>
> 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(-)
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
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
+++
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
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/
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)
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
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.
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
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
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
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
1 - 100 of 125 matches
Mail list logo
