Previously, we advertised the extension but the builtin functions
were enabled only for GLSL and not for ES.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52003
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
.../profiles
On Mon, Jul 23, 2012 at 4:30 PM, Tomeu Vizoso to...@tomeuvizoso.net wrote:
On Mon, Jul 16, 2012 at 8:45 PM, Tomeu Vizoso to...@tomeuvizoso.net wrote:
Previously, we advertised the extension but the builtin functions
were enabled only for GLSL and not for ES.
Bugzilla: https
---
src/egl/drivers/dri2/egl_dri2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 423d18d..a6ee9e1 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -481,7 +481,8 @@
On Sat, Aug 18, 2012 at 5:20 AM, Ian Romanick i...@freedesktop.org wrote:
On 08/17/2012 10:08 AM, Paulo Alcantara wrote:
The segmentation fault occurs when DRI2 is not loaded up and
dri2_setup_screen() function deferences dri2_dpy-dri2 (since it's NULL
at this point).
This patch fixes the
instead of just for GL and ES1.
---
src/mesa/main/get.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 24d2a18..e40569d 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -536,6 +536,11 @@ static const
On Tue, Sep 11, 2012 at 5:00 PM, Kenneth Graunke
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Could you please push it for me? I'm not a committer yet.
Forgot to add my s-o-b to the commit:
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
Thanks,
Tomeu
On Tue, Sep 11, 2012 at 5:34 PM, Tomeu Vizoso to...@tomeuvizoso.net wrote:
On Tue, Sep 11, 2012 at 5:00 PM, Kenneth Graunke
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Could you please push it for me? I'm not a committer yet.
Forgot to add my s-o-b to the commit:
Signed-off
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 <tomeu.viz...@collabora.com>
Cc: etna...@lists.freedesktop.org
Cc: Marek Olšák <mare
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
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 <tomeu.viz...@collabora.com>
---
src/gallium/drivers/freedreno/freedreno_draw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
.functional.fbo.color.clear.*, when using virgl in the guest
side.
Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
---
src/mesa/main/framebuffer.c | 73 -
1 file changed, 64 insertions(+), 9 deletions(-)
diff --git a/src/mesa/main/framebuffer.c b/sr
.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 <tomeu.viz...@collabora.com>
v2: * Let R10G10B10A2_UINT fal
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 <tomeu.viz...@collabora.com>
---
sr
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 <tomeu.viz...@collabora.
these drivers can avoid a
conversion copy.
Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
---
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
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 <tomeu.viz...@collabora.com>
---
src/mesa/drivers/dr
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
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
On 24 January 2018 at 08:19, Tomeu Vizoso <tomeu.viz...@collabora.com> wrote:
> On 01/24/2018 12:03 AM, Karol Herbst wrote:
>>
>> On Tue, Jan 23, 2018 at 11:46 PM, Francisco Jerez <curroje...@riseup.net>
>> wrote:
>>>
>>> Pierre Moreau <pierre.
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
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 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
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:
>>
>>
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..16e5d962a894 100644
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
---
src/mesa
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
-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 100644
--- a/src
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
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
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/drivers
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 +
any more (and
if so, I can always go back in time).
Reviewed-by: Tomeu Vizoso
Thanks!
Tomeu
Signed-off-by: Alyssa Rosenzweig
Cc: Tomeu Vizoso
Cc: Rob Herring
---
src/gallium/drivers/panfrost/.gitignore| 1 -
src/gallium/drivers/panfrost/meson.build | 10
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_drm.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_drm.c
b/src/gallium/drivers/panfrost/pan_drm.c
index f4580da9f509..0a7cf47c6a36 100644
--- a/src/gallium
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 d242c3f90cea..c513791615ea 100644
--- a/src/gallium/drivers/panfrost
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_drm.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_drm.c
b/src/gallium/drivers/panfrost/pan_drm.c
index 887bf19148e7..c30beaf2b500 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_drm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_drm.c
b/src/gallium/drivers/panfrost/pan_drm.c
index 0a7cf47c6a36..887bf19148e7 100644
--- a/src/gallium
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pandecode/cmdline.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pandecode/cmdline.c
b/src/gallium/drivers/panfrost/pandecode/cmdline.c
index b2ba21cfe414..07bffdb5c493 100644
On Fri, 29 Mar 2019 at 02:48, Alyssa Rosenzweig wrote:
>
> Fixes crash in dEQP-GLES2.functional.buffer.*
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> src/gallium/drivers/panfrost/pan_context.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git
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
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
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
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
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
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;
-
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
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
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
> suboptimal
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
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
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
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
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_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
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
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
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, bu
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/panfros
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:
>
> 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 m
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
> ---
>
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:
>
> 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!
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
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
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 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
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
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pandecode/mmap.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pandecode/mmap.h
b/src/gallium/drivers/panfrost/pandecode/mmap.h
index 1a208336e814..e9acae877f7f 100644
--- a/src
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_swizzle.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_swizzle.c
b/src/gallium/drivers/panfrost/pan_swizzle.c
index 291bd1f88aea..52a907ddd55d 100644
--- a/src/gallium/drivers/panfrost
Since last Friday, these two tests have been fixed:
dEQP-GLES2.functional.shaders.functions.control_flow.return_in_nested_loop_fragment
dEQP-GLES2.functional.shaders.linkage.varying_7
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/expected-failures.txt | 2 --
1 file changed
As with the previous value of 5000 we seemed to be reaching OOM in some
circumstances.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/deqp-runner.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/ci/deqp-runner.sh
b/src/gallium
.
Suggested-by: Rob Clark
Signed-off-by: Alyssa Rosenzweig
Cc: Tomeu Vizoso
This is a great cleanup, thanks!
Reviewed-by: Tomeu Vizoso
Cheers,
Tomeu
---
.../drivers/panfrost/include/panfrost-job.h | 8 +--
src/gallium/drivers/panfrost/pan_context.c| 54 +++
src
The compiler configuration was hardened to fail on format warnings and
things stopped building.
Fixes: c9c1e2610647 ("mesa: prevent common string formatting security issues")
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/bifrost/disassemble.c | 2 +-
1 file changed, 1
On Tue, 28 May 2019 at 08:17, Tomeu Vizoso wrote:
>
> On 5/26/19 1:51 AM, Alyssa Rosenzweig wrote:
> > The mesa/st flips the viewport, so we respect that rather than
> > trying to flip the framebuffer itself and ignoring the viewport and
> > using a messy heuristic.
>
On 6/6/19 6:10 PM, Michel Dänzer wrote:
On 2019-05-20 11:33 a.m., Tomeu Vizoso wrote:
Jump over the container stage if we haven't changed any of the files
that involved in building the container images.
This saves 1-2 minutes in each run and helps conserve resources.
Signed-off-by: Tomeu
On Fri, 7 Jun 2019 at 09:51, Eduardo Lima Mitev wrote:
>
> On 5/20/19 11:33 AM, Tomeu Vizoso wrote:
> > Signed-off-by: Tomeu Vizoso
> > ---
> > src/gallium/drivers/panfrost/ci/Dockerfile | 7 +++
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
Use the infrastructure in wayland/ci-templates to build the container
images.
This prevents from getting into some situations in which the images
wouldn't be rebuilt, and allows us to share some infrastructure with
other projects in freedesktop.org.
Signed-off-by: Tomeu Vizoso
Suggested
-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/meson.build | 1 -
src/gallium/drivers/panfrost/pan_context.c | 91 +-
src/gallium/drivers/panfrost/pan_wallpaper.c | 274 ---
src/gallium/drivers/panfrost/pan_wallpaper.h | 33 ---
4 files changed, 88 insertions
And instead, link them as they are added.
Makes things a bit clearer and prepares future work such as FB reload
jobs.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 120 +
src/gallium/drivers/panfrost/pan_context.h | 2 +-
2 files changed, 54
On Wed, 29 May 2019 at 17:10, Alyssa Rosenzweig wrote:
>
> Does this address the issues with the previous version raised on IRC? In
> particular:
>
> Does mpv work? (Including the on-screen display)
> Does sway work?
Have never tested those, tbh. Do you know if I should be able
On Wed, 29 May 2019 at 17:37, Alyssa Rosenzweig wrote:
>
> > Have never tested those, tbh. Do you know if I should be able to test
> > those with whatever is packaged for Debian?
>
> I don't think sway isn't packaged in testing yet (I think it's in
> experimental)? mpv is definitely packaged; you
Any ideas on why these two changes get kmscube working on T720?
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost
We hadn't updated the kernel header after the driver got into mainline.
Signed-off-by: Tomeu Vizoso
---
include/drm-uapi/panfrost_drm.h| 6 --
src/gallium/drivers/panfrost/pan_drm.c | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/drm-uapi
On Tue, 18 Jun 2019 at 17:00, Alyssa Rosenzweig
wrote:
>
> Now that sRGB formats are supported for both rendering and sampling,
> advertise support.
>
> Signed-off-by: Alyssa Rosenzweig
Hi there,
this patch seems to have caused the following regressions:
Hi there,
this patch seems to have caused the following regressions:
+dEQP-GLES2.functional.shaders.conversions.vector_combine.bvec2_float_to_bvec3_fragment
+dEQP-GLES2.functional.shaders.conversions.vector_combine.float_bool_to_bvec2_fragment
1 - 100 of 214 matches
Mail list logo