On Fri, Apr 12, 2019 at 6:46 PM Alyssa Rosenzweig
wrote:
> On Mali hardware (supported by Panfrost and Lima), the fixed-function
> transformation from world-space to screen-space coordinates is done in
> the vertex shader prior to writing out the gl_Position varying, rather
> than in dedicated ha
Patch series are:
Reviewed-by: Qiang Yu
Regards,
Qiang
On Sat, Apr 13, 2019 at 7:46 AM Alyssa Rosenzweig wrote:
>
> On Mali hardware (supported by Panfrost and Lima), the fixed-function
> transformation from world-space to screen-space coordinates is done in
> the vertex shader prior to writin
This patch is
Reviewed-by: Ian Romanick
On 4/12/19 4:46 PM, Alyssa Rosenzweig wrote:
> On Mali hardware (supported by Panfrost and Lima), the fixed-function
> transformation from world-space to screen-space coordinates is done in
> the vertex shader prior to writing out the gl_Position varying,
On 4/12/19 5:11 PM, Ian Romanick wrote:
> On 4/8/19 5:34 AM, Thomas Helland wrote:
>> man. 8. apr. 2019 kl. 06:30 skrev Alyssa Rosenzweig :
>>>
>>> On Mali hardware (supported by Panfrost and Lima), the fixed-function
>>> transformation from world-space to screen-space coordinates is done in
>>> th
On 4/8/19 5:34 AM, Thomas Helland wrote:
> man. 8. apr. 2019 kl. 06:30 skrev Alyssa Rosenzweig :
>>
>> On Mali hardware (supported by Panfrost and Lima), the fixed-function
>> transformation from world-space to screen-space coordinates is done in
>> the vertex shader prior to writing out the gl_Pos
> I believe it's agreement in mesa that the if ( ... ) should be on one line,
> and the continue, return, etc should be on a new one.
Fixed in v3.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mes
> This should be done per nir function, and I suggest to divide this function
> into more sub-functions to follow conventions of other nir_lower_*
> implementation.
You only should be writing gl_Position once anyway; why reinit for
functions that likely won't use them?
lower_alpha_test does it th
v2: Run before lowering I/O.
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 105 +-
1 file changed, 4 insertions(+), 101 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard
On Mali hardware (supported by Panfrost and Lima), the fixed-function
transformation from world-space to screen-space coordinates is done in
the vertex shader prior to writing out the gl_Position varying, rather
than in dedicated hardware. This commit adds a shared NIR pass for
implementing coordin
Just a message to Eric,
as per our previous private thread,
I've checked that the Android build works,
but we use libLLVM70 name in library dependency.
Please adapt and apply the patch to mesa dev branch,
to fix the breakage
\ prior to " in the LLVM version string value, just touching
Android.m
Fixes the following building errors:
external/mesa/src/gallium/drivers/r600/r600_pipe_common.c:1290:14:
error: expected ')'
", LLVM " MESA_LLVM_VERSION_STRING
^
:8:34: note: expanded from here
^
external/mesa/src/gallium/
Done locally.
Marek
On Fri, Apr 12, 2019 at 12:20 PM Samuel Pitoiset
wrote:
> I would suggest to document that workaround somewhere in the code.
>
> On 4/12/19 5:17 PM, Marek Olšák wrote:
> > From: Marek Olšák
> >
> > This is a workaround for a thread deadlock that I have no idea
> > why it oc
The 2D pipe is useful to implement fast planar and interleaved YUV buffer
imports. Not all systems have a 2D capable core, so this is strictly
optional.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_context.c | 6 ++
src/gallium/drivers/etnaviv/etnaviv_context.h | 1 +
src
We weren't handling this flag at all, which broke some assumptions
made by the users of the resource_create interface. As we can't render
to a linear surface and the usefulness of yet another layout transition
to handle this case seems limited, we only respect the flag when the
resource isn't used
We copy the template resource content into the newly allocated resource.
If the template derived from a planar resource this leads to a non reference
counted copy of the next resource pointer. Make sure to clear this out when
allocating a new resource.
Signed-off-by: Lucas Stach
---
src/gallium/
The GC320 without the 2D tiling feature doesn't support regular blits
with YUV input, as well as the tiled output. So on those cores we need
need to do a filter blit for the YUV->RGB conversion to a temporary
linear buffer and then do a tiling blit into the texture buffer using
the RS engine on the
This allows color space conversion and tiling in a single step, as
well as handling multi-planar formats like NV12, which are really
useful when dealing with hardware video decoders.
Signed-off-by: Lucas Stach
---
.../drivers/etnaviv/etnaviv_clear_blit.c | 2 +-
src/gallium/drivers/etnaviv
Imported resources might not start at offset 0 into the buffer object.
Make sure to remember the offset that is provided with the handle on
import.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_resource.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/driver
This adds a blit path using the 2D GPU for a linear YUV to tiled RGB
blit. This allows to implement importing of planar YUV textures with
a single copy.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/Makefile.sources |2 +
src/gallium/drivers/etnaviv/etnaviv_2d.c | 164 ++
The new 2D YUV blit needs this in some cases, so make it available.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_rs.c | 2 +-
src/gallium/drivers/etnaviv/etnaviv_rs.h | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv
From: Philipp Zabel
Fix the gbm_dri_bo_get_handle_for_plane use case by allowing plane > 0
in dri2_from_planar for images with multiple planes in separate chained
texture resources.
Signed-off-by: Philipp Zabel
---
src/gallium/state_trackers/dri/dri2.c | 12 +++-
1 file changed, 11 ins
If the driver supports multi-planar formats natively we don't want to
re-write the format of the planes on import. Split this out in a
separate function for clarity.
Signed-off-by: Lucas Stach
---
src/gallium/state_trackers/dri/dri2.c | 32 ++-
1 file changed, 22 insertio
If the driver provides native support for YUV textures we can skip
adding additional samplers and re-writing the shaders.
Signed-off-by: Lucas Stach
---
src/mesa/state_tracker/st_atom_sampler.c | 6 ++
src/mesa/state_tracker/st_atom_texture.c | 6 ++
src/mesa/state_tracker/st_program.h
The Mesa state tracker will emulate YUV texture sampling for drivers that
don't support it natively by using multiple R8/RG88 samplers. Teach
dri2_query_dma_buf_modifiers about this special case.
This allows clients like GStreamer glupload or Kodi to properly query
the supported dma-buf import form
From: Philipp Zabel
Images with multiple planes in separate chained texture resources should
report the correct number of planes.
Signed-off-by: Philipp Zabel
---
src/gallium/state_trackers/dri/dri2.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_tr
Unconditionally requesting both bindings can lead to premature
failure to create a valid image.
Signed-off-by: Lucas Stach
---
src/gallium/state_trackers/dri/dri2.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gal
I would suggest to document that workaround somewhere in the code.
On 4/12/19 5:17 PM, Marek Olšák wrote:
From: Marek Olšák
This is a workaround for a thread deadlock that I have no idea
why it occurs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108879
Fixes: 9b331e462e5021d9948597
https://bugs.freedesktop.org/show_bug.cgi?id=110345
--- Comment #11 from Samuel Pitoiset ---
Does the problem still happen if you try to downgrade your kernel?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=109326
--- Comment #1 from Erik Faye-Lund ---
An MR has been submitted here:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/648
--
You are receiving this mail because:
You are the QA Contact for the bug.__
possibly? :)
Reviewed-by: Samuel Pitoiset
On 4/12/19 5:40 PM, Marek Olšák wrote:
From: Marek Olšák
---
src/amd/common/ac_nir_to_llvm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 55c64e2a
On Friday, 2019-04-12 11:50:11 -0400, Marek Olšák wrote:
> On Fri, Apr 12, 2019 at 11:41 AM Eric Engestrom
> wrote:
>
> > On Friday, 2019-04-12 11:00:56 -0400, Marek Olšák wrote:
> > > On Thu, Apr 11, 2019 at 2:53 AM Tapani Pälli
> > wrote:
> > > > On 4/11/19 3:32 AM, Marek Olšák wrote:
> > > >
Looks correct to me.
For the series,
Reviewed-by: Roland Scheidegger
Am 11.04.19 um 18:05 schrieb Emil Velikov:
> The function is analogous to lp_fence_wait() while taking at timeout
> (ns) parameter, as needed for EGL fence/sync.
>
> Cc: Roland Scheidegger
> Signed-off-by: Emil Velikov
> ---
On Fri, Apr 12, 2019 at 11:41 AM Eric Engestrom
wrote:
> On Friday, 2019-04-12 11:00:56 -0400, Marek Olšák wrote:
> > On Thu, Apr 11, 2019 at 2:53 AM Tapani Pälli
> wrote:
> > > On 4/11/19 3:32 AM, Marek Olšák wrote:
> > > > - file = fopen(filename, "w");
> > > > + }
> > > > +
On Friday, 2019-04-12 11:00:56 -0400, Marek Olšák wrote:
> On Thu, Apr 11, 2019 at 2:53 AM Tapani Pälli wrote:
> > On 4/11/19 3:32 AM, Marek Olšák wrote:
> > > - file = fopen(filename, "w");
> > > + }
> > > + FILE *file = fopen(filename, "r");
> > > + if (!file)
> > >
From: Marek Olšák
---
src/amd/common/ac_nir_to_llvm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 55c64e2aacb..afdd9318fff 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_ni
https://bugs.freedesktop.org/show_bug.cgi?id=110253
--- Comment #2 from Gregory Popovitch ---
Could this possibly affect the AMD Radeon Pro 19.Q1.1 drivers?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug._
Am 12.04.19 um 14:34 schrieb Dominik Drees:
> Hi Roland!
>
> On 4/11/19 8:18 PM, Roland Scheidegger wrote:
>> What version of mesa are you using?
> The original results were generated using version 19.0.2 (from the arch
> linux repositories), but I got the same results using the current git
> vers
From: Marek Olšák
This is a workaround for a thread deadlock that I have no idea
why it occurs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108879
Fixes: 9b331e462e5021d994859756d46cd2519d9c9c6e
---
src/gallium/drivers/radeonsi/si_clear.c| 6 +++---
src/gallium/drivers/radeon
On 4/12/19 5:04 PM, Marek Olšák wrote:
On Thu, Apr 11, 2019 at 3:15 AM Samuel Pitoiset
mailto:samuel.pitoi...@gmail.com>> wrote:
On 4/11/19 3:30 AM, Marek Olšák wrote:
> From: Marek Olšák mailto:marek.ol...@amd.com>>
>
> ---
> src/amd/common/ac_nir_to_llvm.c | 70
+
On Thu, Apr 11, 2019 at 3:15 AM Samuel Pitoiset
wrote:
>
> On 4/11/19 3:30 AM, Marek Olšák wrote:
> > From: Marek Olšák
> >
> > ---
> > src/amd/common/ac_nir_to_llvm.c | 70 +++--
> > 1 file changed, 5 insertions(+), 65 deletions(-)
> >
> > diff --git a/src/amd/com
On Thu, Apr 11, 2019 at 2:53 AM Tapani Pälli wrote:
>
> On 4/11/19 3:32 AM, Marek Olšák wrote:
> > From: Marek Olšák
> >
> > ---
> > src/mesa/main/shaderapi.c | 20 +---
> > 1 file changed, 17 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/mesa/main/shaderapi.c b/src/m
Reviewed-by: Alyssa Rosenzweig
Looks great! pan_context.c is definitely some of the most fragile code
in the driver right now, so I'm thrilled to get some attention to clean
it up :)
(Not tested by me yet -- I won't be able to test until next week)
___
https://bugs.freedesktop.org/show_bug.cgi?id=99781
tele4...@hotmail.com changed:
What|Removed |Added
CC||tele4...@hotmail.com
--- Comment #
Hi Roland!
On 4/11/19 8:18 PM, Roland Scheidegger wrote:
What version of mesa are you using?
The original results were generated using version 19.0.2 (from the arch
linux repositories), but I got the same results using the current git
version (98934e6aa19795072a353dae6020dafadc76a1e3).
The de
Reviewed-by: Samuel Pitoiset
On 4/12/19 12:15 PM, Rhys Perry wrote:
Seems it was missing the "/ ma + 0.5" and the order was swapped.
Fixes: a1a2a8dfda7b9cac7e ('nir: add AMD_gcn_shader extended instructions')
Signed-off-by: Rhys Perry
---
src/amd/common/ac_nir_to_llvm.c | 11 +--
s
Seems it was missing the "/ ma + 0.5" and the order was swapped.
Fixes: a1a2a8dfda7b9cac7e ('nir: add AMD_gcn_shader extended instructions')
Signed-off-by: Rhys Perry
---
src/amd/common/ac_nir_to_llvm.c | 11 +--
src/compiler/nir/nir_opcodes.py | 21 +++--
2 files changed
The caller of ->set_vertex_buffers() might want to update only a subset
of the currently active vertex buffers, hence the start_slot and
num_buffers arguments.
The panfrost driver was assuming that the whole set of vertex buffers
were to be freed/updated each time this hook is called, which leads t
47 matches
Mail list logo
