ut missing a better name I left it as-is.
Signed-off-by: Lucas Stach
---
v2: fix invalid vreg assignment
---
src/gallium/drivers/etnaviv/etnaviv_compiler.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_compile
It turned out not to be a hardware bug, but the shader compiler
emitting wrong varying component use information. With that fixed
we can turn flat shading back on.
Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
---
src/gallium/drivers/etnaviv/etnaviv_rasterizer.c | 6 +-
1 file
Am Dienstag, den 19.09.2017, 10:30 +0200 schrieb Philipp Zabel:
> On Fri, 2017-09-15 at 18:04 +0200, Lucas Stach wrote:
> > It seems that newer cores don't use the PA_ATTRIBUTES to decide if the
> > varying should bypass the flat shading, but derive this from the
> > com
Am Dienstag, den 19.09.2017, 16:24 +0200 schrieb Wladimir J. van der
Laan:
> On Fri, Sep 15, 2017 at 06:00:52PM +0200, Lucas Stach wrote:
> > The RS can blit abitrary tile aligned subregions of a resource by
> > adjusting the buffer offset.
>
> Thanks for doing this.
ces, other 16bpp
formats seem to work fine.
Fixes: d6aa2ba2b2 (etnaviv: replace translate_clear_color with util_pack_color)
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
It turned out not to be a hardware bug, but the shader compiler
emitting wrong varying component use information. With that fixed
we can turn flat shading back on.
Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
Reviewed-by: Wladimir J. van der Laan
---
src/gallium/drivers/etnaviv
ut missing a better name I left it as-is.
Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
Reviewed-by: Wladimir J. van der Laan
---
v2: fix invalid vreg assignment
v3: fix missed negation, improve variable naming
---
src/gallium/drivers/etnaviv/etnaviv_compiler.c | 22 ++--
The RS can blit abitrary tile aligned subregions of a resource by
adjusting the buffer offset.
Signed-off-by: Lucas Stach
---
v2:
- add asserts, so we catch any invalid use of the RS
- split out tile mask computation, to make it easier to read the code
---
src/gallium/drivers/etnaviv
subregion of the
resource, which the transfer is going to change.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_transfer.c | 29 ++
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
b/src/gallium
This is useful if we only need to copy part of a larger resource, mostly
when using the RS engine to de-/tile on pipe transfers.
Signed-off-by: Lucas Stach
Reviewed-by: Wladimir J. van der Laan
---
src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 27
src/gallium
Hi Wladimir,
Am Dienstag, den 26.09.2017, 16:20 +0200 schrieb Wladimir J. van der
Laan:
> Hello Lucas,
>
> On Fri, Sep 22, 2017 at 11:27:36AM +0200, Lucas Stach wrote:
> > It seems that newer cores don't use the PA_ATTRIBUTES to decide if
> > the
> > varying sho
te issue on GC3000 and doesn't seem to regress
on older cores, so:
Tested-by: Lucas Stach
> ---
> src/gallium/drivers/etnaviv/etnaviv_context.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c
> b/
The logic to decide if we need to flush the GPU command stream was broken
and hard to reason about. Fix and clarify this.
Fixes the data sync subtests from piglit arb_vertex_buffer_object.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_transfer.c | 15 ++-
1
Now that the real meaning of the 2 bits in PA_SYSTEM_MODE is known,
we can set them according to the rasterizer state, which fixes uses
that are setting provoking vertex first.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_rasterizer.c | 3 +-
src/gallium/drivers/etnaviv
Am Sonntag, den 01.10.2017, 12:46 +0200 schrieb Christian Gmeiner:
> 2017-09-26 12:29 GMT+02:00 Wladimir J. van der Laan :
> > Set up new states that the blob started setting for GC3000 consistently.
> >
> > This makes sure that when another test or driver leaves the GPU in
> > unpredictable state
Am Donnerstag, den 28.09.2017, 13:47 +0200 schrieb Lucas Stach:
> Hi Wladimir,
>
> Am Dienstag, den 26.09.2017, 16:20 +0200 schrieb Wladimir J. van der
> Laan:
> > Hello Lucas,
> >
> > On Fri, Sep 22, 2017 at 11:27:36AM +0200, Lucas Stach wrote:
> > >
om the TS.
>
> This is the same as the blob does and potentially saves significant
> bandwidth when doing i.MX6qp scanout using PRE, and when rendering to
> textures (though here using sampler TS would be even better).
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Lucas S
Am Dienstag, den 10.10.2017, 13:57 +0200 schrieb Lucas Stach:
> Am Samstag, den 30.09.2017, 10:11 +0200 schrieb Wladimir J. van der
> Laan:
> > If an RS blit is done with source exactly the same as destination,
> > and
> > the hardware supports this, do an in-place resolve
tests using the st_draw path.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_compiler.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
index e2b906c2f6a5..41ab4031f6c5
TS_MEM_CONFIG
must be updated before each draw if the status has changed.
This fixes the remaining TS related piglit failures (regressions of a
standard run against a piglit run with TS completely disabled).
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 5 +--
src
Am Sonntag, den 26.03.2017, 16:13 +0200 schrieb Christian Gmeiner:
> If we render to rb swapped format we will create a shader variant doing
> the involved swizzing in the pixel shader.
>
> Signed-off-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_compiler.c | 17 +
Am Sonntag, den 26.03.2017, 16:13 +0200 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner
s/adopt/adapt in the subject
Reviewed-by: Lucas Stach
> ---
> src/gallium/drivers/etnaviv/etnaviv_shader.c | 30
> ++--
> 1 file changed, 15 in
Am Sonntag, den 26.03.2017, 16:13 +0200 schrieb Christian Gmeiner:
> If shader-db run, create a standard variant immediately
> (as otherwise nothing will trigger the shader to be
> actually compiled).
>
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
>
Am Sonntag, den 26.03.2017, 16:13 +0200 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 4 +-
> src/gallium/drivers/etnaviv/etnaviv_compiler.c | 4 +-
> src/gallium/drivers/etnaviv/etnaviv_compiler.h | 2 +
> ..
ated
> variant into etna_compile_shader(..). This saves us from passing
> extra ptrs everywhere.
>
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> src/gallium/drivers/etnaviv/etnaviv_compiler.c | 53
> +++---
> src/gallium/drivers/etnaviv/etn
Am Sonntag, den 26.03.2017, 16:13 +0200 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 4 ++--
> src/gallium/drivers/etnaviv/etnaviv_context.h| 9 +
> src/gallium/
Am Sonntag, den 26.03.2017, 16:13 +0200 schrieb Christian Gmeiner:
> This commit adds some basic infrastructure to handle shader
> variants. We are still creating exactly one shader variant
> for each shader.
>
> Signed-off-by: Christian Gmeiner
Nitpick inline, othwerwise:
Rev
From: Philipp Zabel
Before resolving a resource into its scanout prime buffer, check that
the prime resource is actually older. If it is not, the resolve is an
expensive no-op, and we better skip it.
Signed-off-by: Philipp Zabel
---
src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 5 -
1
renderable resource.
lst: Add seqno tracking, to skip flush when not needed.
Fixes: aadcb5e94b35 ("etnaviv: enable TS, but disable autodisable")
Signed-off-by: Philipp Zabel
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 3 +++
src/gallium/drive
Hi Marek,
thanks for the review.
Am Samstag, den 26.05.2018, 00:36 -0400 schrieb Marek Olšák:
[...]
>
> > @@ -983,7 +760,7 @@ dri2_update_tex_buffer(struct dri_drawable *drawable,
> >
> > static __DRIimage *
> > dri2_create_image_from_winsys(__DRIscreen *_screen,
> > -
Am Dienstag, den 01.05.2018, 16:48 +0200 schrieb Christian Gmeiner:
> The binary blob driver supports 'multi layer' formats. For
> instance: gcvSURF_A16B16G16R16F_2_A8R8G8B8
> < format >_n_< base format >
Sort of high-level comment, but to me the usage of the term layer for
th
Am Dienstag, den 01.05.2018, 16:48 +0200 schrieb Christian Gmeiner:
> With the help of the number of layers we can choose the correct
> RS clear format - like the binary blob does.
>
> Signed-off-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_rs.c | 3 ++-
> 1 file changed, 2
Am Mittwoch, den 16.05.2018, 15:31 +0200 schrieb Christian Gmeiner:
> Currently GLSL 1.4 is defined for all gallium drivers even only
> GLSL 1.2 is supported as seen on etnaviv.
>
> Fixes 4560aad780b ("mesa: add GLSLVersionCompat constant")
>
> > Signed-off-by: Christian Gmeiner
> ---
> src/mes
Am Mittwoch, den 16.05.2018, 16:02 +0200 schrieb Christian Gmeiner:
> Currently GLSL 1.4 is defined for all gallium drivers even only
> GLSL 1.2 is supported as seen on etnaviv.
>
> v1 -> v2:
> - use _min(..) as suggested by Lucas Stach and Michel Dänzer
>
> Fixes
t for drivers using the
sampler rewrite (though I think I've covered all cases) I would appreciate
some testing from the Freedreno folks, or whoever cares about this.
Regards,
Lucas
Lucas Stach (2):
st/dri: allow both render and sampler compatible dma-buf formats
st/dri: replace format
the different representations.
Also this now stores all the known representations in the __DRIimageRec,
to avoid the loss of information we currently have when importing a buffer
with a fourcc, which doesn't have a corresponding dri format.
Signed-off-by: Lucas Stach
---
src/ga
image APIs it
doesn't distinguish between render or sampler compatible formats. So
this patch aligns behavior between Intel and Gallium based drivers.
Signed-off-by: Lucas Stach
---
src/gallium/state_trackers/dri/dri2.c | 29 +--
1 file changed, 18 insertions(+
Hi Christian,
Am Dienstag, den 05.06.2018, 17:43 +0200 schrieb Christian Gmeiner:
> Am Di., 5. Juni 2018 um 16:40 Uhr schrieb Philipp Zabel
> > :
> >
> > Hi!
> >
> > we have been interested in NIR support for etnaviv for a while, for the
> > obvious reasons: gaining access to common optimization
Am Donnerstag, den 06.09.2018, 16:43 +0200 schrieb Lukas F. Hartmann:
> Hi,
>
> I've updated to and rebuilt the latest git versions of linux, drm, mesa
> and kmscube on an imx6qp system. I tried both with etnaviv as a module
> and compiled into the kernel (no difference).
>
> Mesa no longer picks
Hi Emil,
Am Freitag, den 07.09.2018, 10:52 +0100 schrieb Emil Velikov:
> Hi Lukas,
>
> Adding the etnaviv ML - people in there may have some tips.
>
> > On 6 September 2018 at 15:43, Lukas F. Hartmann wrote:
> > Hi,
> >
> > I've updated to and rebuilt the latest git versions of linux, drm, mes
Am Montag, den 01.10.2018, 18:37 +0200 schrieb Guido Günther:
> The later are sensitive to unalligned accesses on arm64[1] and we don't
> need an uncached mapping here.
>
> [1]: https://lists.freedesktop.org/archives/etnaviv/2018-September/001956.html
>
> > Signed-off-by: Guido Günther
> ---
>
Am Mittwoch, den 12.12.2018, 14:45 +0100 schrieb Christian Gmeiner:
> There is no need to have an extra ctx paramter as all the other
> parameters carry all the needed information.
>
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> src/galli
CPU time on rapidly freeing and reallocating color buffers
break those feedback loops by letting the unneeded buffers sit around for a
short while before disposing them.
Signed-off-by: Lucas Stach
---
src/egl/drivers/dri2/platform_wayland.c | 13 +
1 file changed, 9 insertions(+), 4
Am Dienstag, den 18.12.2018, 17:43 + schrieb Emil Velikov:
> > On Tue, 18 Dec 2018 at 11:16, Lucas Stach wrote:
> >
> > Currently we dispose any unneeded color buffers immediately if we detect
> > that
> > there are more unlocked buffers than we need. This c
We try to avoid sharing all resources with KMS side of renderonly, as this
adds some overhead that isn't really needed for most resources. If
someone tries to validate a resource for scanout, this is a good indication
that the sharing with the KMS side is actually needed.
Signed-off-by:
Take into account the render target format when checking if the color
mask affects all channels of the RT. This allows to enable full
override in a few cases where a non-alpha format is used.
Signed-off-by: Lucas Stach
---
v2: clarify comment
---
src/gallium/drivers/etnaviv/etnaviv_blend.c | 11
Some of the status variables in the compiler are only used in asserts
and thus may be unused in release builds. Annotate them accordingly
to avoid 'unused but set' warnings from the compiler.
Signed-off-by: Lucas Stach
---
v2: get rid of superfluous variable initialization
---
s
Hi Christian,
Am Freitag, den 28.12.2018, 11:04 +0100 schrieb Christian Gmeiner:
> Am Di., 18. Dez. 2018 um 19:09 Uhr schrieb Lucas Stach
> :
> >
> > We try to avoid sharing all resources with KMS side of renderonly, as this
> > adds some overhead that isn't really
Am Dienstag, den 20.02.2018, 20:47 +0100 schrieb Christian Gmeiner:
> Reduces size of struct etna_specs from 100 to 94 bytes.
>
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> src/gallium/drivers/etnaviv/etnaviv_internal.h | 2 +-
> 1 file changed,
Am Montag, den 05.03.2018, 23:26 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> src/gallium/drivers/etnaviv/etnaviv_query_sw.c | 30
> --
> src/gallium/drivers/etnaviv/etnaviv_query_sw.h | 5 +
Am Montag, den 05.03.2018, 23:26 +0100 schrieb Christian Gmeiner:
> This enables AMD_performance_monitor extension.
>
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> src/gallium/drivers/etnaviv/etnaviv_query.c | 13 +
> 1 file chan
Vivante hardware supports this just fine. There is no reason why this shouldn't
be advertised as a valid combination.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/et
Take into account the resource format, instead of applying a hardcoded
32bpp. This not only over-allocates 16bpp formats, but also results in
a wrong stride being filled into the handle.
Signed-off-by: Lucas Stach
---
src/gallium/auxiliary/renderonly/renderonly.c | 3 ++-
1 file changed, 2
Am Mittwoch, den 31.01.2018, 11:37 + schrieb Daniel Stone:
> On 30 January 2018 at 14:22, Lucas Stach
> wrote:
> > Take into account the resource format, instead of applying a
> > hardcoded
> > 32bpp. This not only over-allocates 16bpp formats, but also results
> &g
TS tiles map to a fixed amount of bytes in the color/depth surface,
so the blocksize of the format needs to be taken into account when
calculating the number of tiles to fill.
The simplest fix is to just use the layer stride, which is the surface
size in bytes.
Signed-off-by: Lucas Stach
This feature has caused some trouble already. Add a debug switch to
allow users to quickly check if a specific issue is caused by this
feature.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_debug.h | 1 +
src/gallium/drivers/etnaviv/etnaviv_screen.c | 3 +++
2 files
Some of the 16bit formats misrender with missing tiles with the current
"2" state. As all the previously working formats also work with the "3"
state, just always use that one.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_state.c | 2 +-
1 file change
Hi Carlos,
Am Freitag, den 09.02.2018, 19:26 +0100 schrieb Carlos Rafael Giani:
> Hi Daniel,
>
> thanks, I got it to work - almost. I am running this on the i.MX6
> with
> etnaviv. I do get some flickering, however.
>
> To test if something is wrong with the page flipping, I call
> drmGetCap()
From: Philipp Zabel
Signed-off-by: Philipp Zabel
---
src/gallium/drivers/etnaviv/etnaviv_resource.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index d70152e082dd..43
Those have been missed when the new parameter was introduced, leading to
incompatible pointer assignement warnings.
Fixes: 3132afdf4c12 (gallium/hud: pass pipe_context explicitly to most
functions)
CC:
Signed-off-by: Lucas Stach
---
src/gallium/auxiliary/hud/hud_cpufreq.c | 2 +-
src
Am Donnerstag, den 24.08.2017, 20:00 -0300 schrieb Fabio Estevam:
> Hi,
>
> Getting the following errors when running glmark2 terrain test on imx6q:
>
> # glmark2-es2-drm -b terrain
> ** Failed to set swap interval. Results may be bounded above by refresh rate.
> =
o stop the core from pushing the dirt into a precious real
render target, plug in dummy buffer when rendering without a color
buffer.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_context.c | 13 +
src/gallium/drivers/etnaviv/etnaviv_context.h | 3 +++
src/galli
Take into account the render target format when checking if the color
mask affects all channels of the RT. This allows to enable full
override in a few cases where a non-alpha format is used.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_blend.c | 7 +--
1 file changed
There is no need to do the detour over the resource behind the
surface to get the format. Use the surface format directly.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_blend.c | 2 +-
src/gallium/drivers/etnaviv/etnaviv_context.c | 9 ++---
2 files changed, 3
Some of the status variables in the compiler are only used in asserts
and thus may be unused in release builds. Annotate them accordingly
to avoid 'unused but set' warnings from the compiler.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_compiler.c | 8 --
Hi Guido,
Am Dienstag, den 09.10.2018, 13:50 +0200 schrieb Guido Günther:
> Hi,
> On Mon, Sep 17, 2018 at 04:06:57PM +0200, Guido Günther wrote:
> > etna_resource_alloc and etna_resource_from_handle currently use different
> > checks.
> > This leads to
> >
> > etna_resource_from_handle:492: t
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 | 2 +-
src/gallium/drivers/etnaviv/etnaviv_resource.h | 1 +
2 files
lease of this
series, which only worked on the i.MX6QP. With this series NV12 should work
on all supported Vivante GPUs.
Regards,
Lucas
[1] https://marc.info/?l=mesa3d-dev&m=152655423402505&w=2
[2] https://bugzilla.gnome.org/show_bug.cgi?id=783521
Lucas Stach (9):
etnaviv: improve PIP
isn't used for rendering.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_resource.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index 7fd374ae23d5..c17a170453
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
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
---
src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 2 +-
src/gallium/drivers
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 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
ngine on the 3D core.
Not the most efficient path, but at least gives us the same level of
functionality as on the newer GC320 cores and looks the same to the
application.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_2d.c | 194 +--
1 file changed, 177 in
We don't have a fallback to get them into a render/sampler compatible
layout (yet). Rejecting the import at least forwards this issue to the
client application, which might have a way to deal with this.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_resource.
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 | 166
When a EGLImage is newly bound to a texture, we need to make sure the
driver is informed that the resource might have changed. Fixes stale
texture content on Etnaviv when binding an existing EGLImage to an
existing texture object.
Signed-off-by: Lucas Stach
---
src/mesa/state_tracker
texture"
> Fixes: a37cf630b4d1 "gallium: add pipe_screen::resource_changed callback
> wrappers"
> Signed-off-by: Michel Dänzer
Urgh, thanks for fixing this up.
Reviewed-by: Lucas Stach
> ---
> src/gallium/auxiliary/driver_ddebug/dd_screen.c |
Hi,
Am Dienstag, dem 27.04.2021 um 09:26 -0400 schrieb Marek Olšák:
> Ok. So that would only make the following use cases broken for now:
> - amd render -> external gpu
> - amd video encode -> network device
FWIW, "only" breaking amd render -> external gpu will make us pretty
unhappy, as we have
Am Montag, dem 22.11.2021 um 13:01 +0100 schrieb Christian König:
> Hi guys,
>
> Am 22.11.21 um 06:49 schrieb Dave Airlie:
> > On Thu, 18 Nov 2021 at 18:45, Sil Vilerino
> > wrote:
> > > Hello mesa-dev community,
> > >
> > >
> > >
> > > We are starting to work on adding support for D3D12 Video
Hi Christian,
Am Donnerstag, dem 30.03.2023 um 19:54 + schrieb Christian Gudrian:
> Hi, Daniel!
>
> Thanks for your reply.
>
> > You need to force QtWayland to use the wp-linux-dmabuf-v1 platform
> > integration for the compositor.
>
> Yes. I've did that before and that indeed solves the ti
Hi Joao Paulo,
Am Mittwoch, dem 24.04.2024 um 19:31 -0300 schrieb Joao Paulo Silva
Goncalves:
> Hello all,
>
> We might have encountered a performance regression after upgrading from Mesa
> 2022.0.3 to 2024.0.2. During our automated hardware tests using LAVA, we
> noticed
> a lower score on glma
Am Donnerstag, dem 25.04.2024 um 07:56 -0300 schrieb Joao Paulo Silva
Goncalves:
>
>
> On Thu, Apr 25, 2024 at 5:58 AM Lucas Stach wrote:
>
> > Etnaviv added some resource tracking to fix issues with a number of
> > use-cases, which did add some CPU overhead and might c
Hi João Paulo,
Am Dienstag, dem 07.05.2024 um 15:17 -0300 schrieb João Paulo
Gonçalves:
> Hello all,
>
> I did run some benchmark on i.MX8MM GPU and I have some concerns on the
> differences between mainline Linux/etnaviv/Mesa and the proprietary
> NXP/Vivante
> solution.
>
> The tests were exe
Am Dienstag, dem 25.06.2024 um 09:56 +0200 schrieb Michel Dänzer:
> On 2024-06-24 21:08, James Jones wrote:
> > FWIW, the NVIDIA binary driver's implementation of gbm_bo_map/unmap()
> >
> > 1) Don't do any synchronization against in-flight work. The assumption is
> > that if the content is going
This adds a helper to check if a pipe format is in YUV color space.
Drivers want to know about this, as YUV mostly needs special handling.
Signed-off-by: Lucas Stach
---
src/gallium/auxiliary/util/u_format.h | 12
1 file changed, 12 insertions(+)
diff --git a/src/gallium/auxiliary
We only support importing YUV as OES external resources.
This will change in the future, but for now this fixes the
advertised capabilities in eglQueryDmaBufModifiersEXT.
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_screen.c | 2 +-
1 file changed, 1 insertion(+), 1
Am Sonntag, den 25.03.2018, 22:30 +0200 schrieb Christian Gmeiner:
> > Signed-off-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_query_pm.c | 63
> ++
> src/gallium/drivers/etnaviv/etnaviv_query_pm.h | 10
> 2 files changed, 73 insertions(+)
>
> d
Hi Daniel, et. al,
Am Dienstag, den 25.06.2019, 16:27 +0100 schrieb Daniel Stone:
> Hi,
>
> > On Tue, 25 Jun 2019 at 16:07, Jason Ekstrand wrote:
> > > > On Tue, Jun 25, 2019 at 4:04 AM Daniel Stone
> > > > wrote:
> > > > > > On Tue, 25 Jun 2019 at 07:26, Simon Ser wrote:
> > > > > I noticed
Hi Emil,
Am Mittwoch, den 31.07.2019, 09:37 +0100 schrieb Emil Velikov:
> Hi all,
>
> Here is the tentative release plan for 19.2.0.
>
> As many of you are well aware, it's time to the next branch point.
> The calendar is already updated, so these are the tentative dates:
>
> Aug 06 2019 - Fea
On Fr, 2020-02-28 at 10:47 +0100, Daniel Vetter wrote:
> On Fri, Feb 28, 2020 at 10:29 AM Erik Faye-Lund
> wrote:
> > On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote:
> > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter
> > > wrote:
> > > > Hi all,
> > > >
> > > > You might have read the short
Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay:
> One related issue with explicit sync using sync_file is that combined
> CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> rendering in userspace (like llvmpipe but for Vulkan and with extra
> instructions for GPU tasks)
Am Dienstag, den 17.03.2020, 11:33 -0400 schrieb Nicolas Dufresne:
> Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit :
> > Hi Jason,
> >
> > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> > > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote:
> > > > On Wed, M
Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> On Tue, Mar 17, 2020 at 10:21 AM Lucas Stach wrote:
> > Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay:
> > > One related issue with explicit sync using sync_file is that combined
> > > CP
Hi Fabio,
On Mo, 2020-09-21 at 09:41 -0300, Fabio Estevam wrote:
> Hi,
>
> I am trying to run glmark2 and I am getting the following error on an
> imx6qp-sabresd with kernel 5.8.4:
>
> # glmark2-es2-drm -d
> Debug: Using Udev to detect the right DRM node to use
> Debug: Looking for the main GPU
tracking across
different pipe_context's)
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_resource.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
b/src/gallium/drivers/etnaviv/etnaviv_resou
resource usage tracking across
different pipe_context's)
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_transfer.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
b/src/gallium/drivers/et
Trying to construct a scanout capable buffer will only ever work when
when we are on top of a KMS winsys, as the render node isn't capable
of allocating contiguous buffers.
Tested-by: Marius Vlad
Signed-off-by: Lucas Stach
---
src/gallium/drivers/etnaviv/etnaviv_resource.c | 2 +-
1
Am Mittwoch, den 27.03.2019, 14:58 +0100 schrieb Christian Gmeiner:
> Drop struct members which are only written to but never read from.
>
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> src/gallium/drivers/etnaviv/etnaviv_emit.c | 17 -
Hi Guido,
Am Montag, den 01.04.2019, 14:19 +0200 schrieb Guido Günther:
> Without that `GALLIUM_DDEBUG=always kmscube -A` would segfault like
>
> #0 0x in ()
> #1 0xa72a3c54 in dri2_get_fence_fd (_screen=0xed4f2090,
> _fence=0xed9ef880) at ../src/gallium/st
201 - 300 of 366 matches
Mail list logo
