ks. We use some data structures from v3d and cleanup the
> clear code here. More in-depth refactors to follow.
Looks great to me, can we get more like this? :)
For the whole series:
Reviewed-by: Tomeu Vizoso
Thanks,
Tomeu
> Alyssa Rosenzweig (3):
> panfrost: Import job data structur
Reviewed-by: Tomeu Vizoso
Thanks,
Tomeu
On Wed, 27 Feb 2019 at 04:44, Alyssa Rosenzweig wrote:
>
> This special-case was needlessly added and breaks purely offscreen
> rendering (when there is no scanout involved).
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> src/gal
Cannot really review this myself, but:
Tested-by: Tomeu Vizoso
Thanks!
Tomeu
On Wed, 27 Feb 2019 at 04:36, Alyssa Rosenzweig wrote:
>
> Previously, we forced a #0 inline constant tacked on for the lut
> instructions to mirror the blob's behaviour, which caused some
> subop
Cannot really review this myself, but:
Tested-by: Tomeu Vizoso
Thanks!
On Wed, 27 Feb 2019 at 06:49, Alyssa Rosenzweig wrote:
>
> smul comes first in the pipeline, before vmul. Until we have a full
> instruction scheduler, it's better to have vmul prioritized to maximize
Cannot really review this myself, but:
Tested-by: Tomeu Vizoso
Thanks!
On Wed, 27 Feb 2019 at 06:49, Alyssa Rosenzweig wrote:
>
> If a selected unit causes a data hazard, the whole block gets cut short.
> So, we preview for data hazards _while_ selecting units.
>
> Signed
This backend interacts with the new DRM driver for Midgard GPUs which is
currently in development.
When using this backend, Panfrost has roughly on-par functionality as
when using the non-DRM driver from Arm.
Signed-off-by: Tomeu Vizoso
---
include/drm-uapi/panfrost_drm.h| 128
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_allocate.c | 4 ++--
src/gallium/drivers/panfrost/pan_resource.c | 2 +-
src/gallium/drivers/panfrost/pan_screen.h| 6 --
src/gallium/drivers/panfrost/pan_wallpaper.c | 2 +-
4 files changed, 4 insertions(+), 10 deletions
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 11 +++
src/gallium/drivers/panfrost/pan_context.h | 7 +++
src/gallium/drivers/panfrost/pan_screen.c | 11 ++-
src/gallium/drivers/panfrost/pan_screen.h | 11 ++-
4 files changed, 30
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index b419f25224f2..776469c3e411 100644
--- a/src/gallium/drivers/panfrost
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 19 +--
src/gallium/drivers/panfrost/pan_context.h | 3 +++
src/gallium/drivers/panfrost/pan_screen.h | 1 +
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers
It will be used by the DRM backend to store GEM handles from the kernel.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_allocate.h | 1 +
src/gallium/drivers/panfrost/pan_resource.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/src/gallium/drivers/panfrost
Implement resource_get_handle for non-scanout cases.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_resource.c | 37 +++--
src/gallium/drivers/panfrost/pan_screen.h | 1 +
2 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/src/gallium/drivers
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 776469c3e411..ac58411b265d 100644
--- a/src
Hi,
the patches in this series get Panfrost working with the DRM driver that
Rob Herring and I have been working on lately:
https://gitlab.freedesktop.org/panfrost/linux/tree/panfrost-5.0-rc4
I get roughly the same demos working with it as with Arm's driver, but
there's lots of improvements to b
On 3/4/19 8:52 PM, Rob Herring wrote:
On Mon, Mar 4, 2019 at 1:38 PM Alyssa Rosenzweig wrote:
unsigned transient_count =
ctx->transient_pools[ctx->cmdstream_i].entry_index*ctx->transient_pools[0].entry_size
+ ctx->transient_pools[ctx->cmdstream_i].entry_offset;
- printf("Uploa
On 3/5/19 1:25 AM, Alyssa Rosenzweig wrote:
Reviewed-by: Alyssa Rosenzweig
Out of curiosity, when would this code path be needed? Was this a
problem on the non-DRM driver too, or just the new kernel which makes
heavier use of real BOs?
With non-DRM this code doesn't execute (at least on the w
On 3/5/19 3:29 AM, Dave Airlie wrote:
On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg wrote:
On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig wrote:
Why aren't we using regular dma-buf fences here? The submit ioctl
should be able to take a number of in fences to wait on and return an
out fe
On 3/5/19 1:44 AM, Alyssa Rosenzweig wrote:
I get roughly the same demos working with it as with Arm's driver, but
there's lots of improvements to be made (mostly in the kernel) to how
memory is managed and jobs are scheduled.
Which demos have regressed, just so we can keep track?
One is that
On 3/5/19 4:24 PM, Alyssa Rosenzweig wrote:
One is that with kbase I don't see any noticeable pauses during the very
first scene in glmark2.
...That sounds like a good thing? :)
I was assuming that the horse should spin smoothly, and not pausing every
second or so, as it happens with the DRM
Also use the raw GPU ID value to decide whether to use SFD or MFD.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 66 ++
src/gallium/drivers/panfrost/pan_context.h | 10
src/gallium/drivers/panfrost/pan_screen.h | 1 +
3 files changed, 41
Signed-off-by: Tomeu Vizoso
Reviewed-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index fdb3aa7ccdc2..3c8a483b8f58 100644
This backend interacts with the new DRM driver for Midgard GPUs which is
currently in development.
When using this backend, Panfrost has roughly on-par functionality as
when using the non-DRM driver from Arm.
Signed-off-by: Tomeu Vizoso
---
v2: - Adapt to changes in the UAPI, mostly one atom
Signed-off-by: Tomeu Vizoso
Reviewed-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 51c2ded48fe4..fdb3aa7ccdc2 100644
--- a
It will be used by the DRM backend to store GEM handles from the kernel.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_allocate.h | 1 +
src/gallium/drivers/panfrost/pan_resource.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/src
Signed-off-by: Tomeu Vizoso
Reviewed-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_allocate.c | 4 ++--
src/gallium/drivers/panfrost/pan_resource.c | 2 +-
src/gallium/drivers/panfrost/pan_screen.h| 6 --
src/gallium/drivers/panfrost/pan_wallpaper.c | 2 +-
4 files
The corresponding change to the kernel can be seen here:
https://gitlab.freedesktop.org/tomeu/linux/commits/panfrost-5.0
Thanks,
Tomeu
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Implement resource_get_handle for non-scanout cases.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 37 +++--
src/gallium/drivers/panfrost/pan_screen.h | 1 +
2 files changed, 20 insertions(+), 18 deletions
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 11 +++
src/gallium/drivers/panfrost/pan_context.h | 7 +++
src/gallium/drivers/panfrost/pan_screen.c | 11 ++-
src/gallium/drivers/panfrost/pan_screen.h | 11 ++-
4 files changed, 30
On Sun, 10 Mar 2019 at 07:50, Alyssa Rosenzweig wrote:
>
> We were setting this bit as a magic value for a while when using depth
> FBOs, but it is only now clear what the meaning is.
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> src/gallium/drivers/panfrost/include/panfrost-job.h | 8
>
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_resource.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index 1a6769b5508e..e398b6f6b7ce 100644
--- a/src/gallium/drivers/panfrost
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_drm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_drm.c
b/src/gallium/drivers/panfrost/pan_drm.c
index 6d1129ff5f2b..62a7b0ce5a30 100644
--- a/src/gallium/drivers
Hi,
I needed the below two patches to avoid regressions when testing this
series.
Thanks,
Tomeu
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
f-by: Alyssa Rosenzweig
Reviewed-by: Tomeu Vizoso
> ---
> src/gallium/drivers/panfrost/pan_resource.c | 56 ++---
> 1 file changed, 26 insertions(+), 30 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_resource.c
> b/src/gallium/drivers/pa
On Sun, 10 Mar 2019 at 07:50, Alyssa Rosenzweig wrote:
>
> AFBC, tiled, and linear BO layouts are mutually exclusive; they should
> be coupled via a single enum rather than ad hoc checks of booleans.
>
> Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Tomeu Vizoso
> ---
>
Reviewed-by: Tomeu Vizoso
On Sun, 10 Mar 2019 at 07:50, Alyssa Rosenzweig wrote:
>
> In an effort to cleanup framebuffer management code, we delay
> colour buffer setup until the FRAGMENT job is actually emitted, allowing
> the AFBC and linear codepaths to be unified.
>
> Sig
On Sun, 10 Mar 2019 at 07:50, Alyssa Rosenzweig wrote:
>
> This emit is only implemented for AFBC depth/stencil buffers, so
> conceptually there is no change here, but we follow the style of the
> previous patch to improve robustness and clarity.
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> src/
uct panfrost_context *ctx,
> struct panfrost_resource
> rsrc->bo->has_checksum = true;
> }
>
> +static unsigned
> +panfrost_sfbd_format_for_surface(struct pipe_surface *surf)
> +{
> +/* TODO */
> +return 0xb84e0281; /* RGB32, no MSAA */
C
On Sun, 10 Mar 2019 at 07:50, Alyssa Rosenzweig wrote:
>
> With a unified layout field, we can specify the logic for BO layout
> explicitly, deciding between linear/tiled/AFBC based on the specified
> usage/binding flags.
>
> Signed-off-by: Alyssa Rosenzweig
Great stuff!
Reviewed-by: Tomeu Vizoso
On Sun, 10 Mar 2019 at 07:50, Alyssa Rosenzweig wrote:
>
> Previously, linear BOs shared memory with each other to minimize kernel
> round-trips / latency, as well as to work around a bug in the free_slab
> function. These concerns are invalid now, but c
Reviewed-by: Tomeu Vizoso
On Sun, 10 Mar 2019 at 07:50, Alyssa Rosenzweig wrote:
>
> This combination has not yet been seen "in the wild" in traces, but to
> support linear depth FBOs, ~bruteforce reveals this bit pattern is
> necessary. It's not yet clear why the
One more brick in the wall :)
Reviewed-by: Tomeu Vizoso
On Sun, 10 Mar 2019 at 07:50, Alyssa Rosenzweig wrote:
>
> The fragment_extra structure contains additional fields extending the
> MRT framebuffer descriptor, snuck in between the main framebuffer
> descriptor and the render
So we can free it later.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_resource.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index d647f618ee77..2fa468b177b9
So we can unmap it later.
Signed-off-by: Tomeu Vizoso
---
include/drm-uapi/panfrost_drm.h| 1 -
src/gallium/drivers/panfrost/pan_drm.c | 10 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/include/drm-uapi/panfrost_drm.h b/include/drm-uapi/panfrost_drm.h
index
Two ioctls had wrong DRM_IO* flags.
Signed-off-by: Tomeu Vizoso
---
include/drm-uapi/panfrost_drm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm-uapi/panfrost_drm.h b/include/drm-uapi/panfrost_drm.h
index a0ead4979ccc..508b9621d9db 100644
--- a/include/drm
If info->index_size is zero, info->index will point to uninitialized
memory.
Fatal signal 11 (SIGSEGV), code 2, fault addr 0xab5d07a3 in tid 20456
(surfaceflinger)
Signed-off-by: Tomeu Vizoso
Cc: etna...@lists.freedesktop.org
Cc: Marek Olšák
Fixes: 330d0607ed60 ("gall
On 05/29/2017 02:47 PM, Lucas Stach wrote:
> Hi Tomeu,
>
> Am Freitag, den 19.05.2017, 12:40 +0200 schrieb Tomeu Vizoso:
>> If info->index_size is zero, info->index will point to uninitialized
>> memory.
>>
>> Fatal signal 11 (SIGSEGV), cod
Hi,
I'm still trying to estimate the work required to support OpenCL on
Freedreno, and as part of that I have given a try to put Khronos'
LLVM-SPIRV into a shape that Mesa can depend on:
https://gitlab.collabora.com/tomeu/llvm-spirv
I basically took Khronos' master branch, rewrote history to
As the comments say, we don't have a way of knowing for sure that they
will be only read, so mark them as written.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/freedreno/freedreno_draw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/free
Some fprintfs were probably left unintentionally a few years ago and are
a bit of a nuisance.
Signed-off-by: Tomeu Vizoso
Cc: Signed-off-by: Rob Herring
Fixes: 2d3301e4d513 ("virgl: fix reference counting of prime handles")
---
src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 2
On 31 May 2018 at 00:25, Eric Anholt wrote:
> Tomeu Vizoso writes:
>
>> Virgl could save a lot of work converting buffers in the host side
>> between formats if Mesa supported a bunch of other formats when reading
>> pixels.
>>
>> This commit adds cases to
Anholt)
Signed-off-by: Tomeu Vizoso
Reviewed-by: Gurchetan Singh
---
src/mesa/main/framebuffer.c | 79 ++---
1 file changed, 47 insertions(+), 32 deletions(-)
diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 3ec8b91eaa2c..8e09620966cf 1
On 18 June 2018 at 23:19, Marek Olšák wrote:
> What about non-sRGB formats?
Only sRGB formats get unpacked to BGRA currently, so I don't need to
do anything about the others.
Thanks,
Tomeu
> Marek
>
> On Wed, May 23, 2018 at 4:54 AM, Tomeu Vizoso
> wrote:
>>
>
On 06/20/2018 02:57 PM, emil.veli...@collabora.com wrote:
Hi Tomeu,
On Wed, May 23, 2018 at 10:54:06AM +0200, Tomeu Vizoso wrote:
--- a/src/mesa/main/texcompress_etc.h
+++ b/src/mesa/main/texcompress_etc.h
@@ -28,6 +28,7 @@
#include "glheader.h"
#include "texcompres
B so these drivers can avoid a
conversion copy.
Signed-off-by: Tomeu Vizoso
---
src/mesa/state_tracker/st_format.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 418f5342025c..16e5d962a
ag to _mesa_unpack_etc2_format so callers can
specify the optimal component order.
In Gallium's case, it will be requested if the format isn't in
PIPE_FORMAT_B8G8R8A8_SRGB format.
For i965, it will remain GL_BGRA, as before.
v2: * Remove unnecesary include (Emil Velikov)
Signed-off-by: Tomeu Vizoso
and PIPE_FORMAT_R8G8B8A8_SRGB, as well.
The reason for this is that when Virgl runs with GLES on the host, it
cannot directly upload textures in BGRA.
So to avoid a conversion step, consider the RGB sRGB formats as well for
this extension.
Signed-off-by: Tomeu Vizoso
---
src/mesa
GLES3.functional.fbo.color.clear.*, when using virgl in the guest
side.
Signed-off-by: Tomeu Vizoso
---
src/mesa/main/framebuffer.c | 73 -
1 file changed, 64 insertions(+), 9 deletions(-)
diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
GLES3.functional.fbo.color.clear.*, when using virgl in the guest
side.
Additionally, assert that those functions' result match
_mesa_format_matches_format_and_type, so both functions are kept in
sync.
Signed-off-by: Tomeu Vizoso
v2: * Let R10G10B10A2_UINT fall back to GL_RGBA_INTEGER (E
e CI comes soon to save us all.
v2: * Let R10G10B10A2_UINT fall back to GL_RGBA_INTEGER (Eric Anholt)
* Assert with _mesa_format_matches_format_and_type (Eric Anholt)
v3: * Remove the assert, as it won't be reliable (Eric Anholt)
Signed-off-by: Tomeu Vizoso
---
src/mesa/main/fra
and PIPE_FORMAT_R8G8B8A8_SRGB, as well.
The reason for this is that when Virgl runs with GLES on the host, it
cannot directly upload textures in BGRA.
So to avoid a conversion step, consider the RGB sRGB formats as well for
this extension.
Signed-off-by: Tomeu Vizoso
---
src/mesa
B so these drivers can avoid a
conversion copy.
Signed-off-by: Tomeu Vizoso
---
src/mesa/state_tracker/st_format.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 418f5342025c..16e5d962a
ag to _mesa_unpack_etc2_format so callers can
specify the optimal component order.
In Gallium's case, it will be requested if the format isn't in
PIPE_FORMAT_B8G8R8A8_SRGB format.
For i965, it will remain GL_BGRA, as before.
Signed-off-by: Tomeu Vizoso
---
src/mesa/drivers/dri/i965/intel_mip
On 09/14/2018 04:42 PM, Gert Wollny wrote:
Am Freitag, den 14.09.2018, 15:26 +0300 schrieb andrey simiklit:
[...]
+ if (vcmd == VCMD_TRANSFER_PUT2)
+ vtest_hdr[VTEST_CMD_LEN] += data_size + 3 / 4;
Looks like a copy/paste mistake)
I suppose that it is should be like:
... = (data_size + 3
uffer references in
compiled_framebuffer_state to avoid confusion.
The leak can be reproduced with a client that continuously creates and
destroys contexts.
Signed-off-by: Tomeu Vizoso
Reported-by: Sjoerd Simons
---
src/gallium/drivers/etnaviv/etnaviv_context.c | 10 ++
src/gallium/dr
On 01/24/2018 12:03 AM, Karol Herbst wrote:
On Tue, Jan 23, 2018 at 11:46 PM, Francisco Jerez wrote:
Pierre Moreau writes:
On 2018-01-23 — 14:02, Francisco Jerez wrote:
Karol Herbst writes:
there seem to be some patches missing?
On Tue, Jan 23, 2018 at 1:33 AM, Pierre Moreau wrote:
*
On 24 January 2018 at 08:19, Tomeu Vizoso wrote:
> On 01/24/2018 12:03 AM, Karol Herbst wrote:
>>
>> On Tue, Jan 23, 2018 at 11:46 PM, Francisco Jerez
>> wrote:
>>>
>>> Pierre Moreau writes:
>>>
>>>> On 2018-01-23 — 14
On 10/4/18 7:48 PM, Gurchetan Singh wrote:
On Thu, Oct 4, 2018 at 7:41 AM Gert Wollny wrote:
From: Tomeu Vizoso
Pass the size of a resource when creating it so a backing can be kept in
the other side.
Also pass the required offset to transfer commands.
This moves vtest closer to how
Reviewed-by: Tomeu Vizoso
On 14 August 2018 at 07:40, Dave Airlie wrote:
> ping?
> On Wed, 8 Aug 2018 at 08:46, Dave Airlie wrote:
>>
>> From: Dave Airlie
>>
>> ---
>> src/gallium/drivers/virgl/virgl_context.c | 9 +++--
>> src/gallium/drivers/v
On Mon, 24 Jun 2019 at 12:00, Rohan Garg wrote:
>
> > I think assertions should be limited to the most basic of sanity checks,
> > and the other asserts replaced by proper error handling.
>
> So, should I leave it as is and let us hit assertions that we fix?
Sorry, can you rephrase?
Thanks,
Tom
Arm's kernel driver mentions how to decode this field, which makes a bit
clearer what had happened.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pandecode/decode.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pand
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pandecode/decode.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pandecode/decode.c
b/src/gallium/drivers/panfrost/pandecode/decode.c
index 7f58ad033669..d468e10140b7 100644
--- a
Then we can get some information back about any exception that might
have happened.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_drm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_drm.c
b/src/gallium/drivers
When the fault_pointer field in the header is set, we can get some idea
of which descriptor the HW isn't happy with if we know their addresses.
Signed-off-by: Tomeu Vizoso
---
.../drivers/panfrost/pandecode/decode.c | 24 +--
1 file changed, 11 insertions(+), 13 dele
> + * © Copyright2019 Collabora, Ltd.
Patch looks good to me, but please add the space missing above.
Reviewed-by: Tomeu Vizoso
Thanks,
Tomeu
> *
> * Permission is hereby granted, free of charge, to any person obtaining a
> * copy of this software and associated document
Panfrost has grown and doesn't leak as much as before.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/deqp-runner.sh | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/panfrost/ci/deqp-runner.sh
b/src/gallium/drivers/panfro
These changes will make sure we get the right image from the container
registry.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/gitlab-ci.yml | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/ci/gitlab-ci.yml
b/src
As there's lots of them and Gitlab struggles rendering logs with so many
lines.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/debian-install.sh | 2 +-
src/gallium/drivers/panfrost/ci/gitlab-ci.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Rendering to AFBC was broken, as the HW will complaint loudly if we pass
a tagged pointer in bifrost_render_target.
Signed-off-by: Tomeu Vizoso
Fixes: 3609b50a6443 ("panfrost: Merge AFBC slab with BO backing")
---
src/gallium/drivers/panfrost/pan_context.c | 8 +++-
src/galli
Besides the leak, I think I preferred the open-coded version, which is
incidentally what all other drivers I've seen do. The modifiers work
is going to massively change this code anyway.
But I'm not against it, so
Reviewed-by: Tomeu Vizoso
Cheers,
Tomeu
On Tue, 2 Jul 2019 at 15
On Tue, 2 Jul 2019 at 15:24, Boris Brezillon
wrote:
>
> Let's keep a clear split between ioctl wrappers and the rest of the
> driver. All the import BO function need is a dmabuf FD and the screen
> object, and the export one should only take care of generating a dmabuf
> FD out of a BO object. Win
rost area right now, and some
> of what I'm proposing here might be irrelevant or might have to be
> ported on top of other changes (which is fine). Let me know if that's
> the case.
Looks great to me, will be a pleasure to rebase my modifiers work on
top of this.
Reviewed-by:
On Tue, 2 Jul 2019 at 15:24, Boris Brezillon
wrote:
>
> There's no point duplicating the code, and it will help us simplify
> the bo_handles[] filling logic in panfrost_drm_submit_job().
Looks good but, could we drop panfrost_memory completely? Other
drivers seem to do fine wthout such a thing.
On Tue, 2 Jul 2019 at 17:02, Boris Brezillon
wrote:
>
> On Tue, 2 Jul 2019 16:54:22 +0200
> Tomeu Vizoso wrote:
>
> > On Tue, 2 Jul 2019 at 15:24, Boris Brezillon
> > wrote:
> > >
> > > There's no point duplicating the code, and it will help us s
In that case, ctx->pipe_framebuffer.cbufs[0] can be NULL.
Signed-off-by: Tomeu Vizoso
Cc: Boris Brezillon
Fixes: 5375d009be18 ("panfrost: Pass referenced BOs to the SUBMIT ioctls")
---
src/gallium/drivers/panfrost/pan_drm.c | 10 ++
1 file changed, 6 insertions(+), 4 delet
e last job is done with it.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_allocate.h | 2 +-
src/gallium/drivers/panfrost/pan_drm.c | 46 +++--
src/gallium/drivers/panfrost/pan_resource.c | 20 -
src/gallium/drivers/panfrost/pan_screen.h | 6 ++
In preparation for using AFBC for BOs that could be scanned out (though
they are likely to be only shared with the compositor for now), use the
buffer allocation UABI of the GPU driver, as dumb buffers cannot be
allocated for AFBC.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost
ts it.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_drm.c | 1 +
src/gallium/drivers/panfrost/pan_resource.c | 74 ++---
src/gallium/drivers/panfrost/pan_screen.c | 37 +++
src/gallium/drivers/panfrost/pan_util.h | 7 ++
4 files changed
On Thu, 4 Jul 2019 at 10:05, Tomeu Vizoso wrote:
>
> Implement query_dmabuf_modifiers and resource_create_with_modifiers so
> Wayland clients can share AFBC buffers with the compositor.
>
> For now this is guarded behind the PAN_MESA_DEBUG=modifiers env var
> because implementi
This was stale code that was causing a SIGSEGV when using SFBD, as we
stopped creating the corresponding BO.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.h | 1 -
src/gallium/drivers/panfrost/pan_sfbd.c| 6 --
2 files changed, 4 insertions(+), 3 deletions
This was stale code that was causing a SIGSEGV when using SFBD, as we
stopped creating the corresponding BO.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.h | 1 -
src/gallium/drivers/panfrost/pan_sfbd.c| 8 ++--
2 files changed, 6 insertions(+), 3 deletions
Patches 8 to 11 look good to me:
Reviewed-by: Tomeu Vizoso
Thanks,
Tomeu
On 7/10/19 3:24 PM, Alyssa Rosenzweig wrote:
A lot of the pan_screen.c code was cargoculted from other drivers. The
upshot is that we return true for a lot of PIPE_CAPs that we don't
actually support, resulting
In the mali_single_framebuffer descriptor.
Signed-off-by: Tomeu Vizoso
v2: Remove unwanted chunks
---
src/gallium/drivers/panfrost/pan_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost
In the mali_single_framebuffer descriptor.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 12
src/gallium/drivers/panfrost/pan_tiler.c | 12
src/gallium/drivers/panfrost/pan_tiler.h | 6 --
3 files changed, 20 insertions(+), 10
Fixes this assertion:
../mesa/src/panfrost/midgard/midgard_schedule.c:507:schedule_block: Assertion
`ins == __next && "use _safe iterator"' failed.
Trace/breakpoint trap
Signed-off-by: Tomeu Vizoso
---
src/panfrost/midgard/midgard_schedule.c | 2 +-
1 file changed, 1 i
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/debian-install.sh | 4 ++--
src/gallium/drivers/panfrost/ci/gitlab-ci.yml | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/ci/debian-install.sh
b/src/gallium/drivers/panfrost
Some hash functions (eg. key_u64_hash) will attempt to dereference the
key, causing an invalid access when passed DELETED_KEY_VALUE (0x1) or
FREED_KEY_VALUE (0x0).
The entry.hash field isn't needed by the delete_function, so just stop
populating it.
Signed-off-by: Tomeu Vizoso
Cc: S
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_drm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_drm.c
b/src/gallium/drivers/panfrost/pan_drm.c
index 122bc5f3db36..46cceb808919 100644
--- a/src/gallium/drivers
table).
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_allocate.h | 2 +
src/gallium/drivers/panfrost/pan_assemble.c | 5 ++-
src/gallium/drivers/panfrost/pan_blend.h | 11 --
src/gallium/drivers/panfrost/pan_blend_cso.c | 39 ++-
.../drivers/pan
Unless a BO has the EXECUTABLE flag, mark it as NOEXEC.
Signed-off-by: Tomeu Vizoso
---
include/drm-uapi/panfrost_drm.h | 27 +++
src/gallium/drivers/panfrost/pan_drm.c| 7 +-
src/gallium/drivers/panfrost/pan_screen.c | 12 ++
src/gallium/drivers
eeded.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_drm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_drm.c
b/src/gallium/drivers/panfrost/pan_drm.c
index a3f35aed4d0f..122bc5f3db36 100644
--- a/src/gallium/dr
1 - 100 of 215 matches
Mail list logo
