Re: Possible Performance Regression with Mesa

[Lucas Stach]

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 cost some
> > performance, but should no be as dramatic as the numbers you are seeing
> > here.
> 
> Good to know. Thanks!
> 
> > Since the glmark2 cumulative score can be skewed quite heavily by
> >  single tests, it would be interesting to compare the results from
> >  individual benchmark tests. Do you see any outliers there or is the
> >  performance drop across the board?
> 
> It seems to have a perfomance impact on overall the individual benchmarks 
> too, for example:

I can reproduce the issue, but sadly there is no simple fix for this,
as it's a bad interaction between some of the new features.
At the core of the issue is the dmabuf-feedback support with the chain
of events being as follows:

1. weston switches to the scanout tranche, as it would like to put the
surface on a plane
2. the client reallocates as linear but does so on the render node
3. weston still isn't able to put the buffer on the plane, as it's
still scanout incompatible due to being non-contig, so needs to fall
back to rendering
4. now we are stuck at a linear buffer being used for rendering, which
is very non-optimal

I'll look into improving this, but can make no commitments as to when
I'll be able to get around to this.

Regards,
Lucas

Re: Possible Performance Regression with Mesa

[Lucas Stach]

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 glmark2 when we upgraded from the OpenEmbedded release from
> Kirkstone to Scartgarth. After conducting some internal tests, it doesn't seem
> to be an issue with the kernel or the glmark2 tool version, so we suspect that
> the issue may be related to something within Mesa. We believe that there might
> be something we're overlooking. Do you have any ideas or insights about
> this problem?
> 
Etnaviv added some resource tracking to fix issues with a number of
use-cases, which did add some CPU overhead and might cost some
performance, but should no be as dramatic as the numbers you are seeing
here.

> Here are some details about our hardware platform and some tests we
> have conducted:
> 
> Platform: Toradex Apalis iMX6 - NXP i.MX 6Q/6D Arm Cortex A9 with
> Vivante GC2000 rev 5108 using Etnaviv.
> 
> Tests:
> 
> Kernel Versions - v6.1.87 and v6.9-rc4
> Glmark2 Versions - 2021.12 and 2023.01
> 
> We combined different upstream kernel, Mesa, and glmark2 versions and
> ran glmark2 on each
> combination on a mostly idle system. The benchmark was run 20 times on
> each combination.
> 
> Some Results:
> 
> > Kernel   |   Mesa| glmark2 | Max-Min Score
> v6.1.87 2022.0.32021.12   449-495
> v6.9-rc42022.0.32021.12   452-502
> v6.1.87 2022.0.32023.01   453-504
> v6.9-rc42022.0.32023.01   455-496
> v6.1.87 2024.0.22021.12   301-313
> v6.9-rc42024.0.22021.12   298-320
> v6.1.87 2024.0.22023.01   301-313
> v6.9-rc42024.0.22023.01   295-310

Since the glmark2 cumulative score can be skewed quite heavily by
single tests, it would be interesting to compare the results from
individual benchmark tests. Do you see any outliers there or is the
performance drop across the board?

Regards,
Lucas

Re: wayland: wrong tiling with wl_drm on Vivante GC2000

[Lucas Stach]

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 tiling problem.
> However the CPU usage is much higher and the FPS drops from 60 to 30
> (I can see a similar behavior with Weston).

etnaviv simply does not have any sideband channel to communicate the
the tiling information, which would be required to make wl_drm work
with tiled buffers. Falling back to linear buffers is also not an
option for performance reasons. etnaviv requires a modifier enabled
interface to get the tiling correct, which in the wayland case is the
linux dmabuf protocol.

If you see a big difference in CPU usage between the two interfaces, it
would be good to investigate where this increased overhead is coming
from to see if we can just fix that.

Regards,
Lucas

Re: [Mesa-dev] Enabling Mesa video frontends on top of D3D12 gallium driver

[Lucas Stach]

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 acceleration in 
> > > the mesa gallium D3D12 driver so that mesa frontends such as VA, VDPAU, 
> > > etc can leverage HW acceleration in those environments.
> > > 
> > > To begin with we are working in a mesa fork project on a simple video 
> > > decoder prototype that implements the pipe_video_codec and 
> > > pipe_video_buffer interfaces with a D3D12 backend.
> > > 
> > Welcome, to start I'm not authorative on this area of Mesa at all,
> > I've just started investigating vaapi and vulkan video decode.
> > 
> > I'm not really sure who understands all the ins/outs, I've cc'ed two
> > AMD contacts who have worked on this code.
> 
> Yeah, I'm not working on that for a long time now but I think I still 
> have all the design pieces in my head.
> 
> > > Wayland/Software screen creation in VA_DRIVER_INIT_FUNC
> > > In our d3d12 gallium driver, we rely on the EGL/GLX and the DRI frontend 
> > > to handle the pure swrast screen creation as our virtualized environment 
> > > doesn’t have devices listed under /dev/dri/*.
> > > The default for gstreamer/vainfo initialization code in WSL seems to be 
> > > to create a Wayland display and pass it to VAInitialize. If we go ahead 
> > > and create a pure software wayland d3d12_screen in 
> > > VA_DRIVER_INIT_FUNC(VADriverContextP ctx) we hit vaGetSurfaceBufferWl() 
> > > is not implemented at VAAPI Gallium state tracker (#587) · Issues · Mesa 
> > > / mesa · GitLab when trying to run a simple gstreamer pipeline that 
> > > decodes with VAAPI (and d3d12 video backend) and presents to screen in a 
> > > display sink.
> > >  From vaGetSurfaceBufferWl() is not implemented at VAAPI Gallium state 
> > > tracker (#587) · Issues · Mesa / mesa · GitLab discussion, it looks like 
> > > “the change removing "NOT_IMPLEMENTED" is wayland display should be 
> > > opened with DRM code path, and it's already implemented. the code here is 
> > > not general switch to turn on the wayland support on vaapi, it's just one 
> > > of the steps to complete that support and which has been implemented.”
> > > Could you please provide some details on the high level design of how 
> > > wayland supports for libva and gallium video drivers ?
> > > Which of the currently implemented paths in mesa is currently recommended 
> > > in general for video driver implementors: Wayland with DRM fd device or X 
> > > DRI/DR3?
> > > What’d be a recommended way of supporting pure swrast screens like d3d12 
> > > for libva in VA_DRIVER_INIT_FUNC?
> 
> Well long story short: That simply won't work that easily.
> 
> As far as I know interop with Wayland only works by passing DMA-buf 
> handles around. And the problem is now that software drivers can't 
> create any DMA-buf handles because they don't have an underlying kernel 
> driver.
> 
> This question already came up a couple of times now in different contexts.
> 
> > > Are there any objections to having a pure sw (no DRM devices) screen ?
> > > Another alternative we discussed was to enable VGEM in the WSL kernel and 
> > > create a wayland swrast screen using a kms_dri_create_winsys with the 
> > > virtual DRM device FD but that’d still require more work to support 
> > > wayland presentation to screen code paths (see next section below).
> > > Recommended present path
> > > Assuming we create a wayland screen (pure software or using VGEM + DRM) 
> > > in VA_DRIVER_INIT_FUNC, once end_frame() finishes execution and we have 
> > > the decoded image in pipe_video_buffer *target, what are the supported 
> > > and recommended paths for presenting to screen?
> > > Looks like both VDPAU (vlVdpPresentationQueueDisplay) and VAAPI 
> > > (vlVaPutSurface) call texture_from_drawable() to pass the associated 
> > > pipe_resource texture to flush_frontbuffer(), but the 
> > > texture_from_drawable() function seems only implemented on X backends 
> > > (vl_winsys_dri3/vl_winsys_dri.c) and not for 
> > > vl_winsys_swrast/vl_winsys_drm. As it’s mentioned that there’s support 
> > > for wayland on vaapi, we’d like to get some clarity on how the 
> > > presentation path is designed here.
> > My expectation here is that making it operate like the GL paths is
> > probably what you want, and that if you are not using wayland there,
> > you shouldn't be doing it here. If you are there then adding support
> > for it here would be required.
> > 
> > I haven't investigated vaapi on wayland at all, and I probably need to
> > look into that soon, I'd expect adding proper support for presenting
> > would be a good feature to add there.
> > 
> > Currently at least using things like mplayer -hwdec=vaapi, the vaapi
> > code is just used to do the decode into dma-buf on Linux and then that
> > 

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

[Lucas Stach]

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 some cases where we are combining an AMD APU with a
FPGA based graphics card. I can't go into the specifics of this use-
case too much but basically the AMD graphics is rendering content that
gets composited on top of a live video pipeline running through the
FPGA.

> What about the case when we get a buffer from an external device and
> we're supposed to make it "busy" when we are using it, and the
> external device wants to wait until we stop using it? Is it something
> that can happen, thus turning "external -> amd" into "external <->
> amd"?

Zero-copy texture sampling from a video input certainly appreciates
this very much. Trying to pass the render fence through the various
layers of userspace to be able to tell when the video input can reuse a
buffer is a great experience in yak shaving. Allowing the video input
to reuse the buffer as soon as the read dma_fence from the GPU is
signaled is much more straight forward.

Regards,
Lucas

> Marek
> 
> On Tue., Apr. 27, 2021, 08:50 Christian König, < 
> ckoenig.leichtzumer...@gmail.com> wrote:
> >  Only amd -> external.
> >  
> >  We can easily install something in an user queue which waits for a
> > dma_fence in the kernel.
> >  
> >  But we can't easily wait for an user queue as dependency of a
> > dma_fence.
> >  
> >  The good thing is we have this wait before signal case on Vulkan
> > timeline semaphores which have the same problem in the kernel.
> >  
> >  The good news is I think we can relatively easily convert i915 and
> > older amdgpu device to something which is compatible with user
> > fences.
> >  
> >  So yes, getting that fixed case by case should work.
> >  
> >  Christian
> >  
> > Am 27.04.21 um 14:46 schrieb Marek Olšák:
> >  
> > > I'll defer to Christian and Alex to decide whether dropping sync
> > > with non-amd devices (GPUs, cameras etc.) is acceptable.
> > > 
> > > Rewriting those drivers to this new sync model could be done on a
> > > case by case basis.
> > > 
> > > For now, would we only lose the "amd -> external" dependency? Or
> > > the "external -> amd" dependency too?
> > > 
> > > Marek
> > > 
> > > On Tue., Apr. 27, 2021, 08:15 Daniel Vetter, 
> > > wrote:
> > >  
> > > > On Tue, Apr 27, 2021 at 2:11 PM Marek Olšák 
> > > > wrote:
> > > >  > Ok. I'll interpret this as "yes, it will work, let's do it".
> > > >  
> > > >  It works if all you care about is drm/amdgpu. I'm not sure
> > > > that's a
> > > >  reasonable approach for upstream, but it definitely is an
> > > > approach :-)
> > > >  
> > > >  We've already gone somewhat through the pain of drm/amdgpu
> > > > redefining
> > > >  how implicit sync works without sufficiently talking with
> > > > other
> > > >  people, maybe we should avoid a repeat of this ...
> > > >  -Daniel
> > > >  
> > > >  >
> > > >  > Marek
> > > >  >
> > > >  > On Tue., Apr. 27, 2021, 08:06 Christian König,
> > > >  wrote:
> > > >  >>
> > > >  >> Correct, we wouldn't have synchronization between device
> > > > with
> > > > and without user queues any more.
> > > >  >>
> > > >  >> That could only be a problem for A+I Laptops.
> > > >  >>
> > > >  >> Memory management will just work with preemption fences
> > > > which
> > > > pause the user queues of a process before evicting something.
> > > > That will be a dma_fence, but also a well known approach.
> > > >  >>
> > > >  >> Christian.
> > > >  >>
> > > >  >> Am 27.04.21 um 13:49 schrieb Marek Olšák:
> > > >  >>
> > > >  >> If we don't use future fences for DMA fences at all, e.g.
> > > > we
> > > > don't use them for memory management, it can work, right?
> > > > Memory
> > > > management can suspend user queues anytime. It doesn't need to
> > > > use DMA fences. There might be something that I'm missing here.
> > > >  >>
> > > >  >> What would we lose without DMA fences? Just inter-device
> > > > synchronization? I think that might be acceptable.
> > > >  >>
> > > >  >> The only case when the kernel will wait on a future fence
> > > > is
> > > > before a page flip. Everything today already depends on
> > > > userspace
> > > > not hanging the gpu, which makes everything a future fence.
> > > >  >>
> > > >  >> Marek
> > > >  >>
> > > >  >> On Tue., Apr. 27, 2021, 04:02 Daniel Vetter,
> > > >  wrote:
> > > >  >>>
> > > >  >>> On Mon, Apr 26, 2021 at 04:59:28PM -0400, Marek Olšák
> > > > wrote:
> > > >  >>> > Thanks everybody. The initial proposal is dead. Here are
> > > > some thoughts on
> > > >  >>> > how to do it differently.
> > > >  >>> >
> > > >  >>> > I think we can have direct command submission from
> > > > userspace via
> > > >  >>> > memory-mapped queues ("user queues") without changing
> > > > window systems.
> > > >  >>> >
> > > >  >>> > 

Re: [Mesa-dev] Etnaviv: eglCreateWindowSurface fails with glmark2

[Lucas Stach]

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 DRM node...
> Debug: Not found!
> Debug: Looking for a concrete GPU DRM node...
> Debug: Success!
> Debug: Trying to use the DRM node /dev/dri/card0
> Debug: Success!
> Debug: Using eglGetPlatformDisplayEXT()
> Debug: Got 6 suitable EGLConfigs:
> Debug:
> Debug: cfg buf  rgb  colorbuffer dp st config native support
> surface sample
> Debug:  id  sz  lum  r  g  b  a  th cl caveat
> render  visidtype  buf ns
> Debug: --
> --
> Debug: 0x2  32  rgb 10 10 10  2  16  0   None   true0x30334241
> 0x4   0  0
> Debug: 0xa  32  rgb  8  8  8  8  16  0   None   true0x34325241
> 0x4   0  0
> Debug: 0x3  32  rgb 10 10 10  2  24  0   None   true0x30334241
> 0x4   0  0
> Debug: 0xb  32  rgb  8  8  8  8  24  0   None   true0x34325241
> 0x4   0  0
> Debug: 0x4  32  rgb 10 10 10  2  24  8   None   true0x30334241
> 0x4   0  0
> Debug: 0xc  32  rgb  8  8  8  8  24  8   None   true0x34325241
> 0x4   0  0
> Debug:
> Debug: Best EGLConfig ID: 0x3
> Error: eglCreateWindowSurface failed with error: 0x3009
> Error: eglCreateWindowSurface failed with error: 0x3009
> Error: CanvasGeneric: Invalid EGL state
> Error: main: Could not initialize canvas
> 
> kmscube runs without issues.
> 
> glmark2-es2-drm used to work fine with older kernel/Mesa versions.
> 
> Does anyone have any ideas?

Since a while Mesa offers 10bit EGL configs, which have the highest
priority and thus get selected if the application doesn't care about
bit depth. imx-drm is unable to scanout those formats.

Try starting glmark with --visual-config red=8 as a workaround to get a
scanout capable visual.

Regards,
Lucas

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

[Lucas Stach]

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
> > > 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) but need to synchronize with other
> > > drivers/processes is that there should be some way to create an
> > > explicit fence/semaphore from userspace and later signal it. This
> > > seems to conflict with the requirement for a sync_file to complete in
> > > finite time, since the user process could be stopped or killed.
> > > 
> > > Any ideas?
> > 
> > Finite just means "not infinite". If you stop the process that's doing
> > part of the pipeline processing you block the pipeline, you get to keep
> > the pieces in that case.
> 
> Seems reasonable.
> 
> > That's one of the issues with implicit sync
> > that explicit may solve: a single client taking way too much time to
> > render something can block the whole pipeline up until the display
> > flip. With explicit sync the compositor can just decide to use the last
> > client buffer if the latest buffer isn't ready by some deadline.
> > 
> > With regard to the process getting killed: whatever you sync primitive
> > is, you need to make sure to signal the fence (possibly with an error
> > condition set) when you are not going to make progress anymore. So
> > whatever your means to creating the sync_fd from your software renderer
> > is, it needs to signal any outstanding fences on the sync_fd when the
> > fd is closed.
> 
> I think I found a userspace-accessible way to create sync_files and
> dma_fences that would fulfill the requirements:
> https://github.com/torvalds/linux/blob/master/drivers/dma-buf/sw_sync.c
> 
> I'm just not sure if that's a good interface to use, since it appears
> to be designed only for debugging. Will have to check for additional
> requirements of signalling an error when the process that created the
> fence is killed.

Something like that can certainly be lifted for general use if it makes
sense. But then with a software renderer I don't really see how fences
help you at all. With a software renderer you know exactly when the
frame is finished and you can just defer pushing it over to the next
pipeline element until that time. You won't gain any parallelism by
using fences as the CPU is busy doing the rendering and will not run
other stuff concurrently, right?

Regards,
Lucas

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

[Lucas Stach]

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, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote:
> > > > > (I know I'm going to be spammed by so many mailing list ...)
> > > > > 
> > > > > Le mercredi 11 mars 2020 à 14:21 -0500, Jason Ekstrand a écrit :
> > > > > > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand 
> > > > > >  wrote:
> > > > > > > All,
> > > > > > > 
> > > > > > > Sorry for casting such a broad net with this one. I'm sure most 
> > > > > > > people
> > > > > > > who reply will get at least one mailing list rejection.  However, 
> > > > > > > this
> > > > > > > is an issue that affects a LOT of components and that's why it's
> > > > > > > thorny to begin with.  Please pardon the length of this e-mail as
> > > > > > > well; I promise there's a concrete point/proposal at the end.
> > > > > > > 
> > > > > > > 
> > > > > > > Explicit synchronization is the future of graphics and media.  At
> > > > > > > least, that seems to be the consensus among all the graphics 
> > > > > > > people
> > > > > > > I've talked to.  I had a chat with one of the lead Android 
> > > > > > > graphics
> > > > > > > engineers recently who told me that doing explicit sync from the 
> > > > > > > start
> > > > > > > was one of the best engineering decisions Android ever made.  It's
> > > > > > > also the direction being taken by more modern APIs such as Vulkan.
> > > > > > > 
> > > > > > > 
> > > > > > > ## What are implicit and explicit synchronization?
> > > > > > > 
> > > > > > > For those that aren't familiar with this space, GPUs, media 
> > > > > > > encoders,
> > > > > > > etc. are massively parallel and synchronization of some form is
> > > > > > > required to ensure that everything happens in the right order and
> > > > > > > avoid data races.  Implicit synchronization is when bits of work 
> > > > > > > (3D,
> > > > > > > compute, video encode, etc.) are implicitly based on the absolute
> > > > > > > CPU-time order in which API calls occur.  Explicit 
> > > > > > > synchronization is
> > > > > > > when the client (whatever that means in any given context) 
> > > > > > > provides
> > > > > > > the dependency graph explicitly via some sort of synchronization
> > > > > > > primitives.  If you're still confused, consider the following
> > > > > > > examples:
> > > > > > > 
> > > > > > > With OpenGL and EGL, almost everything is implicit sync.  Say you 
> > > > > > > have
> > > > > > > two OpenGL contexts sharing an image where one writes to it and 
> > > > > > > the
> > > > > > > other textures from it.  The way the OpenGL spec works, the 
> > > > > > > client has
> > > > > > > to make the API calls to render to the image before (in CPU time) 
> > > > > > > it
> > > > > > > makes the API calls which texture from the image.  As long as it 
> > > > > > > does
> > > > > > > this (and maybe inserts a glFlush?), the driver will ensure that 
> > > > > > > the
> > > > > > > rendering completes before the texturing happens and you get 
> > > > > > > correct
> > > > > > > contents.
> > > > > > > 
> > > > > > > Implicit synchronization can also happen across processes.  
> > > > > > > Wayland,
> > > > > > > for instance, is currently built on implicit sync where the client
> > > > > > > does their rendering and then does a hand-off (via 
> > > > > > > wl_surface::commit)
> > > > > > > to tell the compositor it's done at which point the compositor 
> > > > > > > can now
> > > > > > > texture from the surface.  The hand-off ensures that the client's
> > > > > > > OpenGL API calls happen before the server's OpenGL API calls.
> > > > > > > 
> > > > > > > A good example of explicit synchronization is the Vulkan API.  
> > > > > > > There,
> > > > > > > a client (or multiple clients) can simultaneously build command
> > > > > > > buffers in different threads where one of those command buffers
> > > > > > > renders to an image and the other textures from it and then submit
> > > > > > > both of them at the same time with instructions to the driver for
> > > > > > > which order to execute them in.  The execution order is described 
> > > > > > > via
> > > > > > > the VkSemaphore primitive.  With the new VK_KHR_timeline_semaphore
> > > > > > > extension, you can even submit the work which does the texturing
> > > > > > > BEFORE the work which does the rendering and the driver will sort 
> > > > > > > it
> > > > > > > out.
> > > > > > > 
> > > > > > > The #1 problem with implicit synchronization (which explicit 
> > > > > > > solves)
> > > > > > > is that it leads to a lot of over-synchronization both in client 
> > > > > > > space
> > > > > > > and in driver/device space.  The client has to synchronize a lot 
> > > > > > > more
> > > > > > > because it has to ensure that the 

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

[Lucas Stach]

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) but need to synchronize with other
> drivers/processes is that there should be some way to create an
> explicit fence/semaphore from userspace and later signal it. This
> seems to conflict with the requirement for a sync_file to complete in
> finite time, since the user process could be stopped or killed.
> 
> Any ideas?

Finite just means "not infinite". If you stop the process that's doing
part of the pipeline processing you block the pipeline, you get to keep
the pieces in that case. That's one of the issues with implicit sync
that explicit may solve: a single client taking way too much time to
render something can block the whole pipeline up until the display
flip. With explicit sync the compositor can just decide to use the last
client buffer if the latest buffer isn't ready by some deadline.

With regard to the process getting killed: whatever you sync primitive
is, you need to make sure to signal the fence (possibly with an error
condition set) when you are not going to make progress anymore. So
whatever your means to creating the sync_fd from your software renderer
is, it needs to signal any outstanding fences on the sync_fd when the
fd is closed.

Regards,
Lucas

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Lucas Stach]

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 take in the X.org board meeting
> > > > minutes
> > > > already, here's the long version.
> > > > 
> > > > The good news: gitlab.fd.o has become very popular with our
> > > > communities, and is used extensively. This especially includes all
> > > > the
> > > > CI integration. Modern development process and tooling, yay!
> > > > 
> > > > The bad news: The cost in growth has also been tremendous, and it's
> > > > breaking our bank account. With reasonable estimates for continued
> > > > growth we're expecting hosting expenses totalling 75k USD this
> > > > year,
> > > > and 90k USD next year. With the current sponsors we've set up we
> > > > can't
> > > > sustain that. We estimate that hosting expenses for gitlab.fd.o
> > > > without any of the CI features enabled would total 30k USD, which
> > > > is
> > > > within X.org's ability to support through various sponsorships,
> > > > mostly
> > > > through XDC.
> > > > 
> > > > Note that X.org does no longer sponsor any CI runners themselves,
> > > > we've stopped that. The huge additional expenses are all just in
> > > > storing and serving build artifacts and images to outside CI
> > > > runners
> > > > sponsored by various companies. A related topic is that with the
> > > > growth in fd.o it's becoming infeasible to maintain it all on
> > > > volunteer admin time. X.org is therefore also looking for admin
> > > > sponsorship, at least medium term.
> > > > 
> > > > Assuming that we want cash flow reserves for one year of
> > > > gitlab.fd.o
> > > > (without CI support) and a trimmed XDC and assuming no sponsor
> > > > payment
> > > > meanwhile, we'd have to cut CI services somewhere between May and
> > > > June
> > > > this year. The board is of course working on acquiring sponsors,
> > > > but
> > > > filling a shortfall of this magnitude is neither easy nor quick
> > > > work,
> > > > and we therefore decided to give an early warning as soon as
> > > > possible.
> > > > Any help in finding sponsors for fd.o is very much appreciated.
> > > 
> > > a) Ouch.
> > > 
> > > b) we probably need to take a large step back here.
> > > 
> > 
> > I kinda agree, but maybe the step doesn't have to be *too* large?
> > 
> > I wonder if we could solve this by restructuring the project a bit. I'm
> > talking purely from a Mesa point of view here, so it might not solve
> > the full problem, but:
> > 
> > 1. It feels silly that we need to test changes to e.g the i965 driver
> > on dragonboards. We only have a big "do not run CI at all" escape-
> > hatch.
> > 
> > 2. A lot of us are working for a company that can probably pay for
> > their own needs in terms of CI. Perhaps moving some costs "up front" to
> > the company that needs it can make the future of CI for those who can't
> > do this
> > 
> > 3. I think we need a much more detailed break-down of the cost to make
> > educated changes. For instance, how expensive is Docker image
> > uploads/downloads (e.g intermediary artifacts) compared to build logs
> > and final test-results? What kind of artifacts?
> 
> We have logs somewhere, but no one yet got around to analyzing that.
> Which will be quite a bit of work to do since the cloud storage is
> totally disconnected from the gitlab front-end, making the connection
> to which project or CI job caused something is going to require
> scripting. Volunteers definitely very much welcome I think.

It's very surprising to me that this kind of cost monitoring is treated
as an afterthought, especially since one of the main jobs of the X.Org
board is to keep spending under control and transparent.

Also from all the conversations it's still unclear to me if the google
hosting costs are already over the sponsored credits (so is burning a
hole into X.org bank account right now) or if this is only going to
happen at a later point in time.

Even with CI disabled it seems that the board estimates a cost of 30k
annually for the plain gitlab hosting. Is this covered by the credits
sponsored by google? If not, why wasn't there a board voting on this
spending? All other spending seem to require pre-approval by the board.
Why wasn't gitlab hosting cost discussed much earlier in the public
board meetings, especially if it's going to be such an big chunk of the
overall spending of the X.Org foundation?

Regards,
Lucas

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 19.2.0 release plan

[Lucas Stach]

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 - Feature freeze/Release candidate 1
>  Aug 13 2019 - Release candidate 2
>  Aug 20 2019 - Release candidate 3
>  Aug 27 2019 - Release candidate 4/final release
> 
> This gives us around 1 week until the branch point.
> 
> Note: In the spirit of keeping things clearer and more transparent, we
> will be keeping track of any features planned for the release in
> Bugzilla [1].
> 
> Do add a separate "Depends on" for each work you have planned.
> Alternatively you can reply to this email and I'll add them for you.
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=111265

The etnaviv team would like to land the experimental NIR compiler [1]
and a good bunch of fixes for multithreading issues [2] before the
branching.

Regards,
Lucas

[1] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1497
[2] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1190
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm: add gbm_{bo, surface}_create_with_modifiers2

[Lucas Stach]

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 that original patch (v1) for gbm_bo_create_with_modifiers 
> > > > > did
> > > > > have usage at first but it was removed during the review. I'm having
> > > > > trouble digging what was the reason for this?
> > > > 
> > > > I'm not sure either. Daniel said it was a mistake.
> > > > 
> > > > Adding the 63bd2ae7452d4 folks to the discussion. Ben, do you remember
> > > > the details?
> > > 
> > > We decided to remove it since we decided that modifiers were a good
> > > enough proxy for usage; no need to pass SCANOUT or TEXTURE anymore,
> > > because we already get the scanout modifiers from KMS and the texture
> > > modifiers from EGL.
> > > 
> > > In hindsight, I think this was a mistake since it only handles buffer
> > > layout, and not buffer placement or cache configuration.
> > 
> > 
> > It's not great but modifiers should be able to handle that as well.  You 
> > can have _CONTIGUOUS versions of the modifiers supported by scanout and 
> > scanout will only advertise those and the caller has to know to place them 
> > in contiguous memory.  That's just an example but I think it would probably 
> > work for a lot of the cases.  If not, I'd love to know why not.
> 
> Sometimes it's _CONTIGUOUS, sometimes it's _ON_THIS_PCIE_DEVICE.
> Either way, it does seem like a bit of an abuse: it has nothing to do
> with internal buffer layout, but how and where the backing pages are
> sourced.
> 
> Given that it's completely orthogonal, I wouldn't like to go trying to
> combine it into the same namespace.

If this is about the specifics of the backing store placement, I fear
that a simple uint32_t usage won't get us far at all. It might be able
to cover the most pressing "I really need contig" issue, but it will
break down shortly after this.

At the risk of opening a big can of worms: has anyone thought about
describing the usage as a set of allocator [1]
constraints/capabilities? I feel like those are in a much better
position to actually cover the use-cases you touched above.

Regards,
Lucas

[1] https://gitlab.freedesktop.org/allocator/allocator
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] etnaviv: fix some pm query issues

[Lucas Stach]

The offsets to read the query results were off-by-one, which causes the
counters to report bogus increasing values.

Also the counter result is u32, so we need to initialize the query type
to reflect that.

Signed-off-by: Lucas Stach 
---
This only fixes the obvious issues. I still believe there are some
GPU/CPU synchronization issues in this code, that need to be fixed
separately.
---
 src/gallium/drivers/etnaviv/etnaviv_query_pm.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_query_pm.c 
b/src/gallium/drivers/etnaviv/etnaviv_query_pm.c
index ade0b9790c28..c63ed8304919 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_query_pm.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_query_pm.c
@@ -485,9 +485,9 @@ etna_pm_query_get(struct etna_cmd_stream *stream, struct 
etna_query *q,
assert(flags);
 
if (flags == ETNA_PM_PROCESS_PRE)
-  offset = 2;
+  offset = 1;
else
-  offset = 3;
+  offset = 2;
 
struct etna_perf p = {
   .flags = flags,
@@ -639,6 +639,10 @@ etna_pm_get_driver_query_info(struct pipe_screen *pscreen, 
unsigned index,
info->name = query_config[i].name;
info->query_type = query_config[i].type;
info->group_id = query_config[i].group_id;
+   info->type = PIPE_DRIVER_QUERY_TYPE_UINT;
+   info->result_type = PIPE_DRIVER_QUERY_RESULT_TYPE_AVERAGE;
+   info->max_value.u32 = 0;
+   info->flags = 0;
 
return 1;
 }
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH libdrm] etnaviv: drop etna_bo_from_handle symbol

[Lucas Stach]

There is no implementation and also no users, so there is no point
in keeping it in the API.

Signed-off-by: Lucas Stach 
---
 etnaviv/etnaviv-symbol-check | 1 -
 etnaviv/etnaviv_drmif.h  | 2 --
 2 files changed, 3 deletions(-)

diff --git a/etnaviv/etnaviv-symbol-check b/etnaviv/etnaviv-symbol-check
index 0e2030e4672f..965870236111 100755
--- a/etnaviv/etnaviv-symbol-check
+++ b/etnaviv/etnaviv-symbol-check
@@ -23,7 +23,6 @@ etna_pipe_del
 etna_pipe_wait
 etna_pipe_wait_ns
 etna_bo_new
-etna_bo_from_handle
 etna_bo_from_name
 etna_bo_from_dmabuf
 etna_bo_ref
diff --git a/etnaviv/etnaviv_drmif.h b/etnaviv/etnaviv_drmif.h
index 87704acd3469..198bb429ada2 100644
--- a/etnaviv/etnaviv_drmif.h
+++ b/etnaviv/etnaviv_drmif.h
@@ -112,8 +112,6 @@ int etna_pipe_wait_ns(struct etna_pipe *pipe, uint32_t 
timestamp, uint64_t ns);
 
 struct etna_bo *etna_bo_new(struct etna_device *dev,
uint32_t size, uint32_t flags);
-struct etna_bo *etna_bo_from_handle(struct etna_device *dev,
-   uint32_t handle, uint32_t size);
 struct etna_bo *etna_bo_from_name(struct etna_device *dev, uint32_t name);
 struct etna_bo *etna_bo_from_dmabuf(struct etna_device *dev, int fd);
 struct etna_bo *etna_bo_ref(struct etna_bo *bo);
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: rs: choose clear format based on block size

[Lucas Stach]

Am Sonntag, den 26.05.2019, 21:06 +0200 schrieb Christian Gmeiner:
> Fixes following piglit and does not introduce any regressions.
>   spec@ext_packed_depth_stencil@fbo-depth-gl_depth24_stencil8-blit
> 
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_rs.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index e64babfdd0a..8c85f329f76 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -254,7 +254,19 @@ etna_rs_gen_clear_surface(struct etna_context *ctx, 
> struct etna_surface *surf,
>    uint32_t clear_value)
>  {
> struct etna_resource *dst = etna_resource(surf->base.texture);
> -   uint32_t format = translate_rs_format(surf->base.format);
> +   uint32_t format;
> +
> +   switch (util_format_get_blocksizebits(surf->base.format)) {
> +   case 16:
> +  format = RS_FORMAT_A4R4G4B4;
> +  break;
> +   case 32:
> +  format = RS_FORMAT_A8R8G8B8;
> +  break;
> +   default:
> +  format = ETNA_NO_MATCH;
> +  break;
> +   }
>  
> if (format == ETNA_NO_MATCH) {
>    BUG("etna_rs_gen_clear_surface: Unhandled clear fmt %s", 
> util_format_name(surf->base.format));
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: fill missing offset in etna_resource_get_handle

[Lucas Stach]

Am Freitag, den 03.05.2019, 12:05 +0200 schrieb Philipp Zabel:
> Without this gbm_bo_get_offset() can return 0 where it shouldn't.

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 83179d3cd088..ab77a80c72b3 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -622,6 +622,7 @@ etna_resource_get_handle(struct pipe_screen *pscreen,
>    rsc = etna_resource(rsc->external);
>  
> handle->stride = rsc->levels[0].stride;
> +   handle->offset = rsc->levels[0].offset;
> handle->modifier = layout_to_modifier(rsc->layout);
>  
> if (handle->type == WINSYS_HANDLE_TYPE_SHARED) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/8] etnaviv: add 2D GPU YUV->RGB blitter

[Lucas Stach]

Am Freitag, den 26.04.2019, 08:24 +0200 schrieb Christian Gmeiner:
> Am Fr., 12. Apr. 2019 um 19:38 Uhr schrieb Lucas Stach 
> :
> > 
> > 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 
> > ---
[...]
> > +
> > +   switch (blit_info->src.format) {
> > +   case PIPE_FORMAT_NV12:
> > +  src_format = DE_FORMAT_NV12;
> > +  break;
> > +   case PIPE_FORMAT_YUYV:
> > +  src_format = DE_FORMAT_YUY2;
> > +  break;
> 
> Do you need to support YUVU in your utlra fast video-path with 
> glReadPixels(..)?

Yes, as this is the output format of the VDOA. Using the VPU together
with the VDOA is the highest performing video decode path on i.MX6.

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/6] Add support for NV12

[Lucas Stach]

Am Freitag, den 26.04.2019, 09:41 +0200 schrieb Christian Gmeiner:
> Hi Lucas
> 
> > 
> > Am Mittwoch, den 24.04.2019, 08:36 +0200 schrieb Christian Gmeiner:
> > > This patch series goes a complete different route then the one from
> > > Lucas Stach. I am using the integrated YUV tiler instead of using
> > > the 2D core for format conversion. I am reusing some patches from
> > > Lucas and this series sits on-top of Lucas "st/dri: YUV" patches.
> > 
> > We specifically opted to use the 2D GPU to do a format conversion, as
> > this yields a RGB internal representation, which means the texture has
> > the same properties as a normal GL texture (e.g. glReadPixels works).
> > This way we can expose YUV format imports as non-external textures.
> > 
> 
> Do you know out of head if rs can handle yuv? If that would be the case
> the conversion from yuv -> rgb could also be done this way and you have
> the same interal RGB representation. But I have the feeling
> YUY2_RENDER_TARGET (aka. RS_FORMAT_YUY2) needs to be supported.

I think the RS can do some of the YUY2 conversions, but it certainly
can not do any of the planar formats.

> Is glReadPixels(..) and friends really an use-case for YUV textures? To be
> honest I am not that deep in that topic.

The point isn't that we need glReadPixels for anything, but that the
fact that it works properly allows us to expose the the import as a
regular non-external glTexture without having to lie or cheat. Non-
external textures have some benefits in the lifetime handling that make
the upper parts of the stack more performant.

> Maybe you can 1-2 sentences about the reasoning for using the 2D core
> somewhere in an commit message?
> 
> > This provides a number of benefits in texture lifetime handling in the
> > upper layers of the stack, which are used to drive those video use-
> > cases, like GStreamer. I don't really care what the blob does, but I do
> > care about having the highest performing solution, which is to have the
> > 2D GPU work in parallel with the 3D GPU and allow efficient texture
> > imports with GStreamer.
> > 
> 
> As the branch point is coming I am okay with this. But I have the feeling
> that we need to touch this area in near future for our lovely imx8 based gpus.

My guess is that the BLT engine can actually do a similar CSC like we
do on the 2D now. As the BLT engine can be driven asynchronously, we
should have almost the same behavior as with the 2D GPU based solution.

> Btw. do you have some numbers regarding the speed-up you get by using the
> 2D core in parallel?

I don't have any numbers for the speedup, but we have some use-cases
where even the fast-path on the new GC320 on i.MX6QP, which can use a
regular bitblit that does 2 pixels/clock and has a relatively high
clock frequency, we reach a GPU load of 25% for the texture import.
Moving this load away from the 3D GPU seems worthwhile.

Regards,
Lucas

> > I would really appreciate a review of my patch series.
> > 
> > Regards,
> > Lucas
> > 
> > > Christian Gmeiner (3):
> > >   etnaviv: direct YUYV/UYVY support
> > >   etnaviv: update headers from rnndb
> > >   etnaviv: add multi-planar YUV support
> > > 
> > > Lucas Stach (3):
> > >   etnaviv: clear out next pointer when allocating resource
> > >   etnaviv: remember data offset into BO
> > >   etnaviv: improve PIPE_BIND_LINEAR handling
> > > 
> > >  .../drivers/etnaviv/etnaviv_clear_blit.c  |   2 +-
> > >  src/gallium/drivers/etnaviv/etnaviv_format.c  |   5 +-
> > >  .../drivers/etnaviv/etnaviv_resource.c|  24 +++-
> > >  src/gallium/drivers/etnaviv/etnaviv_rs.c  |   5 +
> > >  src/gallium/drivers/etnaviv/etnaviv_screen.c  |   4 +
> > >  src/gallium/drivers/etnaviv/etnaviv_texture.c |   8 ++
> > >  src/gallium/drivers/etnaviv/etnaviv_yuv.c | 123
> > > ++
> > >  src/gallium/drivers/etnaviv/etnaviv_yuv.h |  44 +++
> > >  src/gallium/drivers/etnaviv/hw/common.xml.h   |   2 +-
> > >  .../drivers/etnaviv/hw/common_3d.xml.h|   2 +-
> > >  src/gallium/drivers/etnaviv/hw/state.xml.h|   4 +-
> > >  src/gallium/drivers/etnaviv/hw/state_3d.xml.h |  35 +++--
> > >  .../drivers/etnaviv/hw/state_blt.xml.h|   4 +-
> > >  .../drivers/etnaviv/hw/texdesc_3d.xml.h   |   2 +-
> > >  src/gallium/drivers/etnaviv/meson.build   |   2 +
> > >  15 files changed, 240 insertions(+), 26 deletions(-)
> > >  create mode 100644 src/gallium/drivers/etnaviv/etnaviv_yuv.c
> > >  create mode 100644 src/gallium/drivers/etnaviv/etnaviv_yuv.h
> > > 
> 
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/6] Add support for NV12

[Lucas Stach]

Hi Christian,

Am Mittwoch, den 24.04.2019, 08:36 +0200 schrieb Christian Gmeiner:
> This patch series goes a complete different route then the one from
> Lucas Stach. I am using the integrated YUV tiler instead of using
> the 2D core for format conversion. I am reusing some patches from
> Lucas and this series sits on-top of Lucas "st/dri: YUV" patches.

We specifically opted to use the 2D GPU to do a format conversion, as
this yields a RGB internal representation, which means the texture has
the same properties as a normal GL texture (e.g. glReadPixels works).
This way we can expose YUV format imports as non-external textures.

This provides a number of benefits in texture lifetime handling in the
upper layers of the stack, which are used to drive those video use-
cases, like GStreamer. I don't really care what the blob does, but I do
care about having the highest performing solution, which is to have the
2D GPU work in parallel with the 3D GPU and allow efficient texture
imports with GStreamer.

I would really appreciate a review of my patch series.

Regards,
Lucas

> Christian Gmeiner (3):
>   etnaviv: direct YUYV/UYVY support
>   etnaviv: update headers from rnndb
>   etnaviv: add multi-planar YUV support
> 
> Lucas Stach (3):
>   etnaviv: clear out next pointer when allocating resource
>   etnaviv: remember data offset into BO
>   etnaviv: improve PIPE_BIND_LINEAR handling
> 
>  .../drivers/etnaviv/etnaviv_clear_blit.c  |   2 +-
>  src/gallium/drivers/etnaviv/etnaviv_format.c  |   5 +-
>  .../drivers/etnaviv/etnaviv_resource.c|  24 +++-
>  src/gallium/drivers/etnaviv/etnaviv_rs.c  |   5 +
>  src/gallium/drivers/etnaviv/etnaviv_screen.c  |   4 +
>  src/gallium/drivers/etnaviv/etnaviv_texture.c |   8 ++
>  src/gallium/drivers/etnaviv/etnaviv_yuv.c | 123
> ++
>  src/gallium/drivers/etnaviv/etnaviv_yuv.h |  44 +++
>  src/gallium/drivers/etnaviv/hw/common.xml.h   |   2 +-
>  .../drivers/etnaviv/hw/common_3d.xml.h|   2 +-
>  src/gallium/drivers/etnaviv/hw/state.xml.h|   4 +-
>  src/gallium/drivers/etnaviv/hw/state_3d.xml.h |  35 +++--
>  .../drivers/etnaviv/hw/state_blt.xml.h|   4 +-
>  .../drivers/etnaviv/hw/texdesc_3d.xml.h   |   2 +-
>  src/gallium/drivers/etnaviv/meson.build   |   2 +
>  15 files changed, 240 insertions(+), 26 deletions(-)
>  create mode 100644 src/gallium/drivers/etnaviv/etnaviv_yuv.c
>  create mode 100644 src/gallium/drivers/etnaviv/etnaviv_yuv.h
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/6] st/dri: allow to create image for formats that only support SV or RT binding

[Lucas Stach]

Hi Michel,

Am Montag, den 15.04.2019, 12:04 +0200 schrieb Michel Dänzer:
> On 2019-04-12 7:33 p.m., Lucas Stach wrote:
> > 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/gallium/state_trackers/dri/dri2.c
> > index efb43c0d7973..510b7f8d04a7 100644
> > --- a/src/gallium/state_trackers/dri/dri2.c
> > +++ b/src/gallium/state_trackers/dri/dri2.c
> > @@ -987,14 +987,23 @@ dri2_create_image_common(__DRIscreen *_screen,
> >  {
> > const struct dri2_format_mapping *map = 
> > dri2_get_mapping_by_format(format);
> > struct dri_screen *screen = dri_screen(_screen);
> > +   struct pipe_screen *pscreen = screen->base.screen;
> > __DRIimage *img;
> > struct pipe_resource templ;
> > -   unsigned tex_usage;
> > +   unsigned tex_usage = 0;
> >  
> > if (!map)
> >    return NULL;
> >  
> > -   tex_usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> > +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
> > screen->target,
> > +0, 0, PIPE_BIND_RENDER_TARGET))
> > +  tex_usage |= PIPE_BIND_RENDER_TARGET;
> > +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
> > screen->target,
> > +0, 0, PIPE_BIND_SAMPLER_VIEW))
> > +  tex_usage |= PIPE_BIND_SAMPLER_VIEW;
> > +
> > +   if (!tex_usage)
> > +  return NULL;
> >  
> > if (use & __DRI_IMAGE_USE_SCANOUT)
> >    tex_usage |= PIPE_BIND_SCANOUT;
> > 
> 
> Since there are no __DRI_IMAGE_USE_* flags for rendering & sampling, the
> expectation does seem to be that both are supported. What happens if an
> image is created for a format which only supports sampling, then the
> caller attempts rendering to it?

While I agree that the missing flags is a problem, I don't think the
expectation that createImage must create something which is both render
and sampler compatible holds anymore.

kmscube for example does create a R8 buffer via gbm_bo_create that is
only used to create a texture. As this is going through the createImage
path it will fail on drivers that only support texturing from R8, like
etnaviv, which is definitely not what the application expects. There is
quite a bit of API abuse involved in this example, but I'm not sure if
the right way to deal with this is break the application.

Also are other ways to come up with a DRI image that is only sampler
compatible, like the create_image_from_fd paths. While we may be able
to fix the gbm case, as we have the flags available there, we can't do
this as easily for the import paths, as there are no usage flags
available at the EGL API level.

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/8] etnaviv: clear out next pointer when allocating resource

[Lucas Stach]

Am Montag, den 15.04.2019, 12:20 +0200 schrieb Philipp Zabel:
> On Fri, 2019-04-12 at 19:38 +0200, Lucas Stach wrote:
> > 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/drivers/etnaviv/etnaviv_resource.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> > b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > index 83179d3cd088..77d027ac806b 100644
> > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > @@ -274,6 +274,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, 
> > unsigned layout,
> 
> Context:
> 
>    rsc = CALLOC_STRUCT(etna_resource);
>    if (!rsc)
> >    return NULL;
> >  
> > rsc->base = *templat;

This copies the content of templat into our resource base, so if
templat has the next pointer set it will also be set in our resource.

> > +   rsc->base.next = NULL;
> > rsc->base.screen = pscreen;
> > rsc->base.nr_samples = nr_samples;
> > rsc->layout = layout;
> 
> The calloc just above already clears the memory to zero.

See above.

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/8] etnaviv: create optional 2d pipe in screen

[Lucas Stach]

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/gallium/drivers/etnaviv/etnaviv_screen.c  | 68 +++
 src/gallium/drivers/etnaviv/etnaviv_screen.h  |  6 ++
 4 files changed, 81 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
b/src/gallium/drivers/etnaviv/etnaviv_context.c
index a59338490b62..631f551d0ad4 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_context.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
@@ -78,6 +78,9 @@ etna_context_destroy(struct pipe_context *pctx)
if (ctx->stream)
   etna_cmd_stream_del(ctx->stream);
 
+   if (ctx->stream2d)
+  etna_cmd_stream_del(ctx->stream2d);
+
slab_destroy_child(>transfer_pool);
 
if (ctx->in_fence_fd != -1)
@@ -434,6 +437,9 @@ etna_context_create(struct pipe_screen *pscreen, void 
*priv, unsigned flags)
if (ctx->stream == NULL)
   goto fail;
 
+   if (screen->pipe2d)
+  ctx->stream2d = etna_cmd_stream_new(screen->pipe2d, 0x1000, NULL, NULL);
+
/* context ctxate setup */
ctx->specs = screen->specs;
ctx->screen = screen;
diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
b/src/gallium/drivers/etnaviv/etnaviv_context.h
index a79d739100d9..2c6e5d6c3db1 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_context.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
@@ -110,6 +110,7 @@ struct etna_context {
struct etna_specs specs;
struct etna_screen *screen;
struct etna_cmd_stream *stream;
+   struct etna_cmd_stream *stream2d;
 
/* which state objects need to be re-emit'd: */
enum {
diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index 62b6f1c80fae..0dea6056c75a 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -95,6 +95,12 @@ etna_screen_destroy(struct pipe_screen *pscreen)
if (screen->gpu)
   etna_gpu_del(screen->gpu);
 
+   if (screen->pipe2d)
+  etna_pipe_del(screen->pipe2d);
+
+   if (screen->gpu2d)
+  etna_gpu_del(screen->gpu2d);
+
if (screen->ro)
   FREE(screen->ro);
 
@@ -891,6 +897,66 @@ etna_screen_bo_from_handle(struct pipe_screen *pscreen,
return bo;
 }
 
+static void etna_screen_init_2d(struct etna_screen *screen)
+{
+   struct etna_gpu *gpu2d = NULL;
+   uint64_t val;
+   int ret, i;
+
+   /* If the current GPU is a combined 2d/3D core, use it as 2D engine */
+   if (screen->features[0] & chipFeatures_PIPE_2D)
+  gpu2d = screen->gpu;
+
+   /* otherwise search for a 2D capable core */
+   if (!gpu2d) {
+  for (i = 0;; i++) {
+ gpu2d = etna_gpu_new(screen->dev, i);
+ if (!gpu2d)
+return;
+
+ ret = etna_gpu_get_param(gpu2d, ETNA_GPU_FEATURES_0, );
+ if (!ret && (val & chipFeatures_PIPE_2D)) {
+screen->gpu2d = gpu2d;
+break;
+ }
+
+ etna_gpu_del(gpu2d);
+  }
+   }
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_0, ))
+  return;
+   screen->features2d[0] = val;
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_1, ))
+  return;
+   screen->features2d[1] = val;
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_2, ))
+  return;
+   screen->features2d[2] = val;
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_3, ))
+  return;
+   screen->features2d[3] = val;
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_4, ))
+  return;
+   screen->features2d[4] = val;
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_5, ))
+  return;
+   screen->features2d[5] = val;
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_6, ))
+  return;
+   screen->features2d[6] = val;
+
+   screen->pipe2d = etna_pipe_new(gpu2d, ETNA_PIPE_2D);
+   if (!screen->pipe2d)
+  DBG("could not create 2d pipe");
+}
+
 struct pipe_screen *
 etna_screen_create(struct etna_device *dev, struct etna_gpu *gpu,
struct renderonly *ro)
@@ -984,6 +1050,8 @@ etna_screen_create(struct etna_device *dev, struct 
etna_gpu *gpu,
}
screen->features[6] = val;
 
+   etna_screen_init_2d(screen);
+
if (!etna_get_specs(screen))
   goto fail;
 
diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.h 
b/src/gallium/drivers/etnaviv/etnaviv_screen.h
index 9757985526ec..82733a379430 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.h
@@ -60,6 +60,9 @@ enum viv_features_word {
 #define VIV_FEATURE(screen, word, feature) \
((screen->features[viv_ ## wor

[Mesa-dev] [PATCH 7/8] etnaviv: improve PIPE_BIND_LINEAR handling

[Lucas Stach]

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 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 f405b880a6c0..650c8e7eb7f5 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -369,6 +369,14 @@ etna_resource_create(struct pipe_screen *pscreen,
if (templat->target == PIPE_TEXTURE_3D)
   layout = ETNA_LAYOUT_LINEAR;
 
+   /* The render pipe can't handle linear and there is no code to do yet 
another
+* layout transformation for this case, so we only respect the linear flag
+* if the resource isn't meant to be rendered.
+*/
+   if ((templat->bind & PIPE_BIND_LINEAR) &&
+   !(templat->bind & PIPE_BIND_RENDER_TARGET))
+  layout = ETNA_LAYOUT_LINEAR;
+
/* modifier is only used for scanout surfaces, so safe to use LINEAR here */
return etna_resource_alloc(pscreen, layout, mode, DRM_FORMAT_MOD_LINEAR, 
templat);
 }
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/8] etnaviv: clear out next pointer when allocating resource

[Lucas Stach]

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/drivers/etnaviv/etnaviv_resource.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index 83179d3cd088..77d027ac806b 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -274,6 +274,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, unsigned 
layout,
   return NULL;
 
rsc->base = *templat;
+   rsc->base.next = NULL;
rsc->base.screen = pscreen;
rsc->base.nr_samples = nr_samples;
rsc->layout = layout;
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 6/8] etnaviv: use filter blit for 2D YUV import on old GC320

[Lucas Stach]

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 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 | 198 ---
 1 file changed, 180 insertions(+), 18 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_2d.c 
b/src/gallium/drivers/etnaviv/etnaviv_2d.c
index 457fa4e0cbd0..31b6bf4313dd 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_2d.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_2d.c
@@ -25,13 +25,16 @@
 #include "etnaviv_context.h"
 #include "etnaviv_emit.h"
 #include "etnaviv_screen.h"
+#include "etnaviv_rs.h"
 
 #include "pipe/p_state.h"
 #include "util/u_format.h"
 
 #include "hw/state_2d.xml.h"
+#include "hw/common.xml.h"
 
 #include 
+#include 
 
 #define EMIT_STATE(state_name, src_value) \
etna_coalsence_emit(stream, , VIVS_##state_name, src_value)
@@ -39,15 +42,85 @@
 #define EMIT_STATE_RELOC(state_name, src_value) \
etna_coalsence_emit_reloc(stream, , VIVS_##state_name, src_value)
 
+/* stolen from xf86-video-armada */
+#define KERNEL_ROWS 17
+#define KERNEL_INDICES  9
+#define KERNEL_SIZE (KERNEL_ROWS * KERNEL_INDICES)
+#define KERNEL_STATE_SZ ((KERNEL_SIZE + 1) / 2)
+
+static bool filter_kernel_initialized;
+static uint32_t filter_kernel[KERNEL_STATE_SZ];
+
+static inline float
+sinc (float x)
+{
+  return x != 0.0 ? sinf (x) / x : 1.0;
+}
+
+static void
+etnaviv_init_filter_kernel(void)
+{
+   unsigned row, idx, i;
+   int16_t kernel_val[KERNEL_STATE_SZ * 2];
+   float row_ofs = 0.5;
+   float radius = 4.0;
+
+   /* Compute lanczos filter kernel */
+   for (row = i = 0; row < KERNEL_ROWS; row++) {
+  float kernel[KERNEL_INDICES] = { 0.0 };
+  float sum = 0.0;
+
+  for (idx = 0; idx < KERNEL_INDICES; idx++) {
+ float x = idx - 4.0 + row_ofs;
+
+ if (fabs (x) <= radius)
+kernel[idx] = sinc (M_PI * x) * sinc (M_PI * x / radius);
+
+ sum += kernel[idx];
+   }
+
+   /* normalise the row */
+   if (sum)
+  for (idx = 0; idx < KERNEL_INDICES; idx++)
+ kernel[idx] /= sum;
+
+   /* convert to 1.14 format */
+   for (idx = 0; idx < KERNEL_INDICES; idx++) {
+  int val = kernel[idx] * (float) (1 << 14);
+
+  if (val < -0x8000)
+ val = -0x8000;
+  else if (val > 0x7fff)
+ val = 0x7fff;
+
+  kernel_val[i++] = val;
+   }
+
+   row_ofs -= 1.0 / ((KERNEL_ROWS - 1) * 2);
+   }
+
+   kernel_val[KERNEL_SIZE] = 0;
+
+   /* Now convert the kernel values into state values */
+   for (i = 0; i < KERNEL_STATE_SZ * 2; i += 2)
+  filter_kernel[i / 2] =
+ VIVS_DE_FILTER_KERNEL_COEFFICIENT0 (kernel_val[i]) |
+ VIVS_DE_FILTER_KERNEL_COEFFICIENT1 (kernel_val[i + 1]);
+}
+
 bool etna_try_2d_blit(struct pipe_context *pctx,
   const struct pipe_blit_info *blit_info)
 {
struct etna_context *ctx = etna_context(pctx);
+   struct etna_screen *screen = ctx->screen;
struct etna_cmd_stream *stream = ctx->stream2d;
struct etna_coalesce coalesce;
struct etna_reloc ry, ru, rv, rdst;
struct pipe_resource *res_y, *res_u, *res_v, *res_dst;
+   struct etna_bo *temp_bo = NULL;
uint32_t src_format;
+   bool ext_blt = VIV_2D_FEATURE(screen, chipMinorFeatures2, 2D_TILING);
+   uint32_t dst_config;
 
assert(util_format_is_yuv(blit_info->src.format));
assert(blit_info->dst.format == PIPE_FORMAT_R8G8B8A8_UNORM);
@@ -55,6 +128,11 @@ bool etna_try_2d_blit(struct pipe_context *pctx,
if (!stream)
   return FALSE;
 
+  if (unlikely(!ext_blt && !filter_kernel_initialized)) {
+  etnaviv_init_filter_kernel();
+  filter_kernel_initialized = true;
+  }
+
switch (blit_info->src.format) {
case PIPE_FORMAT_NV12:
   src_format = DE_FORMAT_NV12;
@@ -66,6 +144,18 @@ bool etna_try_2d_blit(struct pipe_context *pctx,
   return FALSE;
}
 
+   res_dst = blit_info->dst.resource;
+
+   if (!ext_blt && etna_resource(res_dst)->layout != ETNA_LAYOUT_LINEAR) {
+  struct etna_resource *dst = etna_resource(blit_info->dst.resource);
+  unsigned int bo_size = dst->levels[blit_info->dst.level].stride *
+ dst->levels[blit_info->dst.level].padded_height;
+
+  temp_bo = etna_bo_new(screen->dev, bo_size, DRM_ETNA_GEM_CACHE_WC);
+  if (!temp_bo)
+ return FALSE;
+   }
+
res_y = blit_info->src.resource;
res_u = res_y->next 

[Mesa-dev] [PATCH 8/8] etnaviv: handle YUV textures with the 2D GPU

[Lucas Stach]

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/etnaviv_format.c  |  5 +++-
 .../drivers/etnaviv/etnaviv_resource.c| 16 
 src/gallium/drivers/etnaviv/etnaviv_rs.c  |  5 
 src/gallium/drivers/etnaviv/etnaviv_screen.c  |  5 +++-
 src/gallium/drivers/etnaviv/etnaviv_texture.c | 25 ---
 6 files changed, 46 insertions(+), 12 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
index 45c30cbf5076..5214162d8798 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
@@ -159,7 +159,7 @@ etna_copy_resource(struct pipe_context *pctx, struct 
pipe_resource *dst,
struct etna_resource *src_priv = etna_resource(src);
struct etna_resource *dst_priv = etna_resource(dst);
 
-   assert(src->format == dst->format);
+   assert(src->format == dst->format || util_format_is_yuv(src->format));
assert(src->array_size == dst->array_size);
assert(last_level <= dst->last_level && last_level <= src->last_level);
 
diff --git a/src/gallium/drivers/etnaviv/etnaviv_format.c 
b/src/gallium/drivers/etnaviv/etnaviv_format.c
index 29e81c4a8b04..0879ddd6a6c8 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_format.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_format.c
@@ -282,8 +282,11 @@ static struct etna_format formats[PIPE_FORMAT_COUNT] = {
_T(ASTC_12x12_SRGB, ASTC_SRGB8_ALPHA8_12x12 | ASTC_FORMAT,  SWIZ(X, 
Y, Z, W), NONE, NONE),
 
/* YUV */
-   _T(YUYV, YUY2, SWIZ(X, Y, Z, W), YUY2, NONE),
+   _T(YUYV, X8B8G8R8, SWIZ(X, Y, Z, W), NONE, NONE),
_T(UYVY, UYVY, SWIZ(X, Y, Z, W), NONE, NONE),
+
+   /* multi-planar YUV */
+   _T(NV12, X8B8G8R8, SWIZ(X, Y, Z, W), NONE, NONE),
 };
 
 uint32_t
diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index 650c8e7eb7f5..5ba3eba5bd33 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -560,6 +560,17 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
   
level->padded_height);
level->size = level->layer_stride;
 
+   rsc->pending_ctx = _mesa_set_create(NULL, _mesa_hash_pointer,
+   _mesa_key_pointer_equal);
+   if (!rsc->pending_ctx)
+  goto fail;
+
+   /* YUV resources are handled by the 2D GPU, so the below constraint checks
+* are invalid.
+*/
+   if (util_format_is_yuv(tmpl->format))
+  return prsc;
+
/* The DDX must give us a BO which conforms to our padding size.
 * The stride of the BO must be greater or equal to our padded
 * stride. The size of the BO must accomodate the padded height. */
@@ -576,11 +587,6 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
   goto fail;
}
 
-   rsc->pending_ctx = _mesa_set_create(NULL, _mesa_hash_pointer,
-   _mesa_key_pointer_equal);
-   if (!rsc->pending_ctx)
-  goto fail;
-
if (rsc->layout == ETNA_LAYOUT_LINEAR) {
   /*
* Both sampler and pixel pipes can't handle linear, create a compatible
diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
b/src/gallium/drivers/etnaviv/etnaviv_rs.c
index fcc2342aedc3..22d07d8f9726 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
@@ -26,6 +26,7 @@
 
 #include "etnaviv_rs.h"
 
+#include "etnaviv_2d.h"
 #include "etnaviv_clear_blit.h"
 #include "etnaviv_context.h"
 #include "etnaviv_emit.h"
@@ -775,6 +776,10 @@ etna_blit_rs(struct pipe_context *pctx, const struct 
pipe_blit_info *blit_info)
   return;
}
 
+   if (util_format_is_yuv(blit_info->src.format) &&
+   etna_try_2d_blit(pctx, blit_info))
+  return;
+
if (etna_try_rs_blit(pctx, blit_info))
   return;
 
diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index 0dea6056c75a..b0630e27b507 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -535,6 +535,9 @@ gpu_supports_texure_format(struct etna_screen *screen, 
uint32_t fmt,
   supported = screen->specs.tex_astc;
}
 
+   if (util_format_is_yuv(format))
+  supported = !!screen->gpu2d;
+
if (!supported)
   return false;
 
@@ -658,7 +661,7 @@ etna_screen_query_dmabuf_modifiers(struct pipe_screen 
*pscreen,
   if (modifiers)
  modifiers[num_modifiers] = supported_modifiers[i];
   if 

[Mesa-dev] [PATCH 3/8] etnaviv: remember data offset into BO

[Lucas Stach]

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/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index 77d027ac806b..f405b880a6c0 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -535,6 +535,7 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
 
level->width = tmpl->width0;
level->height = tmpl->height0;
+   level->offset = handle->offset;
 
/* Determine padding of the imported resource. */
unsigned paddingX = 0, paddingY = 0;
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/8] etnaviv: add 2D GPU YUV->RGB blitter

[Lucas Stach]

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 ++
 src/gallium/drivers/etnaviv/etnaviv_2d.h  |   37 +
 src/gallium/drivers/etnaviv/hw/state_2d.xml.h | 1499 +
 src/gallium/drivers/etnaviv/meson.build   |3 +
 5 files changed, 1705 insertions(+)
 create mode 100644 src/gallium/drivers/etnaviv/etnaviv_2d.c
 create mode 100644 src/gallium/drivers/etnaviv/etnaviv_2d.h
 create mode 100644 src/gallium/drivers/etnaviv/hw/state_2d.xml.h

diff --git a/src/gallium/drivers/etnaviv/Makefile.sources 
b/src/gallium/drivers/etnaviv/Makefile.sources
index 01e7e49a38ad..36dd7d1b6aa4 100644
--- a/src/gallium/drivers/etnaviv/Makefile.sources
+++ b/src/gallium/drivers/etnaviv/Makefile.sources
@@ -3,11 +3,13 @@ C_SOURCES :=  \
hw/common.xml.h \
hw/common_3d.xml.h \
hw/isa.xml.h \
+   hw/state_2d.xml.h \
hw/state_3d.xml.h \
hw/state_blt.xml.h \
hw/state.xml.h \
hw/texdesc_3d.xml.h \
\
+   etnaviv_2d.c \
etnaviv_asm.c \
etnaviv_asm.h \
etnaviv_blend.c \
diff --git a/src/gallium/drivers/etnaviv/etnaviv_2d.c 
b/src/gallium/drivers/etnaviv/etnaviv_2d.c
new file mode 100644
index ..457fa4e0cbd0
--- /dev/null
+++ b/src/gallium/drivers/etnaviv/etnaviv_2d.c
@@ -0,0 +1,164 @@
+/*
+ * Copyright (c) 2018 Etnaviv Project
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include "etnaviv_2d.h"
+#include "etnaviv_context.h"
+#include "etnaviv_emit.h"
+#include "etnaviv_screen.h"
+
+#include "pipe/p_state.h"
+#include "util/u_format.h"
+
+#include "hw/state_2d.xml.h"
+
+#include 
+
+#define EMIT_STATE(state_name, src_value) \
+   etna_coalsence_emit(stream, , VIVS_##state_name, src_value)
+
+#define EMIT_STATE_RELOC(state_name, src_value) \
+   etna_coalsence_emit_reloc(stream, , VIVS_##state_name, src_value)
+
+bool etna_try_2d_blit(struct pipe_context *pctx,
+  const struct pipe_blit_info *blit_info)
+{
+   struct etna_context *ctx = etna_context(pctx);
+   struct etna_cmd_stream *stream = ctx->stream2d;
+   struct etna_coalesce coalesce;
+   struct etna_reloc ry, ru, rv, rdst;
+   struct pipe_resource *res_y, *res_u, *res_v, *res_dst;
+   uint32_t src_format;
+
+   assert(util_format_is_yuv(blit_info->src.format));
+   assert(blit_info->dst.format == PIPE_FORMAT_R8G8B8A8_UNORM);
+
+   if (!stream)
+  return FALSE;
+
+   switch (blit_info->src.format) {
+   case PIPE_FORMAT_NV12:
+  src_format = DE_FORMAT_NV12;
+  break;
+   case PIPE_FORMAT_YUYV:
+  src_format = DE_FORMAT_YUY2;
+  break;
+   default:
+  return FALSE;
+   }
+
+   res_y = blit_info->src.resource;
+   res_u = res_y->next ? res_y->next : res_y;
+   res_v = res_u->next ? res_u->next : res_u;
+
+   ry.bo = etna_resource(res_y)->bo;
+   ry.offset = etna_resource(res_y)->levels[blit_info->src.level].offset;
+   ru.bo = etna_resource(res_u)->bo;
+   ru.offset = etna_resource(res_u)->levels[blit_info->src.level].offset;
+   rv.bo = etna_resource(res_v)->bo;
+   rv.offset = etna_resource(res_v)->levels[blit_info->src.level].offset;
+
+   ry.flags = ru.flags = rv.flags = ETNA_RELOC_READ;
+
+   res_dst = blit_info->dst.resource;
+   rdst.bo = etna_resource(res_dst)->bo;
+   rdst.flags = ETNA_RELOC_WRITE;
+   rdst.offset = 0;
+
+   etna_coalesce_start(stream, );
+
+   EMIT_STATE_RELOC(DE_SRC_ADDRESS, );
+   EMIT_STATE(DE_SRC_STRIDE, etna_resource(res_y)->levels[0].stride);
+
+   EMIT_STATE_RELOC(DE_UPLANE_ADDRESS, );
+   EMIT_STATE(DE_UPLANE_ST

[Mesa-dev] [PATCH 5/8] etnaviv: export etna_submit_rs_state

[Lucas Stach]

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_rs.c 
b/src/gallium/drivers/etnaviv/etnaviv_rs.c
index a9d3872ad41b..fcc2342aedc3 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
@@ -171,7 +171,7 @@ etna_modify_rs_clearbits(struct compiled_rs_state *cs, 
uint32_t clear_bits)
 
 /* submit RS state, without any processing and no dependence on context
  * except TS if this is a source-to-destination blit. */
-static void
+void
 etna_submit_rs_state(struct etna_context *ctx,
  const struct compiled_rs_state *cs)
 {
diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.h 
b/src/gallium/drivers/etnaviv/etnaviv_rs.h
index 125a13a9ad34..81ef05955a79 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_rs.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_rs.h
@@ -84,6 +84,10 @@ void
 etna_compile_rs_state(struct etna_context *ctx, struct compiled_rs_state *cs,
   const struct rs_state *rs);
 
+void
+etna_submit_rs_state(struct etna_context *ctx,
+ const struct compiled_rs_state *cs);
+
 /* Context initialization for RS clear_blit functions. */
 void
 etna_clear_blit_rs_init(struct pipe_context *pctx);
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/6] st/dri: fix dri2_from_planar for multiplanar images

[Lucas Stach]

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 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index 4c8ea485cc70..f139bd6722b9 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1275,10 +1275,18 @@ static __DRIimage *
 dri2_from_planar(__DRIimage *image, int plane, void *loaderPrivate)
 {
__DRIimage *img;
+   struct pipe_resource *tex = image->texture;
+   int i;
 
-   if (plane != 0)
+   if (plane >= 3)
   return NULL;
 
+   for (i = 0; i < plane; i++) {
+  tex = tex->next;
+  if (!tex)
+ return NULL;
+   }
+
if (image->dri_components == 0)
   return NULL;
 
@@ -1286,6 +1294,8 @@ dri2_from_planar(__DRIimage *image, int plane, void 
*loaderPrivate)
if (img == NULL)
   return NULL;
 
+   pipe_resource_reference(>texture, tex);
+
if (img->texture->screen->resource_changed)
   img->texture->screen->resource_changed(img->texture->screen,
  img->texture);
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/6] st/dri: don't re-write plane format if supported by driver

[Lucas Stach]

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 insertions(+), 10 deletions(-)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index 4243a00cb38d..38a8e28ff439 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -776,6 +776,24 @@ dri2_update_tex_buffer(struct dri_drawable *drawable,
/* no-op */
 }
 
+static enum pipe_format get_plane_format(struct pipe_screen *pscreen,
+ enum pipe_format pf,
+ enum pipe_texture_target target,
+ unsigned usage, int plane)
+{
+
+   /* If the driver supports the format natively, no need to re-write */
+   if (pscreen->is_format_supported(pscreen, pf, target, 0, 0, usage))
+  return pf;
+
+   if (pf == PIPE_FORMAT_IYUV || (pf == PIPE_FORMAT_NV12 && plane == 0))
+  return PIPE_FORMAT_R8_UNORM;
+
+   if (pf == PIPE_FORMAT_NV12 && plane == 1)
+  return PIPE_FORMAT_RG88_UNORM;
+
+   return PIPE_FORMAT_NONE;
+}
 static __DRIimage *
 dri2_create_image_from_winsys(__DRIscreen *_screen,
   int width, int height, enum pipe_format pf,
@@ -800,9 +818,9 @@ dri2_create_image_from_winsys(__DRIscreen *_screen,
   /* YUV format sampling can be emulated by the Mesa state tracker by
* using multiple R8/RG88 samplers. So try to rewrite the pipe format.
*/
-  pf = PIPE_FORMAT_R8_UNORM;
 
-  if (pscreen->is_format_supported(pscreen, pf, screen->target, 0, 0,
+  if (pscreen->is_format_supported(pscreen, PIPE_FORMAT_R8_UNORM,
+   screen->target, 0, 0,
PIPE_BIND_SAMPLER_VIEW))
  tex_usage |= PIPE_BIND_SAMPLER_VIEW;
}
@@ -829,24 +847,18 @@ dri2_create_image_from_winsys(__DRIscreen *_screen,
   case 0:
  templ.width0 = width;
  templ.height0 = height;
- templ.format = pf;
  break;
   case 1:
- templ.width0 = width / 2;
- templ.height0 = height / 2;
- templ.format = (num_handles == 2) ?
-   PIPE_FORMAT_RG88_UNORM :   /* NV12, etc */
-   PIPE_FORMAT_R8_UNORM;  /* I420, etc */
- break;
   case 2:
  templ.width0 = width / 2;
  templ.height0 = height / 2;
- templ.format = PIPE_FORMAT_R8_UNORM;
  break;
   default:
  unreachable("too many planes!");
   }
 
+  templ.format = get_plane_format(pscreen, pf, screen->target, tex_usage, 
i);
+
   tex = pscreen->resource_from_handle(pscreen,
 , [i], PIPE_HANDLE_USAGE_FRAMEBUFFER_WRITE);
   if (!tex) {
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 6/6] st/mesa: skip any extra handling of YUV textures if driver supports them

[Lucas Stach]

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  |  6 ++
 src/mesa/state_tracker/st_sampler_view.c | 21 +
 4 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_sampler.c 
b/src/mesa/state_tracker/st_atom_sampler.c
index 27e4da315817..9def70c9432a 100644
--- a/src/mesa/state_tracker/st_atom_sampler.c
+++ b/src/mesa/state_tracker/st_atom_sampler.c
@@ -303,10 +303,16 @@ update_shader_samplers(struct st_context *st,
   struct st_texture_object *stObj =
 st_get_texture_object(st->ctx, prog, unit);
   struct pipe_sampler_state *sampler = samplers + unit;
+  struct pipe_screen *pscreen = st->pipe->screen;
 
   if (!stObj)
  continue;
 
+  if (pscreen->is_format_supported(pscreen, st_get_view_format(stObj),
+   PIPE_TEXTURE_2D, 0, 0,
+   PIPE_BIND_SAMPLER_VIEW))
+ continue;
+
   switch (st_get_view_format(stObj)) {
   case PIPE_FORMAT_NV12:
  /* we need one additional sampler: */
diff --git a/src/mesa/state_tracker/st_atom_texture.c 
b/src/mesa/state_tracker/st_atom_texture.c
index ce7755f0c588..df84a472e722 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -174,11 +174,17 @@ update_textures(struct st_context *st,
   GLuint extra = 0;
   struct st_texture_object *stObj =
 st_get_texture_object(st->ctx, prog, unit);
+  struct pipe_screen *pscreen = st->pipe->screen;
   struct pipe_sampler_view tmpl;
 
   if (!stObj)
  continue;
 
+  if (pscreen->is_format_supported(pscreen, st_get_view_format(stObj),
+   sampler_views[unit]->target, 0, 0,
+   PIPE_BIND_SAMPLER_VIEW))
+ continue;
+
   /* use original view as template: */
   tmpl = *sampler_views[unit];
 
diff --git a/src/mesa/state_tracker/st_program.h 
b/src/mesa/state_tracker/st_program.h
index f67ea5eb2087..bc5f3e3d9642 100644
--- a/src/mesa/state_tracker/st_program.h
+++ b/src/mesa/state_tracker/st_program.h
@@ -67,6 +67,12 @@ st_get_external_sampler_key(struct st_context *st, struct 
gl_program *prog)
   unsigned unit = u_bit_scan();
   struct st_texture_object *stObj =
 st_get_texture_object(st->ctx, prog, unit);
+  struct pipe_screen *pscreen = st->pipe->screen;
+
+  if (pscreen->is_format_supported(pscreen, st_get_view_format(stObj),
+   PIPE_TEXTURE_2D, 0, 0,
+   PIPE_BIND_SAMPLER_VIEW))
+ continue;
 
   switch (st_get_view_format(stObj)) {
   case PIPE_FORMAT_NV12:
diff --git a/src/mesa/state_tracker/st_sampler_view.c 
b/src/mesa/state_tracker/st_sampler_view.c
index eb97f2bb6b7d..30dfa20af6b5 100644
--- a/src/mesa/state_tracker/st_sampler_view.c
+++ b/src/mesa/state_tracker/st_sampler_view.c
@@ -471,6 +471,7 @@ get_sampler_view_format(struct st_context *st,
 const struct st_texture_object *stObj,
 bool srgb_skip_decode)
 {
+   struct pipe_screen *pscreen = st->pipe->screen;
enum pipe_format format;
 
GLenum baseFormat = _mesa_base_tex_image(>base)->_BaseFormat;
@@ -489,15 +490,19 @@ get_sampler_view_format(struct st_context *st,
if (srgb_skip_decode)
   format = util_format_linear(format);
 
-   /* Use R8_UNORM for video formats */
-   switch (format) {
-   case PIPE_FORMAT_NV12:
-   case PIPE_FORMAT_IYUV:
-  format = PIPE_FORMAT_R8_UNORM;
-  break;
-   default:
-  break;
+   if (!pscreen->is_format_supported(pscreen, format, PIPE_TEXTURE_2D, 0, 0,
+ PIPE_BIND_SAMPLER_VIEW)) {
+  /* Use R8_UNORM for video formats */
+  switch (format) {
+  case PIPE_FORMAT_NV12:
+  case PIPE_FORMAT_IYUV:
+ format = PIPE_FORMAT_R8_UNORM;
+ break;
+  default:
+ break;
+  }
}
+
return format;
 }
 
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/6] st/dri: handle emulated YUV texture sampling in query_dma_buf_modifiers

[Lucas Stach]

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 formats, without the need to take a special
code path for the emulated OES_external texture handling.

Signed-off-by: Lucas Stach 
---
 src/gallium/state_trackers/dri/dri2.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index f139bd6722b9..4243a00cb38d 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1358,19 +1358,30 @@ dri2_query_dma_buf_modifiers(__DRIscreen *_screen, int 
fourcc, int max,
const struct dri2_format_mapping *map = dri2_get_mapping_by_fourcc(fourcc);
enum pipe_format format;
 
-   if (!map)
+   if (!map || !pscreen->query_dmabuf_modifiers)
   return false;
 
format = map->pipe_format;
 
-   if (pscreen->query_dmabuf_modifiers != NULL &&
-   (pscreen->is_format_supported(pscreen, format, screen->target, 0, 0,
+   if ((pscreen->is_format_supported(pscreen, format, screen->target, 0, 0,
  PIPE_BIND_RENDER_TARGET) ||
 pscreen->is_format_supported(pscreen, format, screen->target, 0, 0,
  PIPE_BIND_SAMPLER_VIEW))) {
   pscreen->query_dmabuf_modifiers(pscreen, format, max, modifiers,
   external_only, count);
   return true;
+   } else if (util_format_is_yuv(format) &&
+  pscreen->is_format_supported(pscreen, PIPE_FORMAT_R8_UNORM,
+   screen->target, 0, 0,
+   PIPE_BIND_SAMPLER_VIEW)) {
+  /* YUV format sampling can be emulated by the Mesa state tracker by
+   * using multiple R8/RG88 samplers if the driver doesn't support those
+   * formats natively, so we need a special case here to give a mostly
+   * accurate answer to the modifiers query.
+   */
+  pscreen->query_dmabuf_modifiers(pscreen, PIPE_FORMAT_R8_UNORM, max,
+  modifiers, external_only, count);
+  return true;
}
return false;
 }
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/6] st/dri: fix dri2_query_image for multiplanar images

[Lucas Stach]

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_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index 510b7f8d04a7..4c8ea485cc70 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1083,7 +1083,9 @@ static GLboolean
 dri2_query_image(__DRIimage *image, int attrib, int *value)
 {
struct winsys_handle whandle;
+   struct pipe_resource *tex;
unsigned usage;
+   int i;
 
if (image->use & __DRI_IMAGE_USE_BACKBUFFER)
   usage = PIPE_HANDLE_USAGE_EXPLICIT_FLUSH;
@@ -1157,7 +1159,9 @@ dri2_query_image(__DRIimage *image, int attrib, int 
*value)
   }
   return GL_TRUE;
case __DRI_IMAGE_ATTRIB_NUM_PLANES:
-  *value = 1;
+  for (i = 0, tex = image->texture; i < 4 && tex; tex = tex->next)
+ i++;
+  *value = i;
   return GL_TRUE;
case __DRI_IMAGE_ATTRIB_MODIFIER_UPPER:
   whandle.type = WINSYS_HANDLE_TYPE_KMS;
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/6] st/dri: allow to create image for formats that only support SV or RT binding

[Lucas Stach]

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/gallium/state_trackers/dri/dri2.c
index efb43c0d7973..510b7f8d04a7 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -987,14 +987,23 @@ dri2_create_image_common(__DRIscreen *_screen,
 {
const struct dri2_format_mapping *map = dri2_get_mapping_by_format(format);
struct dri_screen *screen = dri_screen(_screen);
+   struct pipe_screen *pscreen = screen->base.screen;
__DRIimage *img;
struct pipe_resource templ;
-   unsigned tex_usage;
+   unsigned tex_usage = 0;
 
if (!map)
   return NULL;
 
-   tex_usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
+   if (pscreen->is_format_supported(pscreen, map->pipe_format, screen->target,
+0, 0, PIPE_BIND_RENDER_TARGET))
+  tex_usage |= PIPE_BIND_RENDER_TARGET;
+   if (pscreen->is_format_supported(pscreen, map->pipe_format, screen->target,
+0, 0, PIPE_BIND_SAMPLER_VIEW))
+  tex_usage |= PIPE_BIND_SAMPLER_VIEW;
+
+   if (!tex_usage)
+  return NULL;
 
if (use & __DRI_IMAGE_USE_SCANOUT)
   tex_usage |= PIPE_BIND_SCANOUT;
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] gallium: ddebug: Add missing fence related wrappers

[Lucas Stach]

Am Mittwoch, den 03.04.2019, 13:08 +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/state_trackers/dri/dri_helpers.c:140
>   #2  0xa8744824 in dri2_dup_native_fence_fd (drv=0xed5010c0, 
> disp=0xed5029a0, sync=0xed9ef7c0) at 
> ../src/egl/drivers/dri2/egl_dri2.c:3050
>   #3  0xa87339b8 in eglDupNativeFenceFDANDROID (dpy=0xed5029a0, 
> sync=0xed9ef7c0) at ../src/egl/main/eglapi.c:2107
>   #4  0xbd29ca90 in  ()
>   #5  0xbd401000 in  ()
> 
> Signed-off-by: Guido Günther 

Reviewed-by: Lucas Stach 

> 
> ---
> Changes from v1:
> - Drop duplicate dd_context_flush() as noticed by Lucas Stach
> ---
>  .../auxiliary/driver_ddebug/dd_context.c  | 27 +++
>  .../auxiliary/driver_ddebug/dd_screen.c   | 10 +++
>  2 files changed, 37 insertions(+)
> 
> diff --git a/src/gallium/auxiliary/driver_ddebug/dd_context.c 
> b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> index 4ea0b16de6f..ab3043a8b87 100644
> --- a/src/gallium/auxiliary/driver_ddebug/dd_context.c
> +++ b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> @@ -575,6 +575,31 @@ dd_context_set_stream_output_targets(struct pipe_context 
> *_pipe,
> pipe->set_stream_output_targets(pipe, num_targets, tgs, offsets);
>  }
>  
> +
> +static void
> +dd_context_fence_server_sync(struct pipe_context *_pipe,
> + struct pipe_fence_handle *fence)
> +{
> +   struct dd_context *dctx = dd_context(_pipe);
> +   struct pipe_context *pipe = dctx->pipe;
> +
> +   pipe->fence_server_sync(pipe, fence);
> +}
> +
> +
> +static void
> +dd_context_create_fence_fd(struct pipe_context *_pipe,
> +   struct pipe_fence_handle **fence,
> +   int fd,
> +   enum pipe_fd_type type)
> +{
> +   struct dd_context *dctx = dd_context(_pipe);
> +   struct pipe_context *pipe = dctx->pipe;
> +
> +   pipe->create_fence_fd(pipe, fence, fd, type);
> +}
> +
> +
>  void
>  dd_thread_join(struct dd_context *dctx)
>  {
> @@ -867,6 +892,8 @@ dd_context_create(struct dd_screen *dscreen, struct 
> pipe_context *pipe)
> CTX_INIT(create_stream_output_target);
> CTX_INIT(stream_output_target_destroy);
> CTX_INIT(set_stream_output_targets);
> +   CTX_INIT(create_fence_fd);
> +   CTX_INIT(fence_server_sync);
> CTX_INIT(create_sampler_view);
> CTX_INIT(sampler_view_destroy);
> CTX_INIT(create_surface);
> diff --git a/src/gallium/auxiliary/driver_ddebug/dd_screen.c 
> b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> index a89af8a8d62..b2108adfa32 100644
> --- a/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> +++ b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> @@ -348,6 +348,15 @@ dd_screen_fence_finish(struct pipe_screen *_screen,
> return screen->fence_finish(screen, ctx, fence, timeout);
>  }
>  
> +static int
> +dd_screen_fence_get_fd(struct pipe_screen *_screen,
> +   struct pipe_fence_handle *fence)
> +{
> +   struct pipe_screen *screen = dd_screen(_screen)->screen;
> +
> +   return screen->fence_get_fd(screen, fence);
> +}
> +
>  /
>   * memobj
>   */
> @@ -550,6 +559,7 @@ ddebug_screen_create(struct pipe_screen *screen)
> SCR_INIT(flush_frontbuffer);
> SCR_INIT(fence_reference);
> SCR_INIT(fence_finish);
> +   SCR_INIT(fence_get_fd);
> SCR_INIT(memobj_create_from_handle);
> SCR_INIT(memobj_destroy);
> SCR_INIT(get_driver_query_info);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: ddebug: Add missing fence related wrappers

[Lucas Stach]

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/state_trackers/dri/dri_helpers.c:140
>   #2  0xa8744824 in dri2_dup_native_fence_fd (drv=0xed5010c0, 
> disp=0xed5029a0, sync=0xed9ef7c0) at 
> ../src/egl/drivers/dri2/egl_dri2.c:3050
>   #3  0xa87339b8 in eglDupNativeFenceFDANDROID (dpy=0xed5029a0, 
> sync=0xed9ef7c0) at ../src/egl/main/eglapi.c:2107
>   #4  0xbd29ca90 in  ()
>   #5  0xbd401000 in  ()
> 
> > Signed-off-by: Guido Günther 
> ---
> This is similar in spirit to the patches for GALLIUM_TRACE send out earlier.
> 
> 
>  .../auxiliary/driver_ddebug/dd_context.c  | 40 +++
>  .../auxiliary/driver_ddebug/dd_screen.c   | 10 +
>  2 files changed, 50 insertions(+)
> 
> diff --git a/src/gallium/auxiliary/driver_ddebug/dd_context.c 
> b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> index 4ea0b16de6f..3152c664630 100644
> --- a/src/gallium/auxiliary/driver_ddebug/dd_context.c
> +++ b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> @@ -575,6 +575,43 @@ dd_context_set_stream_output_targets(struct pipe_context 
> *_pipe,
> pipe->set_stream_output_targets(pipe, num_targets, tgs, offsets);
>  }
>  
> +
> +static void
> +dd_context_flush(struct pipe_context *_pipe,
> + struct pipe_fence_handle **fence,
> + unsigned flags)
> +{
> +   struct dd_context *dctx = dd_context(_pipe);
> +   struct pipe_context *pipe = dctx->pipe;
> +
> +   pipe->flush(pipe, fence, flags);
> +}

dd_context_flush() is already implemented in dd_draw.c

Regards,
Lucas

> +
> +
> +static void
> +dd_context_fence_server_sync(struct pipe_context *_pipe,
> + struct pipe_fence_handle *fence)
> +{
> +   struct dd_context *dctx = dd_context(_pipe);
> +   struct pipe_context *pipe = dctx->pipe;
> +
> +   pipe->fence_server_sync(pipe, fence);
> +}
> +
> +
> +static void
> +dd_context_create_fence_fd(struct pipe_context *_pipe,
> +   struct pipe_fence_handle **fence,
> +   int fd,
> +   enum pipe_fd_type type)
> +{
> +   struct dd_context *dctx = dd_context(_pipe);
> +   struct pipe_context *pipe = dctx->pipe;
> +
> +   pipe->create_fence_fd(pipe, fence, fd, type);
> +}
> +
> +
>  void
>  dd_thread_join(struct dd_context *dctx)
>  {
> @@ -867,6 +904,9 @@ dd_context_create(struct dd_screen *dscreen, struct 
> pipe_context *pipe)
> CTX_INIT(create_stream_output_target);
> CTX_INIT(stream_output_target_destroy);
> CTX_INIT(set_stream_output_targets);
> +   CTX_INIT(flush);
> +   CTX_INIT(create_fence_fd);
> +   CTX_INIT(fence_server_sync);
> CTX_INIT(create_sampler_view);
> CTX_INIT(sampler_view_destroy);
> CTX_INIT(create_surface);
> diff --git a/src/gallium/auxiliary/driver_ddebug/dd_screen.c 
> b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> index a89af8a8d62..b2108adfa32 100644
> --- a/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> +++ b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> @@ -348,6 +348,15 @@ dd_screen_fence_finish(struct pipe_screen *_screen,
> return screen->fence_finish(screen, ctx, fence, timeout);
>  }
>  
> +static int
> +dd_screen_fence_get_fd(struct pipe_screen *_screen,
> +   struct pipe_fence_handle *fence)
> +{
> +   struct pipe_screen *screen = dd_screen(_screen)->screen;
> +
> +   return screen->fence_get_fd(screen, fence);
> +}
> +
>  /
>   * memobj
>   */
> @@ -550,6 +559,7 @@ ddebug_screen_create(struct pipe_screen *screen)
> SCR_INIT(flush_frontbuffer);
> SCR_INIT(fence_reference);
> SCR_INIT(fence_finish);
> +   SCR_INIT(fence_get_fd);
> SCR_INIT(memobj_create_from_handle);
> SCR_INIT(memobj_destroy);
> SCR_INIT(get_driver_query_info);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: shrink struct etna_3d_state

[Lucas Stach]

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 -
>  src/gallium/drivers/etnaviv/etnaviv_internal.h |  6 --
>  2 files changed, 23 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> index f788896dd8..ed7b7ee3cb 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> @@ -250,21 +250,6 @@ etna_emit_state(struct etna_context *ctx)
>    etna_set_state(stream, VIVS_TS_FLUSH_CACHE, VIVS_TS_FLUSH_CACHE_FLUSH);
> }
>  
> -   /* If MULTI_SAMPLE_CONFIG.MSAA_SAMPLES changed, clobber affected shader
> -* state to make sure it is always rewritten. */
> -   if (unlikely(dirty & (ETNA_DIRTY_FRAMEBUFFER))) {
> -  if ((ctx->gpu3d.GL_MULTI_SAMPLE_CONFIG & 
> VIVS_GL_MULTI_SAMPLE_CONFIG_MSAA_SAMPLES__MASK) !=
> -  (ctx->framebuffer.GL_MULTI_SAMPLE_CONFIG & 
> VIVS_GL_MULTI_SAMPLE_CONFIG_MSAA_SAMPLES__MASK)) {
> - /* XXX what does the GPU set these states to on MSAA samples change?
> -  * Does it do the right thing?
> -  * (increase/decrease as necessary) or something else? Just set some
> -  * invalid value until we know for
> -  * sure. */
> - ctx->gpu3d.PS_INPUT_COUNT = 0x;
> - ctx->gpu3d.PS_TEMP_REGISTER_CONTROL = 0x;
> -  }
> -   }
> -
> /* Update vertex elements. This is different from any of the other 
> states, in that
>  * a) the number of vertex elements written matters: so write only active 
> ones
>  * b) the vertex element states must all be written: do not skip entries 
> that stay the same */
> @@ -693,8 +678,6 @@ etna_emit_state(struct etna_context *ctx)
>    /* Copy uniforms to gpu3d, so that incremental updates to uniforms are
> * possible as long as the
> * same shader remains bound */
> -  ctx->gpu3d.vs_uniforms_size = ctx->shader_state.vs_uniforms_size;
> -  ctx->gpu3d.ps_uniforms_size = ctx->shader_state.ps_uniforms_size;
>    memcpy(ctx->gpu3d.VS_UNIFORMS, ctx->shader_state.VS_UNIFORMS,
>   ctx->shader_state.vs_uniforms_size * 4);
>    memcpy(ctx->gpu3d.PS_UNIFORMS, ctx->shader_state.PS_UNIFORMS,
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_internal.h 
> b/src/gallium/drivers/etnaviv/etnaviv_internal.h
> index 77214d9ccb..29566dbd5e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_internal.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_internal.h
> @@ -270,12 +270,6 @@ struct compiled_shader_state {
>  
>  /* state of some 3d and common registers relevant to etna driver */
>  struct etna_3d_state {
> -   unsigned vs_uniforms_size;
> -   unsigned ps_uniforms_size;
> -
> -   uint32_t /*01008*/ PS_INPUT_COUNT;
> -   uint32_t /*0100C*/ PS_TEMP_REGISTER_CONTROL;
> -   uint32_t /*03818*/ GL_MULTI_SAMPLE_CONFIG;
> uint32_t /*05000*/ VS_UNIFORMS[VIVS_VS_UNIFORMS__LEN];
> uint32_t /*07000*/ PS_UNIFORMS[VIVS_PS_UNIFORMS__LEN];
>  };
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] etnaviv: only try to construct scanout resource when on KMS winsys

[Lucas Stach]

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 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index c7eedab74187..83179d3cd088 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -238,7 +238,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, unsigned 
layout,
if (!screen->specs.use_blt && templat->target != PIPE_BUFFER)
   etna_adjust_rs_align(screen->specs.pixel_pipes, NULL, );
 
-   if (templat->bind & PIPE_BIND_SCANOUT) {
+   if (templat->bind & PIPE_BIND_SCANOUT && screen->ro->kms_fd >= 0) {
   struct pipe_resource scanout_templat = *templat;
   struct renderonly_scanout *scanout;
   struct winsys_handle handle;
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] etnaviv: flush all pending contexts when accessing a resource with the CPU

[Lucas Stach]

When setting up a transfer to a resource, all contexts where the resource
is pending must be flushed. Otherwise a write transfer might be started
in the current context before all contexts that access the resource in
shared (read) mode have been executed.

Fixes: 64813541d575 (etnaviv: fix 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/etnaviv/etnaviv_transfer.c
index 45cd31207f70..d875803bde26 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
@@ -360,8 +360,14 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
   if ((trans->rsc && (etna_resource(trans->rsc)->status & 
ETNA_PENDING_WRITE)) ||
   (!trans->rsc &&
(((usage & PIPE_TRANSFER_READ) && (rsc->status & 
ETNA_PENDING_WRITE)) ||
-   ((usage & PIPE_TRANSFER_WRITE) && rsc->status
- pctx->flush(pctx, NULL, 0);
+   ((usage & PIPE_TRANSFER_WRITE) && rsc->status {
+ set_foreach(rsc->pending_ctx, entry) {
+struct etna_context *pend_ctx = (struct etna_context *)entry->key;
+struct pipe_context *pend_pctx = _ctx->base;
+
+pend_pctx->flush(pend_pctx, NULL, 0);
+ }
+  }
 
   mtx_unlock(>lock);
 
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] etnaviv: don't flush own context when updating resource use

[Lucas Stach]

The context is self synchronizing at the GPU side, as commands are
executed in order. We must not flush our own context when updating the
resource use, as that leads to excessive flushing on effectively every
draw call, causing huge CPU overhead.

Fixes: 64813541d575 (etnaviv: fix resource usage 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_resource.c
index ab40414fbe2c..c7eedab74187 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -666,9 +666,18 @@ etna_resource_used(struct etna_context *ctx, struct 
pipe_resource *prsc,
  struct etna_context *extctx = (struct etna_context *)entry->key;
  struct pipe_context *pctx = >base;
 
+ if (extctx == ctx)
+continue;
+
  pctx->flush(pctx, NULL, 0);
+ /* It's safe to clear the status here. If we need to flush it means
+  * either another context had the resource in exclusive (write) use,
+  * or we transition the resource to exclusive use in our context.
+  * In both cases the new status accurately reflects the resource use
+  * after the flush.
+  */
+ rsc->status = 0;
   }
-  rsc->status = 0;
}
 
rsc->status |= status;
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 3/4] etnaviv: hook-up etc2 patching

[Lucas Stach]

Am Donnerstag, den 28.02.2019, 07:26 +0100 schrieb Christian Gmeiner:
> Changes v1 -> v2:
>  - Avoid the GPU sampling from the resource that gets mutated by the the
>transfer map by setting DRM_ETNA_PREP_WRITE.
> 
> Changes v2 -> v3:
>  - make use of likely(..)
>  - drop minor optimization regarding rsc->layout == ETNA_LAYOUT_LINEAR
>  - better documentation why DRM_ETNA_PREP_WRITE is needed
> 
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  .../drivers/etnaviv/etnaviv_resource.c|  3 +
>  .../drivers/etnaviv/etnaviv_resource.h|  5 ++
>  .../drivers/etnaviv/etnaviv_transfer.c| 56 +++
>  3 files changed, 64 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index db5ead4d0ba..45d5f69169e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -478,6 +478,9 @@ etna_resource_destroy(struct pipe_screen *pscreen, struct 
> pipe_resource *prsc)
> pipe_resource_reference(>texture, NULL);
> pipe_resource_reference(>external, NULL);
>  
> +   for (unsigned i = 0; i < ETNA_NUM_LOD; i++)
> +  FREE(rsc->levels[i].patch_offsets);
> +
> FREE(rsc);
>  }
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 75aa80b3d7a..c45ff7586d1 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -33,6 +33,7 @@
>  #include "util/list.h"
>  
>  struct pipe_screen;
> +struct util_dynarray;
>  
>  struct etna_resource_level {
> unsigned width, padded_width; /* in pixels */
> @@ -47,6 +48,10 @@ struct etna_resource_level {
> uint32_t ts_size;
> uint32_t clear_value; /* clear value of resource level (mainly for TS) */
> bool ts_valid;
> +
> +   /* keep track if we have done some per block patching */
> +   bool patched;
> +   struct util_dynarray *patch_offsets;
>  };
>  
>  enum etna_resource_addressing_mode {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 01da393d211..3b925a8ef9f 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -28,6 +28,7 @@
>  #include "etnaviv_clear_blit.h"
>  #include "etnaviv_context.h"
>  #include "etnaviv_debug.h"
> +#include "etnaviv_etc2.h"
>  #include "etnaviv_screen.h"
>  
>  #include "pipe/p_defines.h"
> @@ -57,6 +58,46 @@ etna_compute_offset(enum pipe_format format, const struct 
> pipe_box *box,
>   util_format_get_blocksize(format);
>  }
>  
> +static void etna_patch_data(void *buffer, const struct pipe_transfer *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = >levels[ptrans->level];
> +
> +   if (likely(!etna_etc2_needs_patching(prsc)))
> +  return;
> +
> +   if (level->patched)
> +  return;
> +
> +   /* do have the offsets of blocks to patch? */
> +   if (!level->patch_offsets) {
> +  level->patch_offsets = CALLOC_STRUCT(util_dynarray);
> +
> +  etna_etc2_calculate_blocks(buffer, ptrans->stride,
> + ptrans->box.width, 
> ptrans->box.height,
> + prsc->format, level->patch_offsets);
> +   }
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = true;
> +}
> +
> +static void etna_unpatch_data(void *buffer, const struct pipe_transfer 
> *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = >levels[ptrans->level];
> +
> +   if (!level->patched)
> +  return;
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = false;
> +}
> +
>  static void
>  etna_transfer_unmap(struct pipe_context *pctx, struct pipe_transfer *ptrans)
>  {
> @@ -119,6 +160,9 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> pipe_transfer *ptrans)
>}
> }
>  
> +   /* We need to have the patched data ready for the GPU. */
> +   etna_patch_data(trans->mapped, ptrans);
> +
> /*
>  * Transfers without a temporary are only pulled into the CPU domain if 
> they
>

Re: [Mesa-dev] [PATCH v2 4/4] etnaviv: enable ETC2 texture compression support for HALTI0 GPUs

[Lucas Stach]

Am Dienstag, den 26.02.2019, 19:15 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_screen.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index de822fc85ca..ee32a499fb5 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -518,19 +518,9 @@ gpu_supports_texure_format(struct etna_screen *screen, 
> uint32_t fmt,
> if (util_format_is_srgb(format))
>    supported = VIV_FEATURE(screen, chipMinorFeatures1, HALTI0);
>  
> -   if (fmt & EXT_FORMAT) {
> +   if (fmt & EXT_FORMAT)
>    supported = VIV_FEATURE(screen, chipMinorFeatures1, HALTI0);
>  
> -  /* ETC1 is checked above, as it has its own feature bit. ETC2 is
> -   * supported with HALTI0, however that implementation is buggy in 
> hardware.
> -   * The blob driver does per-block patching to work around this. As this
> -   * is currently not implemented by etnaviv, enable it for HALTI1 
> (GC3000)
> -   * only.
> -   */
> -  if (util_format_is_etc(format))
> - supported = VIV_FEATURE(screen, chipMinorFeatures2, HALTI1);
> -   }
> -
> if (fmt & ASTC_FORMAT) {
>    supported = screen->specs.tex_astc;
> }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 1/4] etnaviv: implement ETC2 block patching for HALTI0

[Lucas Stach]

Am Dienstag, den 26.02.2019, 19:15 +0100 schrieb Christian Gmeiner:
> ETC2 is supported with HALTI0, however that implementation is buggy
> in hardware. The blob driver does per-block patching to work around
> this. We need to swap colors for t-mode etc2 blocks.
> 
> > Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/drivers/etnaviv/Makefile.sources |   2 +
>  src/gallium/drivers/etnaviv/etnaviv_etc2.c   | 149 +++
>  src/gallium/drivers/etnaviv/etnaviv_etc2.h   |  51 +++
>  src/gallium/drivers/etnaviv/meson.build  |   2 +
>  4 files changed, 204 insertions(+)
>  create mode 100644 src/gallium/drivers/etnaviv/etnaviv_etc2.c
>  create mode 100644 src/gallium/drivers/etnaviv/etnaviv_etc2.h
> 
> diff --git a/src/gallium/drivers/etnaviv/Makefile.sources 
> b/src/gallium/drivers/etnaviv/Makefile.sources
> index 0b208122999..01e7e49a38a 100644
> --- a/src/gallium/drivers/etnaviv/Makefile.sources
> +++ b/src/gallium/drivers/etnaviv/Makefile.sources
> @@ -25,6 +25,8 @@ C_SOURCES :=  \
> >     etnaviv_disasm.h \
> >     etnaviv_emit.c \
> >     etnaviv_emit.h \
> > +   etnaviv_etc2.c \
> > +   etnaviv_etc2.h \
> >     etnaviv_fence.c \
> >     etnaviv_fence.h \
> >     etnaviv_format.c \
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_etc2.c 
> b/src/gallium/drivers/etnaviv/etnaviv_etc2.c
> new file mode 100644
> index 000..64811c3038d
> --- /dev/null
> +++ b/src/gallium/drivers/etnaviv/etnaviv_etc2.c
> @@ -0,0 +1,149 @@
> +/*
> + * Copyright (c) 2019 Etnaviv Project
> + * Copyright (C) 2019 Zodiac Inflight Innovations
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sub license,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Authors:
> > + *Christian Gmeiner 
> + */
> +
> +#include "etnaviv_etc2.h"
> +#include "etnaviv_resource.h"
> +#include "etnaviv_screen.h"
> +#include "hw/common.xml.h"
> +#include "util/u_format.h"
> +
> +bool
> +etna_etc2_needs_patching(const struct pipe_resource *prsc)
> +{
> +   const struct etna_screen *screen = etna_screen(prsc->screen);
> +
> +   if (!util_format_is_etc(prsc->format))
> +  return false;
> +
> +   if (prsc->format == PIPE_FORMAT_ETC1_RGB8)
> +  return false;

Isn't this format check redundant with the default case of the switch
below?

Other than that:

Acked-by: Lucas Stach 

Regards,
Lucas


> +   if (VIV_FEATURE(screen, chipMinorFeatures2, HALTI1))
> +  return false;
> +
> +   switch (prsc->format) {
> +   case PIPE_FORMAT_ETC2_RGB8:
> +   case PIPE_FORMAT_ETC2_SRGB8:
> +   case PIPE_FORMAT_ETC2_RGB8A1:
> +   case PIPE_FORMAT_ETC2_SRGB8A1:
> +   case PIPE_FORMAT_ETC2_RGBA8:
> +   case PIPE_FORMAT_ETC2_SRGBA8:
> +  return true;
> +  break;
> +
> +   default:
> +  return false;
> +   }
> +}
> +
> +static inline bool
> +needs_patching(uint8_t *buffer, bool punchthrough_alpha)
> +{
> +   /* punchthrough_alpha or etc2 individual mode? */
> +   if (!punchthrough_alpha && !(buffer[3] & 0x2))
> + return false;
> +
> +   /* etc2 t-mode? */
> +   static const int lookup[8] = { 0, 1, 2, 3, -4, -3, -2, -1 };
> +   const int R_plus_dR = (buffer[0] >> 3) + lookup[buffer[0] & 0x7];
> +
> +   if (R_plus_dR < 0 || R_plus_dR > 31)
> +  return true;
> +
> +   return false;
> +}
> +
> +void
> +etna_etc2_calculate_blocks(uint8_t *buffer, unsigned stride,
> +   unsigned width, unsigned height,
> +   enum pipe_format fo

Re: [Mesa-dev] [PATCH v2 3/4] etnaviv: hook-up etc2 patching

[Lucas Stach]

Am Dienstag, den 26.02.2019, 19:15 +0100 schrieb Christian Gmeiner:
> Changes v1 -> v2:
>  - Avoid the GPU sampling from the resource that gets mutated by the the
>    transfer map by setting DRM_ETNA_PREP_WRITE.
> 
> > Signed-off-by: Christian Gmeiner 
> ---
>  .../drivers/etnaviv/etnaviv_resource.c|  3 +
>  .../drivers/etnaviv/etnaviv_resource.h|  5 ++
>  .../drivers/etnaviv/etnaviv_transfer.c| 55 +++
>  3 files changed, 63 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index db5ead4d0ba..45d5f69169e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -478,6 +478,9 @@ etna_resource_destroy(struct pipe_screen *pscreen, struct 
> pipe_resource *prsc)
> pipe_resource_reference(>texture, NULL);
> pipe_resource_reference(>external, NULL);
>  
> +   for (unsigned i = 0; i < ETNA_NUM_LOD; i++)
> +  FREE(rsc->levels[i].patch_offsets);
> +
> FREE(rsc);
>  }
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 75aa80b3d7a..c45ff7586d1 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -33,6 +33,7 @@
>  #include "util/list.h"
>  
>  struct pipe_screen;
> +struct util_dynarray;
>  
>  struct etna_resource_level {
> unsigned width, padded_width; /* in pixels */
> @@ -47,6 +48,10 @@ struct etna_resource_level {
> uint32_t ts_size;
> uint32_t clear_value; /* clear value of resource level (mainly for TS) */
> bool ts_valid;
> +
> +   /* keep track if we have done some per block patching */
> +   bool patched;
> +   struct util_dynarray *patch_offsets;
>  };
>  
>  enum etna_resource_addressing_mode {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 01da393d211..9a83c481dce 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -28,6 +28,7 @@
>  #include "etnaviv_clear_blit.h"
>  #include "etnaviv_context.h"
>  #include "etnaviv_debug.h"
> +#include "etnaviv_etc2.h"
>  #include "etnaviv_screen.h"
>  
>  #include "pipe/p_defines.h"
> @@ -57,6 +58,46 @@ etna_compute_offset(enum pipe_format format, const struct 
> pipe_box *box,
>   util_format_get_blocksize(format);
>  }
>  
> +static void etna_patch_data(void *buffer, const struct pipe_transfer *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = >levels[ptrans->level];
> +
> +   if (!etna_etc2_needs_patching(prsc))

Maybe likely() here?

> +  return;
> +
> +   if (level->patched)
> +  return;
> +
> +   /* do have the offsets of blocks to patch? */
> +   if (!level->patch_offsets) {
> +  level->patch_offsets = CALLOC_STRUCT(util_dynarray);
> +
> +  etna_etc2_calculate_blocks(buffer, ptrans->stride,
> + ptrans->box.width, 
> ptrans->box.height,
> + prsc->format, level->patch_offsets);
> +   }
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = true;
> +}
> +
> +static void etna_unpatch_data(void *buffer, const struct pipe_transfer 
> *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = >levels[ptrans->level];
> +
> +   if (!level->patched)
> +  return;
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = false;
> +}
> +
>  static void
>  etna_transfer_unmap(struct pipe_context *pctx, struct pipe_transfer *ptrans)
>  {
> @@ -119,6 +160,10 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> pipe_transfer *ptrans)
>    }
> }
>  
> +   /* We need to have the patched data ready for the GPU. */
> +   if (rsc->layout == ETNA_LAYOUT_LINEAR)

I don't like the LAYOUT_LINEAR checks here, as GC3000 actually has a
feature bit TEX_COMPRESSION_SUPERTILED, so I don't think the assertion
that all compressed formats are linear will hold in the future and it
seems like a minor optimization.

> +  etna_patch_data(trans->mapped, ptrans);
> +
> /*
>  * Transfers without a temporary are only pulled into the CPU domain if 
> they
>  * are not mapped unsynchronized. If they are, must push them back into 
> GPU
> @@ -321,6 +366,12 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>    if (usage & PIPE_TRANSFER_WRITE)
>   prep_flags |= DRM_ETNA_PREP_WRITE;
>  
> +  /* avoid the GPU sampling from the resource that gets mutated */

This doesn't really explain to the reader of this function what happens
here. Maybe something along the 

Re: [Mesa-dev] [PATCH] etnaviv: blt: mark used src resource as read from

[Lucas Stach]

Am Freitag, den 22.02.2019, 11:10 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_blt.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_blt.c
> b/src/gallium/drivers/etnaviv/etnaviv_blt.c
> index 52731a9c770..42190d75d4e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_blt.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_blt.c
> @@ -510,7 +510,9 @@ etna_try_blt_blit(struct pipe_context *pctx,
> etna_stall(ctx->stream, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_BLT);
> etna_set_state(ctx->stream, VIVS_GL_FLUSH_CACHE, 0x0c23);
>  
> +   resource_read(ctx, >base);
> resource_written(ctx, >base);
> +
> dst->seqno++;
> dst_lev->ts_valid = false;
>  

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] etnaviv: rs: mark used src resource as read from

[Lucas Stach]

Am Freitag, den 22.02.2019, 11:02 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index fc4f65dbeee..a9d3872ad41 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -728,6 +728,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
> });
>  
> etna_submit_rs_state(ctx, _to_screen);
> +   resource_read(ctx, >base);
> resource_written(ctx, >base);
> dst->seqno++;
> dst->levels[blit_info->dst.level].ts_valid = false;

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] etnaviv: hook-up etc2 patching

[Lucas Stach]

Am Freitag, den 22.02.2019, 10:18 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

AFAICS this is directly operating on the mapped buffer, right?

As ETC is stored as a linear, we won't get a temporary resource for the
transfer, but map the GPU resource directly. So this will fail in some
cases for read transfers, as both GPU and CPU are allowed to do reads
to the resource at the same time, but now your read transfer mutates
the GPU resource. If we don't want to have a full temporary resource to
operate on, at least the DRM_ETNA_PREP_WRITE needs to be set on
etna_bo_cpu_prep(), to avoid the GPU sampling from the resource that
gets mutated by the the transfer map.

Regards,
Lucas
 

> ---
>  .../drivers/etnaviv/etnaviv_resource.c|  3 ++
>  .../drivers/etnaviv/etnaviv_resource.h|  5 ++
>  .../drivers/etnaviv/etnaviv_transfer.c| 49 +++
>  3 files changed, 57 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index db5ead4d0ba..45d5f69169e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -478,6 +478,9 @@ etna_resource_destroy(struct pipe_screen *pscreen, struct 
> pipe_resource *prsc)
> pipe_resource_reference(>texture, NULL);
> pipe_resource_reference(>external, NULL);
>  
> +   for (unsigned i = 0; i < ETNA_NUM_LOD; i++)
> +  FREE(rsc->levels[i].patch_offsets);
> +
> FREE(rsc);
>  }
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 75aa80b3d7a..c45ff7586d1 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -33,6 +33,7 @@
>  #include "util/list.h"
>  
>  struct pipe_screen;
> +struct util_dynarray;
>  
>  struct etna_resource_level {
> unsigned width, padded_width; /* in pixels */
> @@ -47,6 +48,10 @@ struct etna_resource_level {
> uint32_t ts_size;
> uint32_t clear_value; /* clear value of resource level (mainly for TS) */
> bool ts_valid;
> +
> +   /* keep track if we have done some per block patching */
> +   bool patched;
> +   struct util_dynarray *patch_offsets;
>  };
>  
>  enum etna_resource_addressing_mode {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 01da393d211..119820d52b5 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -28,6 +28,7 @@
>  #include "etnaviv_clear_blit.h"
>  #include "etnaviv_context.h"
>  #include "etnaviv_debug.h"
> +#include "etnaviv_etc2.h"
>  #include "etnaviv_screen.h"
>  
>  #include "pipe/p_defines.h"
> @@ -57,6 +58,46 @@ etna_compute_offset(enum pipe_format format, const struct 
> pipe_box *box,
>   util_format_get_blocksize(format);
>  }
>  
> +static void etna_patch_data(void *buffer, const struct pipe_transfer *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = >levels[ptrans->level];
> +
> +   if (!etna_etc2_needs_patching(prsc))
> +  return;
> +
> +   if (level->patched)
> +  return;
> +
> +   /* do have the offsets of blocks to patch? */
> +   if (!level->patch_offsets) {
> +  level->patch_offsets = CALLOC_STRUCT(util_dynarray);
> +
> +  etna_etc2_calculate_blocks(buffer, ptrans->stride,
> + ptrans->box.width, 
> ptrans->box.height,
> + prsc->format, level->patch_offsets);
> +   }
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = true;
> +}
> +
> +static void etna_unpatch_data(void *buffer, const struct pipe_transfer 
> *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = >levels[ptrans->level];
> +
> +   if (!level->patched)
> +  return;
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = false;
> +}
> +
>  static void
>  etna_transfer_unmap(struct pipe_context *pctx, struct pipe_transfer *ptrans)
>  {
> @@ -119,6 +160,10 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> pipe_transfer *ptrans)
>}
> }
>  
> +   /* We need to have the patched data ready for the GPU. */
> +   if (rsc->layout == ETNA_LAYOUT_LINEAR)
> +  etna_patch_data(trans->mapped, ptrans);
> +
> /*
>  * Transfers without a temporary are only pulled into the CPU domain if 
> they
>  * are not mapped unsynchronized. If they are, must push them back into 
> GPU
> @@ -340,6 +385,10 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>   etna_compute_offset(prsc->format, box, res_level->stride,
>  

Re: [Mesa-dev] [PATCH 2/4] etnaviv: keep track of mapped bo address

[Lucas Stach]

Am Freitag, den 22.02.2019, 10:18 +0100 schrieb Christian Gmeiner:
> Saves us from calling etna_bo_map(..) and saves us from doing the
> same offset calcs for map() and unmap() operations.
> 
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.h |  1 +
>  .../drivers/etnaviv/etnaviv_transfer.c| 19 ++-
>  2 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
> b/src/gallium/drivers/etnaviv/etnaviv_context.h
> index 6ad9f3431e1..45b3954c7cb 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
> @@ -70,6 +70,7 @@ struct etna_transfer {
> struct pipe_transfer base;
> struct pipe_resource *rsc;
> void *staging;
> +   void *mapped;
>  };
>  
>  struct etna_vertexbuf_state {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 0b7411b47ef..01da393d211 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -91,16 +91,15 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> pipe_transfer *ptrans)
>} else if (trans->staging) {
>   /* map buffer object */
>   struct etna_resource_level *res_level = >levels[ptrans->level];
> - void *mapped = etna_bo_map(rsc->bo) + res_level->offset;
>  
>   if (rsc->layout == ETNA_LAYOUT_TILED) {
>  etna_texture_tile(
> -   mapped + ptrans->box.z * res_level->layer_stride,
> +   trans->mapped + ptrans->box.z * res_level->layer_stride,
> trans->staging, ptrans->box.x, ptrans->box.y,
> res_level->stride, ptrans->box.width, ptrans->box.height,
> ptrans->stride, util_format_get_blocksize(rsc->base.format));
>   } else if (rsc->layout == ETNA_LAYOUT_LINEAR) {
> -util_copy_box(mapped, rsc->base.format, res_level->stride,
> +util_copy_box(trans->mapped, rsc->base.format, res_level->stride,
>res_level->layer_stride, ptrans->box.x,
>ptrans->box.y, ptrans->box.z, ptrans->box.width,
>ptrans->box.height, ptrans->box.depth,
> @@ -327,8 +326,8 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
> }
>  
> /* map buffer object */
> -   void *mapped = etna_bo_map(rsc->bo);
> -   if (!mapped)
> +   trans->mapped = etna_bo_map(rsc->bo);
> +   if (!trans->mapped)
>goto fail;
>  
> *out_transfer = ptrans;
> @@ -337,9 +336,11 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>ptrans->stride = res_level->stride;
>ptrans->layer_stride = res_level->layer_stride;
>  
> -  return mapped + res_level->offset +
> +  trans->mapped += res_level->offset +
>   etna_compute_offset(prsc->format, box, res_level->stride,
>   res_level->layer_stride);
> +
> +  return trans->mapped;
> } else {
>unsigned divSizeX = util_format_get_blockwidth(format);
>unsigned divSizeY = util_format_get_blockheight(format);
> @@ -350,7 +351,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>if (usage & PIPE_TRANSFER_MAP_DIRECTLY)
>   goto fail;
>  
> -  mapped += res_level->offset;
> +  trans->mapped += res_level->offset;
>ptrans->stride = align(box->width, divSizeX) * 
> util_format_get_blocksize(format); /* row stride in bytes */
>ptrans->layer_stride = align(box->height, divSizeY) * ptrans->stride;
>size_t size = ptrans->layer_stride * box->depth;
> @@ -362,7 +363,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>if (usage & PIPE_TRANSFER_READ) {
>   if (rsc->layout == ETNA_LAYOUT_TILED) {
>  etna_texture_untile(trans->staging,
> -mapped + ptrans->box.z * 
> res_level->layer_stride,
> +trans->mapped + ptrans->box.z * 
> res_level->layer_stride,
>  ptrans->box.x, ptrans->box.y, 
> res_level->stride,
>  ptrans->box.width, ptrans->box.height, 
> ptrans->stride,
>  util_format_g

Re: [Mesa-dev] [PATCH 4/4] etnaviv: hook up linear texture sampling support

[Lucas Stach]

Hi Christian,

Am Montag, den 21.01.2019, 07:50 +0100 schrieb Christian Gmeiner:
> If the GPU supports linear sampling, linear addressing mode
> will be used as default.
> 
> > Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 10 +++---
>  src/gallium/drivers/etnaviv/etnaviv_texture.c  |  4 +++-
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 9a7ebf3064e..7d24b1f03bd 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -318,9 +318,9 @@ etna_resource_create(struct pipe_screen *pscreen,
>  {
> struct etna_screen *screen = etna_screen(pscreen);
>  
> -   /* Figure out what tiling and address mode to use -- for now, assume that
> -* texture cannot be linear. there is a capability LINEAR_TEXTURE_SUPPORT
> -* (supported on gc880 and gc2000 at least), but not sure how it works.
> +   /* Figure out what tiling and address mode to use.
> +* Textures are TILED or LINEAR. If LINEAR_TEXTURE_SUPPORT capability is
> +* available LINEAR gets prefered.
>  * Buffers always have LINEAR layout.
>  */
> unsigned layout = ETNA_LAYOUT_LINEAR;
> @@ -334,6 +334,10 @@ etna_resource_create(struct pipe_screen *pscreen,
>  
>    if (util_format_is_compressed(templat->format))
>   layout = ETNA_LAYOUT_LINEAR;
> +  else if (VIV_FEATURE(screen, chipMinorFeatures1, 
> LINEAR_TEXTURE_SUPPORT)) {
> + layout = ETNA_LAYOUT_LINEAR;
> + mode = ETNA_ADDRESSING_MODE_LINEAR;
> +  }
> } else if (templat->target != PIPE_BUFFER) {
>    bool want_multitiled = false;
>    bool want_supertiled = screen->specs.can_supertile;
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_texture.c 
> b/src/gallium/drivers/etnaviv/etnaviv_texture.c
> index 3993e31cec1..b06f20531fd 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_texture.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_texture.c
> @@ -172,7 +172,9 @@ etna_resource_sampler_compatible(struct etna_resource 
> *res)
> if (res->layout == ETNA_LAYOUT_SUPER_TILED && VIV_FEATURE(screen, 
> chipMinorFeatures2, SUPERTILED_TEXTURE))
>    return true;
>  
> -   /* TODO: LINEAR_TEXTURE_SUPPORT */
> +   /* This GPU supports texturing from linear textures? */
> +   if (res->layout == ETNA_LAYOUT_LINEAR && VIV_FEATURE(screen, 
> chipMinorFeatures1, LINEAR_TEXTURE_SUPPORT))
> +  return true;

In order to avoid this sitting on the ML for too long while mostly
looking good: how would you feel about squashing this last hunk into
the previous patch and dropping the other parts of this patch for now?

This way we could have most of the stuff in master and do further
experiments about the performance implications later on. If you want to
do this, patches 1-3 are:

Reviewed-by: Lucas Stach 

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] etnaviv: hook up linear texture sampling support

[Lucas Stach]

Am Donnerstag, den 24.01.2019, 07:46 +0100 schrieb Christian Gmeiner:
> Am Mo., 21. Jan. 2019 um 10:10 Uhr schrieb Lucas Stach 
> :
> > 
> > Am Montag, den 21.01.2019, 07:50 +0100 schrieb Christian Gmeiner:
> > > If the GPU supports linear sampling, linear addressing mode
> > > will be used as default.
> > > 
> > > > Signed-off-by: Christian Gmeiner 
> > > 
> > > ---
> > >  src/gallium/drivers/etnaviv/etnaviv_resource.c | 10 +++---
> > >  src/gallium/drivers/etnaviv/etnaviv_texture.c  |  4 +++-
> > >  2 files changed, 10 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> > > b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > index 9a7ebf3064e..7d24b1f03bd 100644
> > > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > @@ -318,9 +318,9 @@ etna_resource_create(struct pipe_screen *pscreen,
> > >  {
> > > struct etna_screen *screen = etna_screen(pscreen);
> > > 
> > > -   /* Figure out what tiling and address mode to use -- for now, assume 
> > > that
> > > -* texture cannot be linear. there is a capability 
> > > LINEAR_TEXTURE_SUPPORT
> > > -* (supported on gc880 and gc2000 at least), but not sure how it 
> > > works.
> > > +   /* Figure out what tiling and address mode to use.
> > > +* Textures are TILED or LINEAR. If LINEAR_TEXTURE_SUPPORT capability 
> > > is
> > > +* available LINEAR gets prefered.
> > >  * Buffers always have LINEAR layout.
> > >  */
> > > unsigned layout = ETNA_LAYOUT_LINEAR;
> > > @@ -334,6 +334,10 @@ etna_resource_create(struct pipe_screen *pscreen,
> > > 
> > >    if (util_format_is_compressed(templat->format))
> > >   layout = ETNA_LAYOUT_LINEAR;
> > > +  else if (VIV_FEATURE(screen, chipMinorFeatures1, 
> > > LINEAR_TEXTURE_SUPPORT)) {
> > > + layout = ETNA_LAYOUT_LINEAR;
> > > + mode = ETNA_ADDRESSING_MODE_LINEAR;
> > > +  }
> > 
> > Did you do any performance measurements with this change? I don't think
> > we generally want to prefer linear textures, as in theory they have
> > much worse texture cache hit rates. Also a lot of the async transfer
> > stuff currently depends on hitting the RS linear->tiled blit path for
> > optimal performance on uploads.
> > 
> 
> I have not done any performance measurements yet - I only tried to get it
> render correctly (piglit and amoeba) and get some feedback asap.
> But I will keep an eye on perf for v2.

FWIW, I did some preliminary testing and couldn't find a big perf
difference. Even after a hack to use linear textures more often (in
most cases we end up with textures being allocated with both SAMPLER
and RENDER binding, where we still end up with tiled resources.

But my tests didn't pound very hard on sampler performance.

> Regarding the async transfer staff I have the feeling that we lose the shadow
> resource (etna_transfer->rsc) handling if we are using linear, which saves us
> from some RS blits. Or?

That's right, but at the price that the CPU side of the transfer needs
to synchronize with the GPU job. Getting rid of those synchronization
points was one of the key performance optimizations up until now.

Basically we are trading the overhead of a temporary buffer allocation
and a RS blit (which is only done to the part of the buffer that is
actually updated) against a full GPU stall in most cases. I'm not
saying that getting rid of the RS blit for some of the transfers won't
be beneficial, but we need to carefully weight the performance
implications here. Being able to directly map the texture resource and
blindly doing this when possible (what our current transfer code does) 
will not be a net win in performance in most cases.

> > There are 2 cases where I think linear textures are useful:
> > 
> > 1. Imported external buffers, where we might need to update the
> > internal tiled copy on each resource update. Getting rid of this blit
> > should help performance a good bit.
> > 
> 
> You are taking about etna_resource_from_handle(..). I *think* for this we
> need support for linear in the pixel engine too - based on the binding flag
> combinations I have seen.

That would be ideal, but for a start we can just keep the external
imported resource as linear and keep a tiled base resource, just as we
do now. Linear texture sampling support would already allow us to
sample the external import directly, without the need to do a copy into
a tiled texture resource.

> > 2. 8bpp formats that can't be tiled with the RS and would hit the
> > software fallback path. The tradeoff software tiling path vs. reduced
> > texture cache hit rates might still prefer linear textures.
> > 
> 
> Yes that I something to look into.
> 

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] etnaviv: extend etna_resource with an addressing mode

[Lucas Stach]

Am Donnerstag, den 24.01.2019, 07:31 +0100 schrieb Christian Gmeiner:
> Hi Lucas
> 
> Am Mo., 21. Jan. 2019 um 10:03 Uhr schrieb Lucas Stach 
> :
> > 
> > Hi Christian,
> > 
> > first of all, thanks for figuring this out. This is really nice
> > to finally know how it works.
> > 
> > Am Montag, den 21.01.2019, 07:49 +0100 schrieb Christian Gmeiner:
> > > Defines how sampler (and pixel pipes) needs to access the data
> > > represented with a resource. The used default is mode is
> > > ETNA_ADDRESSING_MODE_TILED.
> > 
> > Do you see any reason why we need a separate property for this? IMHO
> > etna_resource is already a bit too fat and from this set of patches I
> > can't see why we can't infer the addressing mode from the layout. Do
> > you have something specific in mind, that I don't see right now?
> > 
> 
> We are using ETNA_LAYOUT_LINEAR for compressed textures with an
> addressing mode of TILED (register value of 0). That is the root cause why
> was forced to add something new to etna_resource as I can not trust that
> ETNA_LAYOUT_LINEAR for sampler resources implies an linear addressing
> mode.

Ah, right. This had escaped my mind. With this out of the way, patch
looks good.

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] etnaviv: hook up linear texture sampling support

[Lucas Stach]

Am Montag, den 21.01.2019, 07:50 +0100 schrieb Christian Gmeiner:
> If the GPU supports linear sampling, linear addressing mode
> will be used as default.
> 
> > Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 10 +++---
>  src/gallium/drivers/etnaviv/etnaviv_texture.c  |  4 +++-
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 9a7ebf3064e..7d24b1f03bd 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -318,9 +318,9 @@ etna_resource_create(struct pipe_screen *pscreen,
>  {
> struct etna_screen *screen = etna_screen(pscreen);
>  
> -   /* Figure out what tiling and address mode to use -- for now, assume that
> -* texture cannot be linear. there is a capability LINEAR_TEXTURE_SUPPORT
> -* (supported on gc880 and gc2000 at least), but not sure how it works.
> +   /* Figure out what tiling and address mode to use.
> +* Textures are TILED or LINEAR. If LINEAR_TEXTURE_SUPPORT capability is
> +* available LINEAR gets prefered.
>  * Buffers always have LINEAR layout.
>  */
> unsigned layout = ETNA_LAYOUT_LINEAR;
> @@ -334,6 +334,10 @@ etna_resource_create(struct pipe_screen *pscreen,
>  
>    if (util_format_is_compressed(templat->format))
>   layout = ETNA_LAYOUT_LINEAR;
> +  else if (VIV_FEATURE(screen, chipMinorFeatures1, 
> LINEAR_TEXTURE_SUPPORT)) {
> + layout = ETNA_LAYOUT_LINEAR;
> + mode = ETNA_ADDRESSING_MODE_LINEAR;
> +  }

Did you do any performance measurements with this change? I don't think
we generally want to prefer linear textures, as in theory they have
much worse texture cache hit rates. Also a lot of the async transfer
stuff currently depends on hitting the RS linear->tiled blit path for
optimal performance on uploads.

There are 2 cases where I think linear textures are useful:

1. Imported external buffers, where we might need to update the
internal tiled copy on each resource update. Getting rid of this blit
should help performance a good bit.

2. 8bpp formats that can't be tiled with the RS and would hit the
software fallback path. The tradeoff software tiling path vs. reduced
texture cache hit rates might still prefer linear textures.

Regards,
Lucas
 

> } else if (templat->target != PIPE_BUFFER) {
>    bool want_multitiled = false;
>    bool want_supertiled = screen->specs.can_supertile;
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_texture.c 
> b/src/gallium/drivers/etnaviv/etnaviv_texture.c
> index 3993e31cec1..b06f20531fd 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_texture.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_texture.c
> @@ -172,7 +172,9 @@ etna_resource_sampler_compatible(struct etna_resource 
> *res)
> if (res->layout == ETNA_LAYOUT_SUPER_TILED && VIV_FEATURE(screen, 
> chipMinorFeatures2, SUPERTILED_TEXTURE))
>    return true;
>  
> -   /* TODO: LINEAR_TEXTURE_SUPPORT */
> +   /* This GPU supports texturing from linear textures? */
> +   if (res->layout == ETNA_LAYOUT_LINEAR && VIV_FEATURE(screen, 
> chipMinorFeatures1, LINEAR_TEXTURE_SUPPORT))
> +  return true;
>  
> /* Otherwise, only support tiled layouts */
> if (res->layout != ETNA_LAYOUT_TILED)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] etnaviv: extend etna_resource with an addressing mode

[Lucas Stach]

Hi Christian,

first of all, thanks for figuring this out. This is really nice
to finally know how it works.

Am Montag, den 21.01.2019, 07:49 +0100 schrieb Christian Gmeiner:
> Defines how sampler (and pixel pipes) needs to access the data
> represented with a resource. The used default is mode is
> ETNA_ADDRESSING_MODE_TILED.

Do you see any reason why we need a separate property for this? IMHO
etna_resource is already a bit too fat and from this set of patches I
can't see why we can't infer the addressing mode from the layout. Do
you have something specific in mind, that I don't see right now?

Regards,
Lucas

> 
> > Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 17 +++--
>  src/gallium/drivers/etnaviv/etnaviv_resource.h |  9 -
>  src/gallium/drivers/etnaviv/etnaviv_texture.c  |  1 +
>  src/gallium/drivers/etnaviv/etnaviv_transfer.c |  3 ++-
>  4 files changed, 22 insertions(+), 8 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index c0091288030..9a7ebf3064e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -188,7 +188,8 @@ static bool is_rs_align(struct etna_screen *screen,
>  /* Create a new resource object, using the given template info */
>  struct pipe_resource *
>  etna_resource_alloc(struct pipe_screen *pscreen, unsigned layout,
> -uint64_t modifier, const struct pipe_resource *templat)
> +enum etna_resource_addressing_mode mode, uint64_t 
> modifier,
> +const struct pipe_resource *templat)
>  {
> struct etna_screen *screen = etna_screen(pscreen);
> struct etna_resource *rsc;
> @@ -280,6 +281,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, unsigned 
> layout,
> rsc->base.nr_samples = nr_samples;
> rsc->layout = layout;
> rsc->halign = halign;
> +   rsc->addressing_mode = mode;
>  
> pipe_reference_init(>base.reference, 1);
> list_inithead(>list);
> @@ -316,12 +318,14 @@ etna_resource_create(struct pipe_screen *pscreen,
>  {
> struct etna_screen *screen = etna_screen(pscreen);
>  
> -   /* Figure out what tiling to use -- for now, assume that texture cannot 
> be linear.
> -* there is a capability LINEAR_TEXTURE_SUPPORT (supported on gc880 and
> -* gc2000 at least), but not sure how it works.
> +   /* Figure out what tiling and address mode to use -- for now, assume that
> +* texture cannot be linear. there is a capability LINEAR_TEXTURE_SUPPORT
> +* (supported on gc880 and gc2000 at least), but not sure how it works.
>  * Buffers always have LINEAR layout.
>  */
> unsigned layout = ETNA_LAYOUT_LINEAR;
> +   enum etna_resource_addressing_mode mode = ETNA_ADDRESSING_MODE_TILED;
> +
> if (etna_resource_sampler_only(templat)) {
>    /* The buffer is only used for texturing, so create something
> * directly compatible with the sampler.  Such a buffer can
> @@ -364,7 +368,7 @@ etna_resource_create(struct pipe_screen *pscreen,
>    layout = ETNA_LAYOUT_LINEAR;
>  
> /* modifier is only used for scanout surfaces, so safe to use LINEAR here 
> */
> -   return etna_resource_alloc(pscreen, layout, DRM_FORMAT_MOD_LINEAR, 
> templat);
> +   return etna_resource_alloc(pscreen, layout, mode, DRM_FORMAT_MOD_LINEAR, 
> templat);
>  }
>  
>  enum modifier_priority {
> @@ -445,7 +449,7 @@ etna_resource_create_modifiers(struct pipe_screen 
> *pscreen,
> tmpl.bind |= PIPE_BIND_SCANOUT;
>  
> return etna_resource_alloc(pscreen, modifier_to_layout(modifier),
> -  modifier, );
> +  ETNA_ADDRESSING_MODE_TILED, modifier, );
>  }
>  
>  static void
> @@ -518,6 +522,7 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
> rsc->seqno = 1;
> rsc->layout = modifier_to_layout(handle->modifier);
> rsc->halign = TEXTURE_HALIGN_FOUR;
> +   rsc->addressing_mode = ETNA_ADDRESSING_MODE_TILED;
>  
>  
> level->width = tmpl->width0;
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 11ccf8f7bcb..75aa80b3d7a 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -49,6 +49,11 @@ struct etna_resource_level {
> bool ts_valid;
>  };
>  
> +enum etna_resource_addressing_mode {
> +   ETNA_ADDRESSING_MODE_TILED = 0,
> +   ETNA_ADDRESSING_MODE_LINEAR,
> +};
> +
>  /* status of queued up but not flushed reads and write operations.
>   * In _transfer_map() we need to know if queued up rendering needs
>   * to be flushed to preserve the order of cpu and gpu access. */
> @@ -66,6 +71,7 @@ struct etna_resource {
> /* only lod 0 used for non-texture buffers */
> /* Layout for surface (tiled, multitiled, split tiled, ...) */
> enum etna_surface_layout 

Re: [Mesa-dev] Double free error on etnaviv driver.

[Lucas Stach]

Hi Sergey,

Am Donnerstag, den 17.01.2019, 18:14 +0300 schrieb Nazarov Sergey:
> Hi, Lucas!
> Here is result of execution standard Qt5 example application mainwindow
> built under custom buildroot with gcc-4.9.4, mesa3d-17.3.6.
> But we had the same error with latest buildroot and latest supported mesa and 
> gcc.
> ---
> # ./mainwindow
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
> '/root/.tmp/runtime-root'
> Failed to move cursor on screen LVDS1: -14
> *** Error in `./mainwindow': double free or corruption (fasttop): 0x021295b8 
> ***
> Aborted
> ---
> Some from valgrind output:
> ==1473== Invalid free() / delete / delete[] / realloc()
> ==1473==at 0x48469F8: free (vg_replace_malloc.c:530)
> ==1473==by 0x825C61B: _mesa_glsl_release_builtin_functions() (in 
> /usr/lib/dri/imx-drm_dri.so)
> ==1473==by 0x8286113: _mesa_destroy_shader_compiler (in 
> /usr/lib/dri/imx-drm_dri.so)
> ==1473==by 0x808F073: one_time_fini (in /usr/lib/dri/imx-drm_dri.so)
> ==1473==  Address 0x96f4ee8 is 0 bytes inside a block of size 24 free'd
> ==1473==at 0x48469F8: free (vg_replace_malloc.c:530)
> ==1473==by 0x4015CF7: _dl_close_worker (in /lib/ld-2.23.so)
> ==1473==  Block was alloc'd at
> ==1473==at 0x48454B0: malloc (vg_replace_malloc.c:299)
> ==1473==by 0x829EA7F: ralloc_size (in /usr/lib/dri/imx-drm_dri.so)

I've just been made aware of a peculiarity of the buildroot toolchain
configuration, which might well explain why you are seeing the obvious
crash, but no one else is complaining about this.

Can you try if [1] also solves this issue for you? If it does, I think
we should not try to work around this in Mesa.

Regards,
Lucas

[1] http://lists.busybox.net/pipermail/buildroot/2018-November/235923.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Double free error on etnaviv driver.

[Lucas Stach]

Hi Sergey,

Am Mittwoch, den 16.01.2019, 13:34 +0300 schrieb Nazarov Sergey:
> Hello!
> I use mesa+etnaviv Gallium driver on iMX6Q based board.
> I have double free error at the end of any application using mesa.
> I've found that the problem comes from current ARM g++ compilers
> (at least from 4.9.4 up to latest ones) which call static objects destructors 
> before
> on_exit handler. So, static builtin_builder builtins destructor frees 
> dynamically allocated
> internal members memory before call of _mesa_glsl_release_builtin_functions(),
> which do that again. Here is a patch to fix the problem:

Do you have a reproducer for this issue? I haven't experienced any
memory corruption issues with etnaviv in a long time. Also this being
shared code, it should also happen on other ARM drivers too.

I gave some applications a quick run under valgrind, which didn't turn 
up anything bad immediately, so I would be interested in a way to
clearly demonstrate the issue.

Regards,
Lucas

> 
> --- a/src/compiler/glsl/builtin_functions.cpp
> +++ b/src/compiler/glsl/builtin_functions.cpp
> @@ -6268,7 +6268,7 @@ builtin_builder::_vote(const char *intri
>  
> /**/
>  
>  /* The singleton instance of builtin_builder. */
> -static builtin_builder builtins;
> +static builtin_builder *builtins = NULL;
>  static mtx_t builtins_lock = _MTX_INITIALIZER_NP;
>  
>  /**
> @@ -6279,7 +6279,9 @@ void
>  _mesa_glsl_initialize_builtin_functions()
>  {
> mtx_lock(_lock);
> -   builtins.initialize();
> +   if (!builtins)
> + builtins = new builtin_builder;
> +   builtins->initialize();
> mtx_unlock(_lock);
>  }
>  
> @@ -6287,7 +6289,9 @@ void
>  _mesa_glsl_release_builtin_functions()
>  {
> mtx_lock(_lock);
> -   builtins.release();
> +   builtins->release();
> +   delete builtins;
> +   builtins = NULL;
> mtx_unlock(_lock);
>  }
>  
> @@ -6297,7 +6301,7 @@ _mesa_glsl_find_builtin_function(_mesa_g
>  {
> ir_function_signature *s;
> mtx_lock(_lock);
> -   s = builtins.find(state, name, actual_parameters);
> +   s = builtins->find(state, name, actual_parameters);
> mtx_unlock(_lock);
>  
> return s;
> @@ -6309,7 +6313,7 @@ _mesa_glsl_has_builtin_function(_mesa_gl
> ir_function *f;
> bool ret = false;
> mtx_lock(_lock);
> -   f = builtins.shader->symbols->get_function(name);
> +   f = builtins->shader->symbols->get_function(name);
> if (f != NULL) {
>    foreach_in_list(ir_function_signature, sig, >signatures) {
>   if (sig->is_builtin_available(state)) {
> @@ -6326,7 +6330,7 @@ _mesa_glsl_has_builtin_function(_mesa_gl
>  gl_shader *
>  _mesa_glsl_get_builtin_function_shader()
>  {
> -   return builtins.shader;
> +   return builtins ? builtins->shader : NULL;
>  }
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/wayland: break double/tripple buffering feedback loops

[Lucas Stach]

Am Dienstag, den 15.01.2019, 10:35 -0600 schrieb Derek Foreman:
> On 1/15/19 8:02 AM, Daniel Stone wrote:
> > Hi,
> > 
> > > > On Tue, 18 Dec 2018 at 17:59, Lucas Stach  
> > > > wrote:
> > > Am Dienstag, den 18.12.2018, 17:43 + schrieb Emil Velikov:
> > > > > On Tue, 18 Dec 2018 at 11:16, Lucas Stach  
> > > > > wrote:
> > > > >   if (dri2_surf->back == NULL)
> > > > >  dri2_surf->back = _surf->color_buffers[i];
> > > > > - else if (dri2_surf->back->dri_image == NULL)
> > > > > + else if (dri2_surf->back->dri_image == NULL && 
> > > > > dri2_surf->color_buffers[i].dri_image)
> > > > >  dri2_surf->back = _surf->color_buffers[i];
> > > > > + age = dri2_surf->back->age;
> > > > >    }
> > > > > 
> > > > 
> > > > AFAICT this is the wayland equivalent of
> > > > 4f1d27a406478d405eac6f9894ccc46a80034adb
> > > > Where the exact same logic/commit message applies.
> > > 
> > > No it isn't. It's exactly what it says in the commit log. It's keeping
> > > the tripple buffer around for a bit, even if we don't strictly need it
> > > when the client is currently doing double buffering.
> 
> I'm having a bit of a hard time following the logic in this first hunk
> myself...
> 
> The dri2_surf->color_buffers[i].age < age check looks like it's intended
> to skip buffers younger than the one currently in hand - ie) pick the
> oldest buffer.  But doing so would break the second hunk because we'd
> never end up with a very old buffer to trim.  (It doesn't actually cause
> the oldest buffer to be picked though, because of the other tests involved)
> 
> I would like to at least see a comment explaining what's going on,
> because it looks kind of like a bug on a casual read.

The age check is really bogus and I believe I messed this up when
cleaning this up from a previous version of the patch. Thanks for
taking a close look. I'll fix this.

Regards,
Lucas

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4] etnaviv: fix resource usage tracking across different pipe_context's

[Lucas Stach]

Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut:
> > From: Christian Gmeiner 
> 
> A pipe_resource can be shared by all the pipe_context's hanging off the
> same pipe_screen.
> 
> > Signed-off-by: Christian Gmeiner 
> > Signed-off-by: Marek Vasut 
> To: mesa-dev@lists.freedesktop.org
> Cc: etna...@lists.freedesktop.org

I would appreciate if this can get a review from someone who didn't
totally mess up the mental model of the locking involved. To me this
change looks good. I'll push this through some internal testing and
push upstream by the end of the week if there aren't any objections.

Regards,
Lucas

> ---
> Changes from v1 -> v2:
>  - to remove the resource from the used_resources set when it is destroyed
> Changes from v2 -> v3:
>  - add locking with mtx_*() to resource and screen (Marek)
> Changes from v3 -> v4:
>  - drop rsc->lock, just use screen->lock for the entire serialization (Marek)
>  - simplify etna_resource_used() flush condition, which also prevents
>    potentially flushing resources twice (Marek)
>  - don't remove resouces from screen->used_resources in
>    etna_cmd_stream_reset_notify(), they may still be used in other
>    contexts and may need flushing there later on (Marek)
> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.c | 26 +-
>  src/gallium/drivers/etnaviv/etnaviv_context.h |  3 --
>  .../drivers/etnaviv/etnaviv_resource.c| 52 +++
>  .../drivers/etnaviv/etnaviv_resource.h|  8 +--
>  src/gallium/drivers/etnaviv/etnaviv_screen.c  | 12 +
>  src/gallium/drivers/etnaviv/etnaviv_screen.h  |  6 +++
>  6 files changed, 78 insertions(+), 29 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
> b/src/gallium/drivers/etnaviv/etnaviv_context.c
> index 3038d21..2f8cae8 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> @@ -36,6 +36,7 @@
>  #include "etnaviv_query.h"
>  #include "etnaviv_query_hw.h"
>  #include "etnaviv_rasterizer.h"
> +#include "etnaviv_resource.h"
>  #include "etnaviv_screen.h"
>  #include "etnaviv_shader.h"
>  #include "etnaviv_state.h"
> @@ -329,7 +330,8 @@ static void
>  etna_cmd_stream_reset_notify(struct etna_cmd_stream *stream, void *priv)
>  {
> struct etna_context *ctx = priv;
> -   struct etna_resource *rsc, *rsc_tmp;
> +   struct etna_screen *screen = ctx->screen;
> +   struct set_entry *entry;
>  
> etna_set_state(stream, VIVS_GL_API_MODE, VIVS_GL_API_MODE_OPENGL);
> etna_set_state(stream, VIVS_GL_VERTEX_ELEMENT_CONFIG, 0x0001);
> @@ -384,16 +386,18 @@ etna_cmd_stream_reset_notify(struct etna_cmd_stream 
> *stream, void *priv)
> ctx->dirty = ~0L;
> ctx->dirty_sampler_views = ~0L;
>  
> -   /* go through all the used resources and clear their status flag */
> -   LIST_FOR_EACH_ENTRY_SAFE(rsc, rsc_tmp, >used_resources, list)
> -   {
> -  debug_assert(rsc->status != 0);
> -  rsc->status = 0;
> -  rsc->pending_ctx = NULL;
> -  list_delinit(>list);
> -   }
> +   /*
> +* Go through all _resources_ associated with this _screen_, pending
> +* in this _context_ and mark them as not pending in this _context_
> +* anymore, since they were just flushed.
> +*/
> +   mtx_lock(>lock);
> +   set_foreach(screen->used_resources, entry) {
> +  struct etna_resource *rsc = (struct etna_resource *)entry->key;
>  
> -   assert(LIST_IS_EMPTY(>used_resources));
> +  _mesa_set_remove_key(rsc->pending_ctx, ctx);
> +   }
> +   mtx_unlock(>lock);
>  }
>  
>  static void
> @@ -437,8 +441,6 @@ etna_context_create(struct pipe_screen *pscreen, void 
> *priv, unsigned flags)
> /* need some sane default in case state tracker doesn't set some state: */
> ctx->sample_mask = 0x;
>  
> -   list_inithead(>used_resources);
> -
> /*  Set sensible defaults for state */
> etna_cmd_stream_reset_notify(ctx->stream, ctx);
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
> b/src/gallium/drivers/etnaviv/etnaviv_context.h
> index 584caa7..eff0a23 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
> @@ -136,9 +136,6 @@ struct etna_context {
> uint32_t prim_hwsupport;
> struct primconvert_context *primconvert;
>  
> -   /* list of resources used by currently-unsubmitted renders */
> -   struct list_head used_resources;
> -
> struct slab_child_pool transfer_pool;
> struct blitter_context *blitter;
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 3808c29..46ab849 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -33,6 +33,7 @@
>  #include "etnaviv_screen.h"
>  #include "etnaviv_translate.h"
>  
> +#include "util/hash_table.h"
>  #include "util/u_inlines.h"
>  #include "util/u_memory.h"
>  
> @@ -275,7 +276,6 @@ etna_resource_alloc(struct 

Re: [Mesa-dev] [PATCH v4] etnaviv: fix resource usage tracking across different pipe_context's

[Lucas Stach]

Am Montag, den 14.01.2019, 15:20 +0100 schrieb Marek Vasut:
> On 1/14/19 3:02 PM, Lucas Stach wrote:
> > Am Montag, den 14.01.2019, 14:54 +0100 schrieb Marek Vasut:
> > > On 1/14/19 12:16 PM, Lucas Stach wrote:
> > > > Hi Marek,
> > > > 
> > > > Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut:
> > > > > > From: Christian Gmeiner 
> > > > > 
> > > > > A pipe_resource can be shared by all the pipe_context's hanging off 
> > > > > the
> > > > > same pipe_screen.
> > > > > 
> > > > > > > > > > Signed-off-by: Christian Gmeiner 
> > > > > > > > > > 
> > > > > > 
> > > > > > Signed-off-by: Marek Vasut 
> > > > > 
> > > > > To: mesa-dev@lists.freedesktop.org
> > > > > Cc: etna...@lists.freedesktop.org
> > > > > ---
> > > > > Changes from v1 -> v2:
> > > > >  - to remove the resource from the used_resources set when it is 
> > > > > destroyed
> > > > > Changes from v2 -> v3:
> > > > >  - add locking with mtx_*() to resource and screen (Marek)
> > > > > Changes from v3 -> v4:
> > > > >  - drop rsc->lock, just use screen->lock for the entire serialization 
> > > > > (Marek)
> > > > >  - simplify etna_resource_used() flush condition, which also prevents
> > > > >    potentially flushing resources twice (Marek)
> > > > >  - don't remove resouces from screen->used_resources in
> > > > >    etna_cmd_stream_reset_notify(), they may still be used in other
> > > > >    contexts and may need flushing there later on (Marek)
> > > > 
> > > > The patch mostly makes sense to me now, but don't we need to take the
> > > > screen->lock on all call sites where we do a ctx->flush? Otherwise we
> > > > may enter etna_cmd_stream_reset_notify unlocked, changing the
> > > > used_resources set while other threads might use it at the same time,
> > > > right?
> > > 
> > > etna_cmd_stream_reset_notify() takes the lock when accessing the
> > > used_resources set , see below.
> > 
> > Uh, sorry seems I mixed this up. But then I don't see how this isn't
> > deadlocking, as AFAICS mtx_lock isn't recursive.
> > 
> > In etna_resource_used() you already lock the screen mutex, then when
> > you find a context that needs flushing you call the context flush,
> > which flushes the cmd stream and calls into
> > etna_cmd_stream_reset_notify() where the mutex is locked again -> self
> > deadlock.
> 
> [...]
> 
> > > > > +   mtx_init(>lock, mtx_recursive);
> 
> [...]
> 
> But it is recursive ...

Thanks, going back to ridicule myself somewhere myself somewhere else
now.

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4] etnaviv: fix resource usage tracking across different pipe_context's

[Lucas Stach]

Am Montag, den 14.01.2019, 14:54 +0100 schrieb Marek Vasut:
> On 1/14/19 12:16 PM, Lucas Stach wrote:
> > Hi Marek,
> > 
> > Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut:
> > > > From: Christian Gmeiner 
> > > 
> > > A pipe_resource can be shared by all the pipe_context's hanging off the
> > > same pipe_screen.
> > > 
> > > > > > > > Signed-off-by: Christian Gmeiner 
> > > > Signed-off-by: Marek Vasut 
> > > 
> > > To: mesa-dev@lists.freedesktop.org
> > > Cc: etna...@lists.freedesktop.org
> > > ---
> > > Changes from v1 -> v2:
> > >  - to remove the resource from the used_resources set when it is destroyed
> > > Changes from v2 -> v3:
> > >  - add locking with mtx_*() to resource and screen (Marek)
> > > Changes from v3 -> v4:
> > >  - drop rsc->lock, just use screen->lock for the entire serialization 
> > > (Marek)
> > >  - simplify etna_resource_used() flush condition, which also prevents
> > >    potentially flushing resources twice (Marek)
> > >  - don't remove resouces from screen->used_resources in
> > >    etna_cmd_stream_reset_notify(), they may still be used in other
> > >    contexts and may need flushing there later on (Marek)
> > 
> > The patch mostly makes sense to me now, but don't we need to take the
> > screen->lock on all call sites where we do a ctx->flush? Otherwise we
> > may enter etna_cmd_stream_reset_notify unlocked, changing the
> > used_resources set while other threads might use it at the same time,
> > right?
> 
> etna_cmd_stream_reset_notify() takes the lock when accessing the
> used_resources set , see below.

Uh, sorry seems I mixed this up. But then I don't see how this isn't
deadlocking, as AFAICS mtx_lock isn't recursive.

In etna_resource_used() you already lock the screen mutex, then when
you find a context that needs flushing you call the context flush,
which flushes the cmd stream and calls into
etna_cmd_stream_reset_notify() where the mutex is locked again -> self
deadlock.

Regards,
Lucas


> > Regards,
> > Lucas
> > 
> > > ---
> > >  src/gallium/drivers/etnaviv/etnaviv_context.c | 26 +-
> > >  src/gallium/drivers/etnaviv/etnaviv_context.h |  3 --
> > >  .../drivers/etnaviv/etnaviv_resource.c| 52 +++
> > >  .../drivers/etnaviv/etnaviv_resource.h|  8 +--
> > >  src/gallium/drivers/etnaviv/etnaviv_screen.c  | 12 +
> > >  src/gallium/drivers/etnaviv/etnaviv_screen.h  |  6 +++
> > >  6 files changed, 78 insertions(+), 29 deletions(-)
> > > 
> > > diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
> > > b/src/gallium/drivers/etnaviv/etnaviv_context.c
> > > index 3038d21..2f8cae8 100644
> > > --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> > > +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> > > @@ -36,6 +36,7 @@
> > >  #include "etnaviv_query.h"
> > >  #include "etnaviv_query_hw.h"
> > >  #include "etnaviv_rasterizer.h"
> > > +#include "etnaviv_resource.h"
> > >  #include "etnaviv_screen.h"
> > >  #include "etnaviv_shader.h"
> > >  #include "etnaviv_state.h"
> > > @@ -329,7 +330,8 @@ static void
> > >  etna_cmd_stream_reset_notify(struct etna_cmd_stream *stream, void *priv)
> > >  {
> > > struct etna_context *ctx = priv;
> > > -   struct etna_resource *rsc, *rsc_tmp;
> > > +   struct etna_screen *screen = ctx->screen;
> > > +   struct set_entry *entry;
> > >  
> > > etna_set_state(stream, VIVS_GL_API_MODE, VIVS_GL_API_MODE_OPENGL);
> > > etna_set_state(stream, VIVS_GL_VERTEX_ELEMENT_CONFIG, 0x0001);
> > > @@ -384,16 +386,18 @@ etna_cmd_stream_reset_notify(struct etna_cmd_stream 
> > > *stream, void *priv)
> > > ctx->dirty = ~0L;
> > > ctx->dirty_sampler_views = ~0L;
> > >  
> > > -   /* go through all the used resources and clear their status flag */
> > > -   LIST_FOR_EACH_ENTRY_SAFE(rsc, rsc_tmp, >used_resources, list)
> > > -   {
> > > -  debug_assert(rsc->status != 0);
> > > -  rsc->status = 0;
> > > -  rsc->pending_ctx = NULL;
> > > -  list_delinit(>list);
> > > -   }
> > > +   /*
> > > +* Go through all _resources_ associated with this _screen_, pending
> > > +* in this _context_ a

Re: [Mesa-dev] [PATCH v4] etnaviv: fix resource usage tracking across different pipe_context's

[Lucas Stach]

Hi Marek,

Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut:
> > From: Christian Gmeiner 
> 
> A pipe_resource can be shared by all the pipe_context's hanging off the
> same pipe_screen.
> 
> > Signed-off-by: Christian Gmeiner 
> > Signed-off-by: Marek Vasut 
> To: mesa-dev@lists.freedesktop.org
> Cc: etna...@lists.freedesktop.org
> ---
> Changes from v1 -> v2:
>  - to remove the resource from the used_resources set when it is destroyed
> Changes from v2 -> v3:
>  - add locking with mtx_*() to resource and screen (Marek)
> Changes from v3 -> v4:
>  - drop rsc->lock, just use screen->lock for the entire serialization (Marek)
>  - simplify etna_resource_used() flush condition, which also prevents
>    potentially flushing resources twice (Marek)
>  - don't remove resouces from screen->used_resources in
>    etna_cmd_stream_reset_notify(), they may still be used in other
>    contexts and may need flushing there later on (Marek)

The patch mostly makes sense to me now, but don't we need to take the
screen->lock on all call sites where we do a ctx->flush? Otherwise we
may enter etna_cmd_stream_reset_notify unlocked, changing the
used_resources set while other threads might use it at the same time,
right?

Regards,
Lucas

> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.c | 26 +-
>  src/gallium/drivers/etnaviv/etnaviv_context.h |  3 --
>  .../drivers/etnaviv/etnaviv_resource.c| 52 +++
>  .../drivers/etnaviv/etnaviv_resource.h|  8 +--
>  src/gallium/drivers/etnaviv/etnaviv_screen.c  | 12 +
>  src/gallium/drivers/etnaviv/etnaviv_screen.h  |  6 +++
>  6 files changed, 78 insertions(+), 29 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
> b/src/gallium/drivers/etnaviv/etnaviv_context.c
> index 3038d21..2f8cae8 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> @@ -36,6 +36,7 @@
>  #include "etnaviv_query.h"
>  #include "etnaviv_query_hw.h"
>  #include "etnaviv_rasterizer.h"
> +#include "etnaviv_resource.h"
>  #include "etnaviv_screen.h"
>  #include "etnaviv_shader.h"
>  #include "etnaviv_state.h"
> @@ -329,7 +330,8 @@ static void
>  etna_cmd_stream_reset_notify(struct etna_cmd_stream *stream, void *priv)
>  {
> struct etna_context *ctx = priv;
> -   struct etna_resource *rsc, *rsc_tmp;
> +   struct etna_screen *screen = ctx->screen;
> +   struct set_entry *entry;
>  
> etna_set_state(stream, VIVS_GL_API_MODE, VIVS_GL_API_MODE_OPENGL);
> etna_set_state(stream, VIVS_GL_VERTEX_ELEMENT_CONFIG, 0x0001);
> @@ -384,16 +386,18 @@ etna_cmd_stream_reset_notify(struct etna_cmd_stream 
> *stream, void *priv)
> ctx->dirty = ~0L;
> ctx->dirty_sampler_views = ~0L;
>  
> -   /* go through all the used resources and clear their status flag */
> -   LIST_FOR_EACH_ENTRY_SAFE(rsc, rsc_tmp, >used_resources, list)
> -   {
> -  debug_assert(rsc->status != 0);
> -  rsc->status = 0;
> -  rsc->pending_ctx = NULL;
> -  list_delinit(>list);
> -   }
> +   /*
> +* Go through all _resources_ associated with this _screen_, pending
> +* in this _context_ and mark them as not pending in this _context_
> +* anymore, since they were just flushed.
> +*/
> +   mtx_lock(>lock);
> +   set_foreach(screen->used_resources, entry) {
> +  struct etna_resource *rsc = (struct etna_resource *)entry->key;
>  
> -   assert(LIST_IS_EMPTY(>used_resources));
> +  _mesa_set_remove_key(rsc->pending_ctx, ctx);
> +   }
> +   mtx_unlock(>lock);
>  }
>  
>  static void
> @@ -437,8 +441,6 @@ etna_context_create(struct pipe_screen *pscreen, void 
> *priv, unsigned flags)
> /* need some sane default in case state tracker doesn't set some state: */
> ctx->sample_mask = 0x;
>  
> -   list_inithead(>used_resources);
> -
> /*  Set sensible defaults for state */
> etna_cmd_stream_reset_notify(ctx->stream, ctx);
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
> b/src/gallium/drivers/etnaviv/etnaviv_context.h
> index 584caa7..eff0a23 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
> @@ -136,9 +136,6 @@ struct etna_context {
> uint32_t prim_hwsupport;
> struct primconvert_context *primconvert;
>  
> -   /* list of resources used by currently-unsubmitted renders */
> -   struct list_head used_resources;
> -
> struct slab_child_pool transfer_pool;
> struct blitter_context *blitter;
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 3808c29..46ab849 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -33,6 +33,7 @@
>  #include "etnaviv_screen.h"
>  #include "etnaviv_translate.h"
>  
> +#include "util/hash_table.h"
>  #include "util/u_inlines.h"
>  #include "util/u_memory.h"
>  
> @@ -275,7 +276,6 @@ 

Re: [Mesa-dev] [PATCH] etnaviv: implement check_resource_capability

[Lucas Stach]

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 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: Lucas Stach 
> > ---
> >  .../drivers/etnaviv/etnaviv_resource.c| 22 +++
> >  1 file changed, 22 insertions(+)
> > 
> > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> > b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > index c00912880309..cd846e3ae36e 100644
> > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > @@ -624,6 +624,27 @@ etna_resource_get_handle(struct pipe_screen *pscreen,
> > }
> >  }
> > 
> > +static bool
> > +etna_check_resource_capability(struct pipe_screen *pscreen,
> > +   struct pipe_resource *prsc,
> > +   unsigned bind)
> > +{
> > +   struct etna_screen *screen = etna_screen(pscreen);
> > +   struct etna_resource *rsc = etna_resource(prsc);
> > +
> > +   if ((bind & PIPE_BIND_LINEAR) && rsc->layout != ETNA_LAYOUT_LINEAR)
> > +  return false;
> > +
> > +   if ((bind & PIPE_BIND_SCANOUT) && !rsc->scanout) {
> > +  rsc->scanout = renderonly_create_gpu_import_for_resource(prsc, 
> > screen->ro,
> > +   NULL);
> 
> Can you explain me why the
> renderonly_create_gpu_import_for_resource(..) call ends up here? Are
> there really any cases where !rsc->scanout? I looked at the relevant
> code parts and I have the feeling
> the renderonly_create_gpu_import_for_resource(..) call happens much
> earlier in the call chain. I could be
> wrong as I am running out of coffee right now :)

There is one very relevant use-case where we end up with no scanout
resource: dma-buf import on the compositor side with Wayland. On
i.MX6qp we get a client buffer that is perfectly fine for putting
directly on a imx-drm on a plane.

When we import the buffer through GBM we end up with a etnaviv resource
without a scanout handle. GBM will make sure to validate the imported
buffer for scanout before trying to export the KMS handle though. So we
can construct the scanout handle at that point to allow the compositor
to push the client buffer directly onto the plane, skipping the
composition step in some cases.

Regards,
Lucas

> > +  if (!rsc->scanout)
> > + return false;
> > +   }
> > +
> > +   return true;
> > +}
> > +
> >  void
> >  etna_resource_used(struct etna_context *ctx, struct pipe_resource *prsc,
> > enum etna_resource_status status)
> > @@ -667,4 +688,5 @@ etna_resource_screen_init(struct pipe_screen *pscreen)
> > pscreen->resource_get_handle = etna_resource_get_handle;
> > pscreen->resource_changed = etna_resource_changed;
> > pscreen->resource_destroy = etna_resource_destroy;
> > +   pscreen->check_resource_capability = etna_check_resource_capability;
> >  }
> > --
> > 2.19.1
> > 
> > ___
> > etnaviv mailing list
> > etna...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/etnaviv
> 
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 1/2] etnaviv: enable full overwrite in a few more cases

[Lucas Stach]

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 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_blend.c 
b/src/gallium/drivers/etnaviv/etnaviv_blend.c
index 0e2299a50b30..061c9af5247f 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_blend.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_blend.c
@@ -114,6 +114,7 @@ etna_update_blend(struct etna_context *ctx)
struct pipe_blend_state *pblend = ctx->blend;
struct etna_blend_state *blend = etna_blend_state(pblend);
const struct pipe_rt_blend_state *rt0 = >rt[0];
+   const struct util_format_description *desc;
uint32_t colormask;
 
if (pfb->cbufs[0] &&
@@ -128,11 +129,13 @@ etna_update_blend(struct etna_context *ctx)
}
 
/* If the complete render target is written, set full_overwrite:
-* - The color mask is 
-* - No blending is used
+* - The color mask covers all channels of the render target
+* - No blending or logicop is used
 */
-   bool full_overwrite = ((rt0->colormask == 0xf) && blend->fo_allowed) ||
- !pfb->cbufs[0];
+   if (pfb->cbufs[0])
+  desc = util_format_description(pfb->cbufs[0]->format);
+   bool full_overwrite = !pfb->cbufs[0] || ((blend->fo_allowed &&
+ util_format_colormask_full(desc, colormask)));
blend->PE_COLOR_FORMAT =
 VIVS_PE_COLOR_FORMAT_COMPONENTS(colormask) |
 COND(full_overwrite, VIVS_PE_COLOR_FORMAT_OVERWRITE);
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 2/2] etnaviv: annotate variables only used in debug build

[Lucas Stach]

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
---
 src/gallium/drivers/etnaviv/etnaviv_compiler.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c 
b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
index bbc61a59fc67..ceca5b8af997 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
@@ -477,8 +477,7 @@ static void
 etna_compile_parse_declarations(struct etna_compile *c)
 {
struct tgsi_parse_context ctx = { };
-   unsigned status = TGSI_PARSE_OK;
-   status = tgsi_parse_init(, c->tokens);
+   MAYBE_UNUSED unsigned status = tgsi_parse_init(, c->tokens);
assert(status == TGSI_PARSE_OK);
 
while (!tgsi_parse_end_of_tokens()) {
@@ -530,8 +529,7 @@ static void
 etna_compile_pass_check_usage(struct etna_compile *c)
 {
struct tgsi_parse_context ctx = { };
-   unsigned status = TGSI_PARSE_OK;
-   status = tgsi_parse_init(, c->tokens);
+   MAYBE_UNUSED unsigned status = tgsi_parse_init(, c->tokens);
assert(status == TGSI_PARSE_OK);
 
for (int idx = 0; idx < c->total_decls; ++idx) {
@@ -662,8 +660,7 @@ etna_compile_pass_optimize_outputs(struct etna_compile *c)
 {
struct tgsi_parse_context ctx = { };
int inst_idx = 0;
-   unsigned status = TGSI_PARSE_OK;
-   status = tgsi_parse_init(, c->tokens);
+   MAYBE_UNUSED unsigned status = tgsi_parse_init(, c->tokens);
assert(status == TGSI_PARSE_OK);
 
while (!tgsi_parse_end_of_tokens()) {
@@ -1812,7 +1809,7 @@ static void
 etna_compile_pass_generate_code(struct etna_compile *c)
 {
struct tgsi_parse_context ctx = { };
-   unsigned status = tgsi_parse_init(, c->tokens);
+   MAYBE_UNUSED unsigned status = tgsi_parse_init(, c->tokens);
assert(status == TGSI_PARSE_OK);
 
int inst_idx = 0;
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] etnaviv: implement check_resource_capability

[Lucas Stach]

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: Lucas Stach 
---
 .../drivers/etnaviv/etnaviv_resource.c| 22 +++
 1 file changed, 22 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index c00912880309..cd846e3ae36e 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -624,6 +624,27 @@ etna_resource_get_handle(struct pipe_screen *pscreen,
}
 }
 
+static bool
+etna_check_resource_capability(struct pipe_screen *pscreen,
+   struct pipe_resource *prsc,
+   unsigned bind)
+{
+   struct etna_screen *screen = etna_screen(pscreen);
+   struct etna_resource *rsc = etna_resource(prsc);
+
+   if ((bind & PIPE_BIND_LINEAR) && rsc->layout != ETNA_LAYOUT_LINEAR)
+  return false;
+
+   if ((bind & PIPE_BIND_SCANOUT) && !rsc->scanout) {
+  rsc->scanout = renderonly_create_gpu_import_for_resource(prsc, 
screen->ro,
+   NULL);
+  if (!rsc->scanout)
+ return false;
+   }
+
+   return true;
+}
+
 void
 etna_resource_used(struct etna_context *ctx, struct pipe_resource *prsc,
enum etna_resource_status status)
@@ -667,4 +688,5 @@ etna_resource_screen_init(struct pipe_screen *pscreen)
pscreen->resource_get_handle = etna_resource_get_handle;
pscreen->resource_changed = etna_resource_changed;
pscreen->resource_destroy = etna_resource_destroy;
+   pscreen->check_resource_capability = etna_check_resource_capability;
 }
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/wayland: break double/tripple buffering feedback loops

[Lucas Stach]

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 can lead to feedback 
> > loops
> > between the compositor and the application causing rapid toggling between
> > double and tripple buffering. Scenario: 2 buffers already qeued to the
> > compositor, egl/wayland allocates a new back buffer to avoid trottling,
> > slowing down the frame, this allows the compositor to catch up and unlock
> > both buffers, then EGL detects that there are more buffers than currently
> > need, freeing the buffer, restartig the loop shortly after.
> > 
> > To avoid wasting 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 deletions(-)
> > 
> > diff --git a/src/egl/drivers/dri2/platform_wayland.c 
> > b/src/egl/drivers/dri2/platform_wayland.c
> > index 34e09d7ec167..3fa08c1639d1 100644
> > --- a/src/egl/drivers/dri2/platform_wayland.c
> > +++ b/src/egl/drivers/dri2/platform_wayland.c
> > @@ -474,15 +474,17 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
> > wl_display_dispatch_queue_pending(dri2_dpy->wl_dpy, 
> > dri2_surf->wl_queue);
> > 
> > while (dri2_surf->back == NULL) {
> > +  int age = 0;
> >    for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
> >   /* Get an unlocked buffer, preferably one with a dri_buffer
> >    * already allocated. */
> > - if (dri2_surf->color_buffers[i].locked)
> > + if (dri2_surf->color_buffers[i].locked || 
> > dri2_surf->color_buffers[i].age < age)
> >  continue;
> >   if (dri2_surf->back == NULL)
> >  dri2_surf->back = _surf->color_buffers[i];
> > - else if (dri2_surf->back->dri_image == NULL)
> > + else if (dri2_surf->back->dri_image == NULL && 
> > dri2_surf->color_buffers[i].dri_image)
> >  dri2_surf->back = _surf->color_buffers[i];
> > + age = dri2_surf->back->age;
> >    }
> > 
> 
> AFAICT this is the wayland equivalent of
> 4f1d27a406478d405eac6f9894ccc46a80034adb
> Where the exact same logic/commit message applies.

No it isn't. It's exactly what it says in the commit log. It's keeping
the tripple buffer around for a bit, even if we don't strictly need it
when the client is currently doing double buffering.

When things are on the edge between double buffering being enough and
sometimes a third buffer being needed to avoid stalling we would
otherwise bounce rapidly between allocating and disposing the third
buffer.

The DRM platform has no such optimization and just keeps the third
buffer around forever. This patch keeps the optimization in the Wayland
platform, but adds a bit of hysteresis before disposing the buffer when
going from tripple to double buffering to see if things are settling on
double buffering.

> Can you please split that up? I'd imagine this isn't enough to for the
> usecase you had in mind?
> 
> >    if (dri2_surf->back)
> > @@ -615,10 +617,13 @@ update_buffers(struct dri2_egl_surface *dri2_surf)
> > 
> > /* If we have an extra unlocked buffer at this point, we had to do 
> > triple
> >  * buffering for a while, but now can go back to just double buffering.
> > -* That means we can free any unlocked buffer now. */
> > +* That means we can free any unlocked buffer now. To avoid toggling 
> > between
> > +* going back to double buffering and needing to allocate third buffer 
> > too
> > +* fast we let the unneeded buffer sit around for a short while. */
> > for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
> >    if (!dri2_surf->color_buffers[i].locked &&
> > -  dri2_surf->color_buffers[i].wl_buffer) {
> > +  dri2_surf->color_buffers[i].wl_buffer &&
> > +  dri2_surf->color_buffers[i].age > 18) {
> 
> The age check here seems strange - both number used and it's relation
> to double/triple buffering.
> Have you considered tracking/checking how many buffers we have?

A hysteresis value of 18 is just something that worked well in
practice. It didn't appear to defer the buffer destruction for too long
 while keeping the feedback loop well under control.

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] egl/wayland: break double/tripple buffering feedback loops

[Lucas Stach]

Currently we dispose any unneeded color buffers immediately if we detect that
there are more unlocked buffers than we need. This can lead to feedback loops
between the compositor and the application causing rapid toggling between
double and tripple buffering. Scenario: 2 buffers already qeued to the
compositor, egl/wayland allocates a new back buffer to avoid trottling,
slowing down the frame, this allows the compositor to catch up and unlock
both buffers, then EGL detects that there are more buffers than currently
need, freeing the buffer, restartig the loop shortly after.

To avoid wasting 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 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 34e09d7ec167..3fa08c1639d1 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -474,15 +474,17 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
wl_display_dispatch_queue_pending(dri2_dpy->wl_dpy, dri2_surf->wl_queue);
 
while (dri2_surf->back == NULL) {
+  int age = 0;
   for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
  /* Get an unlocked buffer, preferably one with a dri_buffer
   * already allocated. */
- if (dri2_surf->color_buffers[i].locked)
+ if (dri2_surf->color_buffers[i].locked || 
dri2_surf->color_buffers[i].age < age)
 continue;
  if (dri2_surf->back == NULL)
 dri2_surf->back = _surf->color_buffers[i];
- else if (dri2_surf->back->dri_image == NULL)
+ else if (dri2_surf->back->dri_image == NULL && 
dri2_surf->color_buffers[i].dri_image)
 dri2_surf->back = _surf->color_buffers[i];
+ age = dri2_surf->back->age;
   }
 
   if (dri2_surf->back)
@@ -615,10 +617,13 @@ update_buffers(struct dri2_egl_surface *dri2_surf)
 
/* If we have an extra unlocked buffer at this point, we had to do triple
 * buffering for a while, but now can go back to just double buffering.
-* That means we can free any unlocked buffer now. */
+* That means we can free any unlocked buffer now. To avoid toggling between
+* going back to double buffering and needing to allocate third buffer too
+* fast we let the unneeded buffer sit around for a short while. */
for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
   if (!dri2_surf->color_buffers[i].locked &&
-  dri2_surf->color_buffers[i].wl_buffer) {
+  dri2_surf->color_buffers[i].wl_buffer &&
+  dri2_surf->color_buffers[i].age > 18) {
  wl_buffer_destroy(dri2_surf->color_buffers[i].wl_buffer);
  dri2_dpy->image->destroyImage(dri2_surf->color_buffers[i].dri_image);
  if (dri2_dpy->is_different_gpu)
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: drop redundant ctx function parameter

[Lucas Stach]

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/gallium/drivers/etnaviv/etnaviv_shader.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_shader.c 
> b/src/gallium/drivers/etnaviv/etnaviv_shader.c
> index 27c735b83b..d2d736bdee 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_shader.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_shader.c
> @@ -230,8 +230,7 @@ etna_shader_link(struct etna_context *ctx)
>  }
>  
>  static bool
> -etna_shader_update_vs_inputs(struct etna_context *ctx,
> - struct compiled_shader_state *cs,
> +etna_shader_update_vs_inputs(struct compiled_shader_state *cs,
>   const struct etna_shader_variant *vs,
>   const struct compiled_vertex_elements_state 
> *ves)
>  {
> @@ -246,7 +245,7 @@ etna_shader_update_vs_inputs(struct etna_context *ctx,
> num_vs_inputs = MAX2(ves->num_elements, vs->infile.num_reg);
> if (num_vs_inputs != ves->num_elements) {
>    BUG("Number of elements %u does not match the number of VS inputs %zu",
> -  ctx->vertex_elements->num_elements, 
> ctx->shader.vs->infile.num_reg);
> +  ves->num_elements, vs->infile.num_reg);
>    return false;
> }
>  
> @@ -312,7 +311,7 @@ dump_shader_info(struct etna_shader_variant *v, struct 
> pipe_debug_callback *debu
>  bool
>  etna_shader_update_vertex(struct etna_context *ctx)
>  {
> -   return etna_shader_update_vs_inputs(ctx, >shader_state, 
> ctx->shader.vs,
> +   return etna_shader_update_vs_inputs(>shader_state, ctx->shader.vs,
> ctx->vertex_elements);
>  }
>  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: Make sure rs alignment checks match

[Lucas Stach]

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: target=2, 
> > format=PIPE_FORMAT_B8G8R8X8_UNORM, 1080x1920x1, array_size=1, last_level=0, 
> > nr_samples=0, usage=0, bind=8000a, flags=0
> >    etna_resource_from_handle:541: BO stride 4320 is too small for RS engine 
> > width padding (4352, format PIPE_FORMAT_B8G8R8X8_UNORM)
> > 
> > since etna_resource_from_handle wants to be aligned to a 16 byte
> > boundary while the etna_resource_alloc does not.
> > 
> > Adjust the two checks by using a common function.
> 
> Ping?

Thanks, I've finally pushed this to Mesa master.

Regards,
Lucas

> > 
> > Broken by baff59ebf07a114f95ad66d1f54e4b1f409eebee
> > 
> > > > Signed-off-by: Guido Günther 
> > ---
> >  .../drivers/etnaviv/etnaviv_resource.c| 19 +--
> >  1 file changed, 13 insertions(+), 6 deletions(-)
> > 
> > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> > b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > index 7fd374ae23d..f18c6ec6bfc 100644
> > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > @@ -176,6 +176,15 @@ setup_miptree(struct etna_resource *rsc, unsigned 
> > paddingX, unsigned paddingY,
> > return size;
> >  }
> >  
> > +/* Is rs alignment needed? */
> > +static bool is_rs_align(struct etna_screen *screen,
> > +const struct pipe_resource *tmpl)
> > +{
> > +   return screen->specs.use_blt ? false : (
> > +  VIV_FEATURE(screen, chipMinorFeatures1, TEXTURE_HALIGN) ||
> > +  !etna_resource_sampler_only(tmpl));
> > +}
> > +
> >  /* Create a new resource object, using the given template info */
> >  struct pipe_resource *
> >  etna_resource_alloc(struct pipe_screen *pscreen, unsigned layout,
> > @@ -217,11 +226,9 @@ etna_resource_alloc(struct pipe_screen *pscreen, 
> > unsigned layout,
> > * resolve engine's width.  If not, we must not align resources used
> > * only for textures. If this GPU uses the BLT engine, never do RS 
> > align.
> > */
> > -  bool rs_align = screen->specs.use_blt ? false : (
> > - VIV_FEATURE(screen, chipMinorFeatures1, 
> > TEXTURE_HALIGN) ||
> > - !etna_resource_sampler_only(templat));
> > -  etna_layout_multiple(layout, screen->specs.pixel_pipes, rs_align, 
> > ,
> > -   , );
> > +  etna_layout_multiple(layout, screen->specs.pixel_pipes,
> > +   is_rs_align (screen, templat),
> > +   , , );
> >    assert(paddingX && paddingY);
> > } else {
> >    /* Compressed textures are padded to their block size, but we don't 
> > have
> > @@ -519,7 +526,7 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
> > /* Determine padding of the imported resource. */
> > unsigned paddingX = 0, paddingY = 0;
> > etna_layout_multiple(rsc->layout, screen->specs.pixel_pipes,
> > -VIV_FEATURE(screen, chipMinorFeatures1, 
> > TEXTURE_HALIGN),
> > +is_rs_align(screen, tmpl),
> >  , , >halign);
> >  
> > if (!screen->specs.use_blt)
> > -- 
> > 2.18.0
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] etnaviv: annotate variables only used in debug build

[Lucas Stach]

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 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c 
b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
index bbc61a59fc67..386136e46836 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
@@ -477,7 +477,7 @@ static void
 etna_compile_parse_declarations(struct etna_compile *c)
 {
struct tgsi_parse_context ctx = { };
-   unsigned status = TGSI_PARSE_OK;
+   MAYBE_UNUSED unsigned status = TGSI_PARSE_OK;
status = tgsi_parse_init(, c->tokens);
assert(status == TGSI_PARSE_OK);
 
@@ -530,7 +530,7 @@ static void
 etna_compile_pass_check_usage(struct etna_compile *c)
 {
struct tgsi_parse_context ctx = { };
-   unsigned status = TGSI_PARSE_OK;
+   MAYBE_UNUSED unsigned status = TGSI_PARSE_OK;
status = tgsi_parse_init(, c->tokens);
assert(status == TGSI_PARSE_OK);
 
@@ -662,7 +662,7 @@ etna_compile_pass_optimize_outputs(struct etna_compile *c)
 {
struct tgsi_parse_context ctx = { };
int inst_idx = 0;
-   unsigned status = TGSI_PARSE_OK;
+   MAYBE_UNUSED unsigned status = TGSI_PARSE_OK;
status = tgsi_parse_init(, c->tokens);
assert(status == TGSI_PARSE_OK);
 
@@ -1812,7 +1812,7 @@ static void
 etna_compile_pass_generate_code(struct etna_compile *c)
 {
struct tgsi_parse_context ctx = { };
-   unsigned status = tgsi_parse_init(, c->tokens);
+   MAYBE_UNUSED unsigned status = tgsi_parse_init(, c->tokens);
assert(status == TGSI_PARSE_OK);
 
int inst_idx = 0;
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4] etnaviv: use surface format directly

[Lucas Stach]

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 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_blend.c 
b/src/gallium/drivers/etnaviv/etnaviv_blend.c
index 9c23411d4ff7..1792fd0fdd67 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_blend.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_blend.c
@@ -117,7 +117,7 @@ etna_update_blend(struct etna_context *ctx)
uint32_t colormask;
 
if (pfb->cbufs[0] &&
-   translate_rs_format_rb_swap(pfb->cbufs[0]->texture->format)) {
+   translate_rs_format_rb_swap(pfb->cbufs[0]->format)) {
   colormask = rt0->colormask & (PIPE_MASK_A | PIPE_MASK_G);
   if (rt0->colormask & PIPE_MASK_R)
  colormask |= PIPE_MASK_B;
diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
b/src/gallium/drivers/etnaviv/etnaviv_context.c
index 1c305d82a0fc..aa7425662898 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_context.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
@@ -212,13 +212,8 @@ etna_draw_vbo(struct pipe_context *pctx, const struct 
pipe_draw_info *info)
ctx->dirty |= ETNA_DIRTY_INDEX_BUFFER;
 
struct etna_shader_key key = {};
-   struct etna_surface *cbuf = etna_surface(pfb->cbufs[0]);
-
-   if (cbuf) {
-  struct etna_resource *res = etna_resource(cbuf->base.texture);
-
-  key.frag_rb_swap = !!translate_rs_format_rb_swap(res->base.format);
-   }
+   if (pfb->cbufs[0])
+  key.frag_rb_swap = !!translate_rs_format_rb_swap(pfb->cbufs[0]->format);
 
if (!etna_get_vs(ctx, key) || !etna_get_fs(ctx, key)) {
   BUG("compiled shaders are not okay");
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/4] etnaviv: use dummy RT buffer when rendering without color buffer

[Lucas Stach]

At least GC2000 seems to push some dirt from the PE color cache into
the last bound render target when drawing depth only. Newer cores
seem to behave properly and don't do this, but I have found no way
to fix it on GC2000. Flushes and stalls don't seem to make any
difference.

In order to 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/gallium/drivers/etnaviv/etnaviv_state.c   |  5 +++--
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
b/src/gallium/drivers/etnaviv/etnaviv_context.c
index 3038d210e109..1c305d82a0fc 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_context.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
@@ -60,6 +60,9 @@ etna_context_destroy(struct pipe_context *pctx)
 {
struct etna_context *ctx = etna_context(pctx);
 
+   if (ctx->dummy_rt)
+  etna_bo_del(ctx->dummy_rt);
+
if (ctx->primconvert)
   util_primconvert_destroy(ctx->primconvert);
 
@@ -486,6 +489,16 @@ etna_context_create(struct pipe_screen *pscreen, void 
*priv, unsigned flags)
slab_create_child(>transfer_pool, >transfer_pool);
list_inithead(>active_hw_queries);
 
+   /* create dummy RT buffer, used when rendering with no color buffer */
+   ctx->dummy_rt = etna_bo_new(ctx->screen->dev, 64 * 64 * 4,
+   DRM_ETNA_GEM_CACHE_WC);
+   if (!ctx->dummy_rt)
+  goto fail;
+
+   ctx->dummy_rt_reloc.bo = ctx->dummy_rt;
+   ctx->dummy_rt_reloc.offset = 0;
+   ctx->dummy_rt_reloc.flags = ETNA_RELOC_READ | ETNA_RELOC_WRITE;
+
return pctx;
 
 fail:
diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
b/src/gallium/drivers/etnaviv/etnaviv_context.h
index 584caa77080b..6ad9f3431e15 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_context.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
@@ -190,6 +190,9 @@ struct etna_context {
 
/* list of active hardware queries */
struct list_head active_hw_queries;
+
+   struct etna_bo *dummy_rt;
+   struct etna_reloc dummy_rt_reloc;
 };
 
 static inline struct etna_context *
diff --git a/src/gallium/drivers/etnaviv/etnaviv_state.c 
b/src/gallium/drivers/etnaviv/etnaviv_state.c
index 87ba10b0dc98..006bf3016812 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_state.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_state.c
@@ -191,8 +191,9 @@ etna_set_framebuffer_state(struct pipe_context *pctx,
   cs->TS_COLOR_STATUS_BASE.bo = NULL;
   cs->TS_COLOR_SURFACE_BASE.bo = NULL;
 
-  for (int i = 0; i < ETNA_MAX_PIXELPIPES; i++)
- cs->PE_PIPE_COLOR_ADDR[i].bo = NULL;
+  cs->PE_COLOR_ADDR = ctx->dummy_rt_reloc;
+  for (int i = 0; i < ctx->specs.pixel_pipes; i++)
+ cs->PE_PIPE_COLOR_ADDR[i] = ctx->dummy_rt_reloc;
}
 
if (sv->zsbuf != NULL) {
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/4] etnaviv: enable full overwrite in a few more cases

[Lucas Stach]

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, 5 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_blend.c 
b/src/gallium/drivers/etnaviv/etnaviv_blend.c
index 1792fd0fdd67..2bf081c2e710 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_blend.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_blend.c
@@ -114,6 +114,7 @@ etna_update_blend(struct etna_context *ctx)
struct pipe_blend_state *pblend = ctx->blend;
struct etna_blend_state *blend = etna_blend_state(pblend);
const struct pipe_rt_blend_state *rt0 = >rt[0];
+   const struct util_format_description *desc;
uint32_t colormask;
 
if (pfb->cbufs[0] &&
@@ -131,8 +132,10 @@ etna_update_blend(struct etna_context *ctx)
 * - The color mask is 
 * - No blending is used
 */
-   bool full_overwrite = ((rt0->colormask == 0xf) && blend->fo_allowed) ||
- !pfb->cbufs[0];
+   if (pfb->cbufs[0])
+  desc = util_format_description(pfb->cbufs[0]->format);
+   bool full_overwrite = !pfb->cbufs[0] || ((blend->fo_allowed &&
+ util_format_colormask_full(desc, colormask)));
blend->PE_COLOR_FORMAT =
 VIVS_PE_COLOR_FORMAT_COMPONENTS(colormask) |
 COND(full_overwrite, VIVS_PE_COLOR_FORMAT_OVERWRITE);
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: Use write combine instead of unached mappings for shader bo

[Lucas Stach]

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 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_shader.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_shader.c 
> b/src/gallium/drivers/etnaviv/etnaviv_shader.c
> index 04ababc801f..27c735b83bd 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_shader.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_shader.c
> @@ -41,7 +41,7 @@ static bool etna_icache_upload_shader(struct etna_context 
> *ctx, struct etna_shad
>  {
> if (v->bo)
>    return true;
> -   v->bo = etna_bo_new(ctx->screen->dev, v->code_size*4, 
> DRM_ETNA_GEM_CACHE_UNCACHED);
> +   v->bo = etna_bo_new(ctx->screen->dev, v->code_size*4, 
> DRM_ETNA_GEM_CACHE_WC);
> if (!v->bo)
>    return false;

Thanks, pushed to mesa master.

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] imx/etnaviv: loader_open_render_node() fails

[Lucas Stach]

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, 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 up etnaviv for GL rendering, but always reverts to
> > softpipe. A bit of debugging revealed that the following codepath fails:
> > 
> > imx_drm_screen_create -> loader_open_render_node("etnaviv") ->
> > drmGetDevices2 -> drmProcessPlatformDevice(... "/dev/dri/renderD128") ->
> > drmParsePlatformBusInfo -> sysfs_uevent_get
> > 
> > The latter function opens /sys/dev/char/226:128/device/uevent and looks
> > for OF_FULLNAME, but this key is not present on my system. The node
> > contains only:
> > 
> > DRIVER=etnaviv
> > MODALIAS=platform:etnaviv
> > 
> > Whereas /sys/dev/char/226:0/device/uevent contains:
> > 
> > DRIVER=imx-drm
> > OF_NAME=display-subsystem
> > OF_FULLNAME=/display-subsystem
> > OF_COMPATIBLE_0=fsl,imx-display-subsystem
> > OF_COMPATIBLE_N=1
> > 
> > Which is not the render node.
> > 
> > > > According to https://patchwork.kernel.org/patch/9487631/#19940985 there
> > should be more lines (device tree related?) in the uevent file for the
> > render node, and I wonder why they don't exist.
> > 
> 
> Have you considered checking other kernels?
> 
> AFAICT entries like that should not just disappear from the uevent file.
> My personal, slightly biased, opinion is to track down what broke in
> kernel land.

I've just pointed out the kernel change that broke things in my other
mail. While it did apparently break libdrm it is a technically correct
change, so I would rather see libdrm fixed to deal with this than
reverting the kernel change (I'll still do it to not violate the kernel
no regressions rule if someone insists)

This should still be possible, as the regression is only present in the
master branch of mesa and won't end up in any currently tagged mesa
version.

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] imx/etnaviv: loader_open_render_node() fails

[Lucas Stach]

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 up etnaviv for GL rendering, but always reverts to
> softpipe. A bit of debugging revealed that the following codepath fails:
> 
> imx_drm_screen_create -> loader_open_render_node("etnaviv") ->
> drmGetDevices2 -> drmProcessPlatformDevice(... "/dev/dri/renderD128") ->
> drmParsePlatformBusInfo -> sysfs_uevent_get
> 
> The latter function opens /sys/dev/char/226:128/device/uevent and looks
> for OF_FULLNAME, but this key is not present on my system. The node
> contains only:
> 
> DRIVER=etnaviv
> MODALIAS=platform:etnaviv
> 
> Whereas /sys/dev/char/226:0/device/uevent contains:
> 
> DRIVER=imx-drm
> OF_NAME=display-subsystem
> OF_FULLNAME=/display-subsystem
> OF_COMPATIBLE_0=fsl,imx-display-subsystem
> OF_COMPATIBLE_N=1
> 
> Which is not the render node.
> 
> > According to https://patchwork.kernel.org/patch/9487631/#19940985 there
> should be more lines (device tree related?) in the uevent file for the
> render node, and I wonder why they don't exist.

Since kernel 4.17 (drm/etnaviv: remove the need for a gpu-subsystem DT
node) the etnaviv DRM driver doesn't have an associated DT node
anymore. This is technically correct, as the etnaviv device is a
virtual device driving multiple hardware devices.

libdrm should be fixed to properly deal with this.

Regards,
Lucas


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/21] Towards NIR support for etnaviv

[Lucas Stach]

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 optimizations, better support
> > for non-trivial code transformations, better register allocation, and
> > the promise of OpenCL and SPIR-V support in the future.
> > 
> > Michael and I have used our annual exploratory "tech week" last year
> > and last week to get acquainted with NIR and the Vivante GPUs a bit and
> > to get started compiling NIR shaders from the GLSL compiler to Vivante
> > machine code.
> > 
> > The following patches are still very much work in progress. Until now,
> > this has only been tested with kmscube, weston, and glmark2 (and some
> > benchmarks are not working yet, missing instruction implementations).
> > We haven't even dared to run piglit yet. At this point we'd very much
> > like some feedback on where we are on the right path, and where things
> > could be done in a better way.
> > The NIR compiler is placed next to the current TGSI translation layer,
> > and still uses the same backend for code emission. NIR support is
> > disabled by default, and can be enabled using the etnaviv environment
> > option: ETNA_MESA_DEBUG="nir", so this could be merged without side
> > effects, once it is deemed acceptable, to support further development
> > in-tree.
> > 
> > Due to the shared global register file, reducing the amount of temporary
> > registers used by a shader is important for parallelism. We have added
> > added a layer of virtual registers with less than four components over
> > each vec4 base register using the register allocator utility, and use
> > source swizzles and destination write masks to reuse the free components
> > of partially occupied registers if possible.
> > We use the NIR global registers, indexed to represent the registers in
> > the global temporary register file, which allows us to do register
> > assignment in NIR and then reuse the current code emitter without
> > introducing another intermediate representation.
> > 
> > There are already a few Vivante specific lowering passes, but we
> > notably are still missing support for loops, and for lowering sin,
> > cos and log functions to the Vivante specific hardware instructions
> > that need prescaling and post-multiplication of the results' x and
> > y components (or to replace them with approximations where the
> > instructions are not supported).
> > 
> 
> Thanks for this nice patch series. I have been working for too long on
> the nir topic
> for etnaviv and never pushed any patches (which is quite sad). I have taken
> another route to tackle it. I have started with a low level library to
> generate valid
> Vivante binaries and to be able to disassemble them. On top of this, I
> have an eir
> library which is a simple block based ir which makes use of the low-level lib.
> And the last thing is the actual compiler which is nir based. All life outside
> of the gallium driver and have some gtest based unit tests. My main goal was 
> to
> start from a green field without looking at the current tgsi based compiler.
> 
> I will have a deeper look at your patches and review them. I am quite
> unsure what I
> will do with my current code. I think the best would be to clean it up
> and push it.

Did you get a chance to look at this? Will you be able to provide some
review comments? This code is already starting to bitrot and it would
be a shame if the work that has gone into this is going down the drain
due to being stuck on the mailinglist.

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: Check pipe_screen::resource_changed before dereferencing it

[Lucas Stach]

Am Donnerstag, den 12.07.2018, 16:33 +0200 schrieb Michel Dänzer:
> > From: Michel Dänzer 
> 
> It's optional, only implemented by the etnaviv driver so far.
> 
> Fixes: 501d0edeca32 "st/mesa: call resource_changed when binding a
>  EGLImage to a 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 | 3 ++-
>  src/gallium/auxiliary/driver_rbug/rbug_screen.c | 3 ++-
>  src/gallium/auxiliary/driver_trace/tr_screen.c  | 3 ++-
>  src/mesa/state_tracker/st_cb_eglimage.c | 3 ++-
>  4 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/driver_ddebug/dd_screen.c 
> b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> index 5b2be28a969..5f922d884fe 100644
> --- a/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> +++ b/src/gallium/auxiliary/driver_ddebug/dd_screen.c
> @@ -284,7 +284,8 @@ dd_screen_resource_changed(struct pipe_screen *_screen,
>  {
> struct pipe_screen *screen = dd_screen(_screen)->screen;
>  
> -   screen->resource_changed(screen, res);
> +   if (screen->resource_changed)
> +  screen->resource_changed(screen, res);
>  }
>  
>  static void
> diff --git a/src/gallium/auxiliary/driver_rbug/rbug_screen.c 
> b/src/gallium/auxiliary/driver_rbug/rbug_screen.c
> index 2477edbadf0..a1a77add734 100644
> --- a/src/gallium/auxiliary/driver_rbug/rbug_screen.c
> +++ b/src/gallium/auxiliary/driver_rbug/rbug_screen.c
> @@ -222,7 +222,8 @@ rbug_screen_resource_changed(struct pipe_screen *_screen,
> struct pipe_screen *screen = rb_screen->screen;
> struct pipe_resource *resource = rb_resource->resource;
>  
> -   screen->resource_changed(screen, resource);
> +   if (screen->resource_changed)
> +  screen->resource_changed(screen, resource);
>  }
>  
>  static void
> diff --git a/src/gallium/auxiliary/driver_trace/tr_screen.c 
> b/src/gallium/auxiliary/driver_trace/tr_screen.c
> index d5a81249b51..704b2a3c72d 100644
> --- a/src/gallium/auxiliary/driver_trace/tr_screen.c
> +++ b/src/gallium/auxiliary/driver_trace/tr_screen.c
> @@ -444,7 +444,8 @@ trace_screen_resource_changed(struct pipe_screen *_screen,
> trace_dump_arg(ptr, screen);
> trace_dump_arg(ptr, resource);
>  
> -   screen->resource_changed(screen, resource);
> +   if (screen->resource_changed)
> +  screen->resource_changed(screen, resource);
>  
> trace_dump_call_end();
>  }
> diff --git a/src/mesa/state_tracker/st_cb_eglimage.c 
> b/src/mesa/state_tracker/st_cb_eglimage.c
> index 4f33cb4bb06..0db2efc01cf 100644
> --- a/src/mesa/state_tracker/st_cb_eglimage.c
> +++ b/src/mesa/state_tracker/st_cb_eglimage.c
> @@ -229,7 +229,8 @@ st_bind_egl_image(struct gl_context *ctx,
> pipe_resource_reference(>pt, stimg->texture);
> st_texture_release_all_sampler_views(st, stObj);
> pipe_resource_reference(>pt, stObj->pt);
> -   st->pipe->screen->resource_changed(st->pipe->screen, stImage->pt);
> +   if (st->pipe->screen->resource_changed)
> +  st->pipe->screen->resource_changed(st->pipe->screen, stImage->pt);
>  
> stObj->surface_format = stimg->format;
> stObj->level_override = stimg->level;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/mesa: call resource_changed when binding a EGLImage to a texture

[Lucas Stach]

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/st_cb_eglimage.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/state_tracker/st_cb_eglimage.c 
b/src/mesa/state_tracker/st_cb_eglimage.c
index bb092a2f6ef1..4f33cb4bb062 100644
--- a/src/mesa/state_tracker/st_cb_eglimage.c
+++ b/src/mesa/state_tracker/st_cb_eglimage.c
@@ -229,6 +229,7 @@ st_bind_egl_image(struct gl_context *ctx,
pipe_resource_reference(>pt, stimg->texture);
st_texture_release_all_sampler_views(st, stObj);
pipe_resource_reference(>pt, stObj->pt);
+   st->pipe->screen->resource_changed(st->pipe->screen, stImage->pt);
 
stObj->surface_format = stimg->format;
stObj->level_override = stimg->level;
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 6/9] etnaviv: add 2D GPU YUV->RGB blitter

[Lucas Stach]

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 ++
 src/gallium/drivers/etnaviv/etnaviv_2d.h  |   37 +
 src/gallium/drivers/etnaviv/hw/state_2d.xml.h | 1499 +
 4 files changed, 1704 insertions(+)
 create mode 100644 src/gallium/drivers/etnaviv/etnaviv_2d.c
 create mode 100644 src/gallium/drivers/etnaviv/etnaviv_2d.h
 create mode 100644 src/gallium/drivers/etnaviv/hw/state_2d.xml.h

diff --git a/src/gallium/drivers/etnaviv/Makefile.sources 
b/src/gallium/drivers/etnaviv/Makefile.sources
index 0b208122..d1c9c2db166e 100644
--- a/src/gallium/drivers/etnaviv/Makefile.sources
+++ b/src/gallium/drivers/etnaviv/Makefile.sources
@@ -3,11 +3,13 @@ C_SOURCES :=  \
hw/common.xml.h \
hw/common_3d.xml.h \
hw/isa.xml.h \
+   hw/state_2d.xml.h \
hw/state_3d.xml.h \
hw/state_blt.xml.h \
hw/state.xml.h \
hw/texdesc_3d.xml.h \
\
+   etnaviv_2d.c \
etnaviv_asm.c \
etnaviv_asm.h \
etnaviv_blend.c \
diff --git a/src/gallium/drivers/etnaviv/etnaviv_2d.c 
b/src/gallium/drivers/etnaviv/etnaviv_2d.c
new file mode 100644
index ..8b9e5399ce99
--- /dev/null
+++ b/src/gallium/drivers/etnaviv/etnaviv_2d.c
@@ -0,0 +1,166 @@
+/*
+ * Copyright (c) 2018 Etnaviv Project
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include "etnaviv_2d.h"
+#include "etnaviv_context.h"
+#include "etnaviv_emit.h"
+#include "etnaviv_screen.h"
+
+#include "pipe/p_state.h"
+#include "util/u_format.h"
+
+#include "hw/state_2d.xml.h"
+
+#include 
+
+#define EMIT_STATE(state_name, src_value) \
+   etna_coalsence_emit(stream, , VIVS_##state_name, src_value)
+
+#define EMIT_STATE_RELOC(state_name, src_value) \
+   etna_coalsence_emit_reloc(stream, , VIVS_##state_name, src_value)
+
+bool etna_try_2d_blit(struct pipe_context *pctx,
+  const struct pipe_blit_info *blit_info)
+{
+   struct etna_context *ctx = etna_context(pctx);
+   struct etna_cmd_stream *stream = ctx->stream2d;
+   struct etna_coalesce coalesce;
+   struct etna_reloc ry, ru, rv, rdst;
+   struct pipe_resource *res_y, *res_u, *res_v, *res_dst;
+   uint32_t src_format;
+
+   assert(util_format_is_yuv(blit_info->src.format));
+   assert(blit_info->dst.format == PIPE_FORMAT_R8G8B8A8_UNORM);
+
+   if (!stream)
+  return FALSE;
+
+   switch (blit_info->src.format) {
+   case PIPE_FORMAT_NV12:
+  src_format = DE_FORMAT_NV12;
+  break;
+   case PIPE_FORMAT_YUYV:
+  src_format = DE_FORMAT_YUY2;
+  break;
+   default:
+  return FALSE;
+   }
+
+   res_y = blit_info->src.resource;
+   res_u = res_y->next ? res_y->next : res_y;
+   res_v = res_u->next ? res_u->next : res_u;
+
+   ry.bo = etna_resource(res_y)->bo;
+   ry.offset = etna_resource(res_y)->offset;
+   ru.bo = etna_resource(res_u)->bo;
+   ru.offset = etna_resource(res_u)->offset;
+   rv.bo = etna_resource(res_v)->bo;
+   rv.offset = etna_resource(res_v)->offset;
+
+   ry.flags = ru.flags = rv.flags = ETNA_RELOC_READ;
+
+   res_dst = blit_info->dst.resource;
+   rdst.bo = etna_resource(res_dst)->bo;
+   rdst.flags = ETNA_RELOC_WRITE;
+   rdst.offset = 0;
+
+   assert(etna_resource(res_dst)->layout == ETNA_LAYOUT_TILED);
+
+   etna_coalesce_start(stream, );
+
+   EMIT_STATE_RELOC(DE_SRC_ADDRESS, );
+   EMIT_STATE(DE_SRC_STRIDE, etna_resource(res_y)->levels[0].stride);
+
+   EMIT_STATE_RELOC(DE_UPLANE_ADDRESS, );
+   EMIT_STATE(DE_UPLANE_STRIDE, etna_resource(res_u)->levels[0].stride);
+   EMIT_STATE_RELOC(DE_VPLANE_ADDRES

[Mesa-dev] [PATCH 8/9] etnaviv: use filter blit for 2D YUV import on old GC320

[Lucas Stach]

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 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 insertions(+), 17 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_2d.c 
b/src/gallium/drivers/etnaviv/etnaviv_2d.c
index 8b9e5399ce99..487222ce84ba 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_2d.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_2d.c
@@ -25,13 +25,16 @@
 #include "etnaviv_context.h"
 #include "etnaviv_emit.h"
 #include "etnaviv_screen.h"
+#include "etnaviv_rs.h"
 
 #include "pipe/p_state.h"
 #include "util/u_format.h"
 
 #include "hw/state_2d.xml.h"
+#include "hw/common.xml.h"
 
 #include 
+#include 
 
 #define EMIT_STATE(state_name, src_value) \
etna_coalsence_emit(stream, , VIVS_##state_name, src_value)
@@ -39,15 +42,85 @@
 #define EMIT_STATE_RELOC(state_name, src_value) \
etna_coalsence_emit_reloc(stream, , VIVS_##state_name, src_value)
 
+/* stolen from xf86-video-armada */
+#define KERNEL_ROWS 17
+#define KERNEL_INDICES  9
+#define KERNEL_SIZE (KERNEL_ROWS * KERNEL_INDICES)
+#define KERNEL_STATE_SZ ((KERNEL_SIZE + 1) / 2)
+
+static bool filter_kernel_initialized;
+static uint32_t filter_kernel[KERNEL_STATE_SZ];
+
+static inline float
+sinc (float x)
+{
+  return x != 0.0 ? sinf (x) / x : 1.0;
+}
+
+static void
+etnaviv_init_filter_kernel(void)
+{
+   unsigned row, idx, i;
+   int16_t kernel_val[KERNEL_STATE_SZ * 2];
+   float row_ofs = 0.5;
+   float radius = 4.0;
+
+   /* Compute lanczos filter kernel */
+   for (row = i = 0; row < KERNEL_ROWS; row++) {
+  float kernel[KERNEL_INDICES] = { 0.0 };
+  float sum = 0.0;
+
+  for (idx = 0; idx < KERNEL_INDICES; idx++) {
+ float x = idx - 4.0 + row_ofs;
+
+ if (fabs (x) <= radius)
+kernel[idx] = sinc (M_PI * x) * sinc (M_PI * x / radius);
+
+ sum += kernel[idx];
+   }
+
+   /* normalise the row */
+   if (sum)
+  for (idx = 0; idx < KERNEL_INDICES; idx++)
+ kernel[idx] /= sum;
+
+   /* convert to 1.14 format */
+   for (idx = 0; idx < KERNEL_INDICES; idx++) {
+  int val = kernel[idx] * (float) (1 << 14);
+
+  if (val < -0x8000)
+ val = -0x8000;
+  else if (val > 0x7fff)
+ val = 0x7fff;
+
+  kernel_val[i++] = val;
+   }
+
+   row_ofs -= 1.0 / ((KERNEL_ROWS - 1) * 2);
+   }
+
+   kernel_val[KERNEL_SIZE] = 0;
+
+   /* Now convert the kernel values into state values */
+   for (i = 0; i < KERNEL_STATE_SZ * 2; i += 2)
+  filter_kernel[i / 2] =
+ VIVS_DE_FILTER_KERNEL_COEFFICIENT0 (kernel_val[i]) |
+ VIVS_DE_FILTER_KERNEL_COEFFICIENT1 (kernel_val[i + 1]);
+}
+
 bool etna_try_2d_blit(struct pipe_context *pctx,
   const struct pipe_blit_info *blit_info)
 {
struct etna_context *ctx = etna_context(pctx);
+   struct etna_screen *screen = ctx->screen;
struct etna_cmd_stream *stream = ctx->stream2d;
struct etna_coalesce coalesce;
struct etna_reloc ry, ru, rv, rdst;
struct pipe_resource *res_y, *res_u, *res_v, *res_dst;
+   struct etna_bo *temp_bo = NULL;
uint32_t src_format;
+   bool ext_blt = VIV_2D_FEATURE(screen, chipMinorFeatures2, 2D_TILING);
+   uint32_t dst_config;
 
assert(util_format_is_yuv(blit_info->src.format));
assert(blit_info->dst.format == PIPE_FORMAT_R8G8B8A8_UNORM);
@@ -55,6 +128,11 @@ bool etna_try_2d_blit(struct pipe_context *pctx,
if (!stream)
   return FALSE;
 
+  if (unlikely(!ext_blt && !filter_kernel_initialized)) {
+  etnaviv_init_filter_kernel();
+  filter_kernel_initialized = true;
+  }
+
switch (blit_info->src.format) {
case PIPE_FORMAT_NV12:
   src_format = DE_FORMAT_NV12;
@@ -66,6 +144,15 @@ bool etna_try_2d_blit(struct pipe_context *pctx,
   return FALSE;
}
 
+   if (!ext_blt) {
+  struct etna_resource *dst = etna_resource(blit_info->dst.resource);
+  unsigned int bo_size = dst->levels[0].stride * 
dst->levels[0].padded_height;
+
+  temp_bo = etna_bo_new(screen->dev, bo_size, DRM_ETNA_GEM_CACHE_WC);
+  if (!temp_bo)
+ return FALSE;
+   }
+
res_y = blit_info->src.resource;
res_u = res_y->next ? res_y->next : res_y;
res_v = res_u->next ? res_u->next : res_u;
@@ -80,7 +167,7 @@ bool etna_try_2d_blit(struct pipe_context *pctx,
ry.flags = ru.flags = rv.flags

[Mesa-dev] [PATCH 2/9] etnaviv: reject imports of tiler incompatible linear buffers

[Lucas Stach]

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.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 c17a1704537e..41688dd340c2 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -524,6 +524,14 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
level->width = tmpl->width0;
level->height = tmpl->height0;
 
+   /* Reject imports of linear buffers if they have a blocksize incompatible
+* with the hardware tiler, as we don't have a fallback path to get them 
into
+* a render/sampler compatible layout.
+*/
+   if (rsc->layout == ETNA_LAYOUT_LINEAR && !screen->specs.use_blt &&
+   util_format_get_blocksize(prsc->format) == 1)
+  goto fail;
+
/* Determine padding of the imported resource. */
unsigned paddingX = 0, paddingY = 0;
etna_layout_multiple(rsc->layout, screen->specs.pixel_pipes,
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 7/9] etnaviv: export etna_submit_rs_state

[Lucas Stach]

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_rs.c 
b/src/gallium/drivers/etnaviv/etnaviv_rs.c
index fc4f65dbeee1..4c67a9e8a2ca 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
@@ -171,7 +171,7 @@ etna_modify_rs_clearbits(struct compiled_rs_state *cs, 
uint32_t clear_bits)
 
 /* submit RS state, without any processing and no dependence on context
  * except TS if this is a source-to-destination blit. */
-static void
+void
 etna_submit_rs_state(struct etna_context *ctx,
  const struct compiled_rs_state *cs)
 {
diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.h 
b/src/gallium/drivers/etnaviv/etnaviv_rs.h
index 125a13a9ad34..81ef05955a79 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_rs.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_rs.h
@@ -84,6 +84,10 @@ void
 etna_compile_rs_state(struct etna_context *ctx, struct compiled_rs_state *cs,
   const struct rs_state *rs);
 
+void
+etna_submit_rs_state(struct etna_context *ctx,
+ const struct compiled_rs_state *cs);
+
 /* Context initialization for RS clear_blit functions. */
 void
 etna_clear_blit_rs_init(struct pipe_context *pctx);
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/9] etnaviv: clear out next pointer when allocating resource

[Lucas Stach]

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/drivers/etnaviv/etnaviv_resource.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index 41688dd340c2..6d68a890c7b9 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -269,6 +269,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, unsigned 
layout,
   return NULL;
 
rsc->base = *templat;
+   rsc->base.next = NULL;
rsc->base.screen = pscreen;
rsc->base.nr_samples = nr_samples;
rsc->layout = layout;
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 9/9] etnaviv: handle YUV textures with the 2D GPU

[Lucas Stach]

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/etnaviv/etnaviv_format.c | 5 -
 src/gallium/drivers/etnaviv/etnaviv_resource.c   | 6 ++
 src/gallium/drivers/etnaviv/etnaviv_rs.c | 5 +
 src/gallium/drivers/etnaviv/etnaviv_screen.c | 5 -
 src/gallium/drivers/etnaviv/etnaviv_texture.c| 7 +++
 6 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
index 45c30cbf5076..5214162d8798 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
@@ -159,7 +159,7 @@ etna_copy_resource(struct pipe_context *pctx, struct 
pipe_resource *dst,
struct etna_resource *src_priv = etna_resource(src);
struct etna_resource *dst_priv = etna_resource(dst);
 
-   assert(src->format == dst->format);
+   assert(src->format == dst->format || util_format_is_yuv(src->format));
assert(src->array_size == dst->array_size);
assert(last_level <= dst->last_level && last_level <= src->last_level);
 
diff --git a/src/gallium/drivers/etnaviv/etnaviv_format.c 
b/src/gallium/drivers/etnaviv/etnaviv_format.c
index 29e81c4a8b04..0879ddd6a6c8 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_format.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_format.c
@@ -282,8 +282,11 @@ static struct etna_format formats[PIPE_FORMAT_COUNT] = {
_T(ASTC_12x12_SRGB, ASTC_SRGB8_ALPHA8_12x12 | ASTC_FORMAT,  SWIZ(X, 
Y, Z, W), NONE, NONE),
 
/* YUV */
-   _T(YUYV, YUY2, SWIZ(X, Y, Z, W), YUY2, NONE),
+   _T(YUYV, X8B8G8R8, SWIZ(X, Y, Z, W), NONE, NONE),
_T(UYVY, UYVY, SWIZ(X, Y, Z, W), NONE, NONE),
+
+   /* multi-planar YUV */
+   _T(NV12, X8B8G8R8, SWIZ(X, Y, Z, W), NONE, NONE),
 };
 
 uint32_t
diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index 0aef4bfaa2ff..8e5c4593fdcc 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -548,6 +548,12 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
   
level->padded_height);
level->size = level->layer_stride;
 
+   /* YUV resources are handled by the 2D GPU, so the below constraint checks
+* are invalid.
+*/
+   if (util_format_is_yuv(tmpl->format))
+  return prsc;
+
/* The DDX must give us a BO which conforms to our padding size.
 * The stride of the BO must be greater or equal to our padded
 * stride. The size of the BO must accomodate the padded height. */
diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
b/src/gallium/drivers/etnaviv/etnaviv_rs.c
index 4c67a9e8a2ca..389ee89fef70 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
@@ -26,6 +26,7 @@
 
 #include "etnaviv_rs.h"
 
+#include "etnaviv_2d.h"
 #include "etnaviv_clear_blit.h"
 #include "etnaviv_context.h"
 #include "etnaviv_emit.h"
@@ -774,6 +775,10 @@ etna_blit_rs(struct pipe_context *pctx, const struct 
pipe_blit_info *blit_info)
   return;
}
 
+   if (util_format_is_yuv(blit_info->src.format) &&
+   etna_try_2d_blit(pctx, blit_info))
+  return;
+
if (etna_try_rs_blit(pctx, blit_info))
   return;
 
diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index 2c975084f08f..e91c6e799ca6 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -526,6 +526,9 @@ gpu_supports_texure_format(struct etna_screen *screen, 
uint32_t fmt,
   supported = screen->specs.tex_astc;
}
 
+   if (util_format_is_yuv(format))
+  supported = !!screen->gpu2d;
+
if (!supported)
   return false;
 
@@ -644,7 +647,7 @@ etna_screen_query_dmabuf_modifiers(struct pipe_screen 
*pscreen,
   if (modifiers)
  modifiers[num_modifiers] = supported_modifiers[i];
   if (external_only)
- external_only[num_modifiers] = util_format_is_yuv(format) ? 1 : 0;
+ external_only[num_modifiers] = 0;
   num_modifiers++;
}
 
diff --git a/src/gallium/drivers/etnaviv/etnaviv_texture.c 
b/src/gallium/drivers/etnaviv/etnaviv_texture.c
index 72ef00bcb265..8228a8eb0a41 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_texture.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_texture.c
@@ -164,6 +164,9 @@ etna_update_sampler_source(struct pipe_sampler_view *view, 
int num)
 static bool
 etna_resource_sampler_compatible(struct etna_resource *res)
 {
+   if (util_format_

[Mesa-dev] [PATCH 5/9] etnaviv: create optional 2d pipe in screen

[Lucas Stach]

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/gallium/drivers/etnaviv/etnaviv_screen.c  | 68 +++
 src/gallium/drivers/etnaviv/etnaviv_screen.h  |  6 ++
 4 files changed, 81 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
b/src/gallium/drivers/etnaviv/etnaviv_context.c
index 3038d210e109..96cf2f3b59a8 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_context.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
@@ -72,6 +72,9 @@ etna_context_destroy(struct pipe_context *pctx)
if (ctx->stream)
   etna_cmd_stream_del(ctx->stream);
 
+   if (ctx->stream2d)
+  etna_cmd_stream_del(ctx->stream2d);
+
slab_destroy_child(>transfer_pool);
 
if (ctx->in_fence_fd != -1)
@@ -431,6 +434,9 @@ etna_context_create(struct pipe_screen *pscreen, void 
*priv, unsigned flags)
if (ctx->stream == NULL)
   goto fail;
 
+   if (screen->pipe2d)
+  ctx->stream2d = etna_cmd_stream_new(screen->pipe2d, 0x1000, NULL, NULL);
+
/* context ctxate setup */
ctx->specs = screen->specs;
ctx->screen = screen;
diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
b/src/gallium/drivers/etnaviv/etnaviv_context.h
index 584caa77080b..ef2752c61456 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_context.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
@@ -109,6 +109,7 @@ struct etna_context {
struct etna_specs specs;
struct etna_screen *screen;
struct etna_cmd_stream *stream;
+   struct etna_cmd_stream *stream2d;
 
/* which state objects need to be re-emit'd: */
enum {
diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index 04c7a873de65..2c975084f08f 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -90,6 +90,12 @@ etna_screen_destroy(struct pipe_screen *pscreen)
if (screen->gpu)
   etna_gpu_del(screen->gpu);
 
+   if (screen->pipe2d)
+  etna_pipe_del(screen->pipe2d);
+
+   if (screen->gpu2d)
+  etna_gpu_del(screen->gpu2d);
+
if (screen->ro)
   FREE(screen->ro);
 
@@ -877,6 +883,66 @@ etna_screen_bo_from_handle(struct pipe_screen *pscreen,
return bo;
 }
 
+static void etna_screen_init_2d(struct etna_screen *screen)
+{
+   struct etna_gpu *gpu2d = NULL;
+   uint64_t val;
+   int ret, i;
+
+   /* If the current GPU is a combined 2d/3D core, use it as 2D engine */
+   if (screen->features[0] & chipFeatures_PIPE_2D)
+  gpu2d = screen->gpu;
+
+   /* otherwise search for a 2D capable core */
+   if (!gpu2d) {
+  for (i = 0;; i++) {
+ gpu2d = etna_gpu_new(screen->dev, i);
+ if (!gpu2d)
+return;
+
+ ret = etna_gpu_get_param(gpu2d, ETNA_GPU_FEATURES_0, );
+ if (!ret && (val & chipFeatures_PIPE_2D)) {
+screen->gpu2d = gpu2d;
+break;
+ }
+
+ etna_gpu_del(gpu2d);
+  }
+   }
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_0, ))
+  return;
+   screen->features2d[0] = val;
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_1, ))
+  return;
+   screen->features2d[1] = val;
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_2, ))
+  return;
+   screen->features2d[2] = val;
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_3, ))
+  return;
+   screen->features2d[3] = val;
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_4, ))
+  return;
+   screen->features2d[4] = val;
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_5, ))
+  return;
+   screen->features2d[5] = val;
+
+   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_6, ))
+  return;
+   screen->features2d[6] = val;
+
+   screen->pipe2d = etna_pipe_new(gpu2d, ETNA_PIPE_2D);
+   if (!screen->pipe2d)
+  DBG("could not create 2d pipe");
+}
+
 struct pipe_screen *
 etna_screen_create(struct etna_device *dev, struct etna_gpu *gpu,
struct renderonly *ro)
@@ -970,6 +1036,8 @@ etna_screen_create(struct etna_device *dev, struct 
etna_gpu *gpu,
}
screen->features[6] = val;
 
+   etna_screen_init_2d(screen);
+
if (!etna_get_specs(screen))
   goto fail;
 
diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.h 
b/src/gallium/drivers/etnaviv/etnaviv_screen.h
index bffd4b6ef94a..f529d337ea1d 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.h
@@ -58,6 +58,9 @@ enum viv_features_word {
 #define VIV_FEATURE(screen, word, feature) \
((screen->features[viv_ ## wor

[Mesa-dev] [PATCH 1/9] etnaviv: improve PIPE_BIND_LINEAR handling

[Lucas Stach]

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 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..c17a1704537e 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -356,6 +356,14 @@ etna_resource_create(struct pipe_screen *pscreen,
if (templat->target == PIPE_TEXTURE_3D)
   layout = ETNA_LAYOUT_LINEAR;
 
+   /* The render pipe can't handle linear and there is no code to do yet 
another
+* layout transformation for this case, so we only respect the linear flag
+* if the resource isn't meant to be rendered.
+*/
+   if ((templat->bind & PIPE_BIND_LINEAR) &&
+   !(templat->bind & PIPE_BIND_RENDER_TARGET))
+  layout = ETNA_LAYOUT_LINEAR;
+
/* modifier is only used for scanout surfaces, so safe to use LINEAR here */
return etna_resource_alloc(pscreen, layout, DRM_FORMAT_MOD_LINEAR, templat);
 }
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/9] etnaviv: remember data offset into BO

[Lucas Stach]

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 changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index 6d68a890c7b9..0aef4bfaa2ff 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -520,7 +520,7 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
rsc->seqno = 1;
rsc->layout = modifier_to_layout(handle->modifier);
rsc->halign = TEXTURE_HALIGN_FOUR;
-
+   rsc->offset = handle->offset;
 
level->width = tmpl->width0;
level->height = tmpl->height0;
diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
b/src/gallium/drivers/etnaviv/etnaviv_resource.h
index 11ccf8f7bcbe..8dd12be06762 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
@@ -69,6 +69,7 @@ struct etna_resource {
/* Horizontal alignment for texture unit (TEXTURE_HALIGN_*) */
unsigned halign;
struct etna_bo *bo; /* Surface video memory */
+   uint32_t offset; /* data offset into the BO */
struct etna_bo *ts_bo; /* Tile status video memory */
 
struct etna_resource_level levels[ETNA_NUM_LOD];
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/9] Etnaviv direct YUV support

[Lucas Stach]

Driver support for YUV textures is mostly limited to OES_external, which
is suboptimal for etnaviv, as this incurs an additional copy blit on each
texture bind, due to the way the OES_external extension is defined and
the Vivante GPUs inability to sample from linear resources. Also emulating
planar YUV formats with R8 samplers isn't a good option on etnaviv, as the
most common GPUs are not able to tile 8bit formats in hardware and thus
would need a CPU fallback for this case.

There is a better option available, though: the Vivante 2D GPUs can blit
from interleaved or planar YUV buffers to a RGB buffer. New versions of
the 2D core can even do the required texture tiling at the same time. This
series implements the driver support for using the 2D GPU to do the texture
import. This allows us to generate regular GL_TEXTUREs from a set of YUV
dma-bufs by blitting into a internal RGBx buffer.

This series is on top of my st/dri changes, reworking the format
handling [1].

GStreamer glupload support has been developed based on this driver support
and is currently under review [2]. Kodi also seems happy about NV12 support
and I think there was some prototype code, based on a pre-release 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=152655423402505=2
[2] https://bugzilla.gnome.org/show_bug.cgi?id=783521

Lucas Stach (9):
  etnaviv: improve PIPE_BIND_LINEAR handling
  etnaviv: reject imports of tiler incompatible linear buffers
  etnaviv: clear out next pointer when allocating resource
  etnaviv: remember data offset into BO
  etnaviv: create optional 2d pipe in screen
  etnaviv: add 2D GPU YUV->RGB blitter
  etnaviv: export etna_submit_rs_state
  etnaviv: use filter blit for 2D YUV import on old GC320
  etnaviv: handle YUV textures with the 2D GPU

 src/gallium/drivers/etnaviv/Makefile.sources  |2 +
 src/gallium/drivers/etnaviv/etnaviv_2d.c  |  326 
 src/gallium/drivers/etnaviv/etnaviv_2d.h  |   37 +
 .../drivers/etnaviv/etnaviv_clear_blit.c  |2 +-
 src/gallium/drivers/etnaviv/etnaviv_context.c |6 +
 src/gallium/drivers/etnaviv/etnaviv_context.h |1 +
 src/gallium/drivers/etnaviv/etnaviv_format.c  |5 +-
 .../drivers/etnaviv/etnaviv_resource.c|   25 +-
 .../drivers/etnaviv/etnaviv_resource.h|1 +
 src/gallium/drivers/etnaviv/etnaviv_rs.c  |7 +-
 src/gallium/drivers/etnaviv/etnaviv_rs.h  |4 +
 src/gallium/drivers/etnaviv/etnaviv_screen.c  |   73 +-
 src/gallium/drivers/etnaviv/etnaviv_screen.h  |6 +
 src/gallium/drivers/etnaviv/etnaviv_texture.c |7 +
 src/gallium/drivers/etnaviv/hw/state_2d.xml.h | 1499 +
 15 files changed, 1996 insertions(+), 5 deletions(-)
 create mode 100644 src/gallium/drivers/etnaviv/etnaviv_2d.c
 create mode 100644 src/gallium/drivers/etnaviv/etnaviv_2d.h
 create mode 100644 src/gallium/drivers/etnaviv/hw/state_2d.xml.h

-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/dri: replace format conversion functions with single mapping table

[Lucas Stach]

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,
> > -                              int width, int height, int format,
> > +                              int width, int height, enum pipe_format pf,
> >                                int num_handles, struct winsys_handle 
> > *whandle,
> >                                void *loaderPrivate)
> >  {
> > @@ -992,13 +769,8 @@ dri2_create_image_from_winsys(__DRIscreen *_screen,
> >     __DRIimage *img;
> >     struct pipe_resource templ;
> >     unsigned tex_usage = 0;
> > -   enum pipe_format pf;
> >     int i;
> > 
> > -   pf = dri2_format_to_pipe_format (format);
> > -   if (pf == PIPE_FORMAT_NONE)
> > -      return NULL;
> > -
> >     if (pscreen->is_format_supported(pscreen, pf, screen->target, 0,
> >                                      PIPE_BIND_RENDER_TARGET))
> >        tex_usage |= PIPE_BIND_RENDER_TARGET;
> > @@ -1006,6 +778,20 @@ dri2_create_image_from_winsys(__DRIscreen *_screen,
> >                                      PIPE_BIND_SAMPLER_VIEW))
> >        tex_usage |= PIPE_BIND_SAMPLER_VIEW;
> > 
> > +   if (!tex_usage && util_format_is_yuv(pf)) {
> > +      /* YUV format sampling can be emulated by the Mesa state tracker by
> > +       * using multiple R8/RG88 samplers. So try to rewrite the pipe 
> > format.
> > +       */
> > +      pf = PIPE_FORMAT_R8_UNORM;
> > +
> > +      if (pscreen->is_format_supported(pscreen, pf, screen->target, 0,
> > +                                       PIPE_BIND_SAMPLER_VIEW))
> > +         tex_usage |= PIPE_BIND_SAMPLER_VIEW;
> > +   }
> 
> This doesn't seem to belong in this commit.

It does. The removed conversion functions would end up with
PIPE_FORMAT_R8_UNORM for I420 or NV12 input FOURCCs, with the implicit
assumption that all drivers need the emulation by the Mesa state-
tracker.

The new format table maps those to the proper PIPE_FORMAT_IYUV and
PIPE_FORMAT_NV12, so in order to not break drivers which can't handle
those formats natively and need the Mesa side emulation we need this
hunk of code.

> Other than that, the series is:
> 
> > Reviewed-by: Marek Olšák 

With the above explanation, can I keep your review for the whole patch?

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/2] st/dri format handling cleanups

[Lucas Stach]

Hi all,

those 2 patches clean up and align the format handling in the dri state
tracker to how the intel driver implements some details of the interface.

This is mostly in preparation for etnaviv to support native planar YUV
import without needing any of the R8/RG88 sampler rewrites, as those are
really costly due to some of the Vivante hardware constraints. This isn't
quite ready yet, but I wanted to get those patches out, as those have
some value on their own. Just looking at the diffstat should be motivation
enough to pull them in.

As this has the potential to break the NV12 import 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 conversion functions with single mapping table

 src/gallium/state_trackers/dri/dri2.c   | 493 ++--
 src/gallium/state_trackers/dri/dri_screen.h |   1 +
 2 files changed, 150 insertions(+), 344 deletions(-)

-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] st/dri: replace format conversion functions with single mapping table

[Lucas Stach]

Each time I have to touch the buffer import/export functions in the dri
state tracker I get lost in the maze of functions converting between
DRI_IMAGE_FOURCC, DRI_IMAGE_FORMAT, DRI_IMAGE_COMPONENTS and pipe format.

Rip it out and replace by a single table, which defines the correspondence
between 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 <l.st...@pengutronix.de>
---
 src/gallium/state_trackers/dri/dri2.c   | 476 ++--
 src/gallium/state_trackers/dri/dri_screen.h |   1 +
 2 files changed, 138 insertions(+), 339 deletions(-)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index 859161fb87ac..9c74ca54fc89 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -54,295 +54,72 @@
 #define DRM_FORMAT_MOD_INVALID ((1ULL<<56) - 1)
 #endif
 
-static const int fourcc_formats[] = {
-   __DRI_IMAGE_FOURCC_ARGB2101010,
-   __DRI_IMAGE_FOURCC_XRGB2101010,
-   __DRI_IMAGE_FOURCC_ABGR2101010,
-   __DRI_IMAGE_FOURCC_XBGR2101010,
-   __DRI_IMAGE_FOURCC_ARGB,
-   __DRI_IMAGE_FOURCC_ABGR,
-   __DRI_IMAGE_FOURCC_SARGB,
-   __DRI_IMAGE_FOURCC_XRGB,
-   __DRI_IMAGE_FOURCC_XBGR,
-   __DRI_IMAGE_FOURCC_ARGB1555,
-   __DRI_IMAGE_FOURCC_RGB565,
-   __DRI_IMAGE_FOURCC_R8,
-   __DRI_IMAGE_FOURCC_R16,
-   __DRI_IMAGE_FOURCC_GR88,
-   __DRI_IMAGE_FOURCC_GR1616,
-   __DRI_IMAGE_FOURCC_YUV410,
-   __DRI_IMAGE_FOURCC_YUV411,
-   __DRI_IMAGE_FOURCC_YUV420,
-   __DRI_IMAGE_FOURCC_YUV422,
-   __DRI_IMAGE_FOURCC_YUV444,
-   __DRI_IMAGE_FOURCC_YVU410,
-   __DRI_IMAGE_FOURCC_YVU411,
-   __DRI_IMAGE_FOURCC_YVU420,
-   __DRI_IMAGE_FOURCC_YVU422,
-   __DRI_IMAGE_FOURCC_YVU444,
-   __DRI_IMAGE_FOURCC_NV12,
-   __DRI_IMAGE_FOURCC_NV16,
-   __DRI_IMAGE_FOURCC_YUYV
-};
-
-static int convert_fourcc(int format, int *dri_components_p)
-{
+struct dri2_format_mapping {
+   int dri_fourcc;
+   int dri_format;
int dri_components;
-   switch(format) {
-   case __DRI_IMAGE_FOURCC_RGB565:
-  format = __DRI_IMAGE_FORMAT_RGB565;
-  dri_components = __DRI_IMAGE_COMPONENTS_RGB;
-  break;
-   case __DRI_IMAGE_FOURCC_ARGB:
-  format = __DRI_IMAGE_FORMAT_ARGB;
-  dri_components = __DRI_IMAGE_COMPONENTS_RGBA;
-  break;
-   case __DRI_IMAGE_FOURCC_XRGB:
-  format = __DRI_IMAGE_FORMAT_XRGB;
-  dri_components = __DRI_IMAGE_COMPONENTS_RGB;
-  break;
-   case __DRI_IMAGE_FOURCC_ABGR:
-  format = __DRI_IMAGE_FORMAT_ABGR;
-  dri_components = __DRI_IMAGE_COMPONENTS_RGBA;
-  break;
-   case __DRI_IMAGE_FOURCC_XBGR:
-  format = __DRI_IMAGE_FORMAT_XBGR;
-  dri_components = __DRI_IMAGE_COMPONENTS_RGB;
-  break;
-   case __DRI_IMAGE_FOURCC_ARGB2101010:
-  format = __DRI_IMAGE_FORMAT_ARGB2101010;
-  dri_components = __DRI_IMAGE_COMPONENTS_RGBA;
-  break;
-   case __DRI_IMAGE_FOURCC_XRGB2101010:
-  format = __DRI_IMAGE_FORMAT_XRGB2101010;
-  dri_components = __DRI_IMAGE_COMPONENTS_RGB;
-  break;
-   case __DRI_IMAGE_FOURCC_ABGR2101010:
-  format = __DRI_IMAGE_FORMAT_ABGR2101010;
-  dri_components = __DRI_IMAGE_COMPONENTS_RGBA;
-  break;
-   case __DRI_IMAGE_FOURCC_XBGR2101010:
-  format = __DRI_IMAGE_FORMAT_XBGR2101010;
-  dri_components = __DRI_IMAGE_COMPONENTS_RGB;
-  break;
-   case __DRI_IMAGE_FOURCC_R8:
-  format = __DRI_IMAGE_FORMAT_R8;
-  dri_components = __DRI_IMAGE_COMPONENTS_R;
-  break;
-   case __DRI_IMAGE_FOURCC_GR88:
-  format = __DRI_IMAGE_FORMAT_GR88;
-  dri_components = __DRI_IMAGE_COMPONENTS_RG;
-  break;
-   case __DRI_IMAGE_FOURCC_R16:
-  format = __DRI_IMAGE_FORMAT_R16;
-  dri_components = __DRI_IMAGE_COMPONENTS_R;
-  break;
-   case __DRI_IMAGE_FOURCC_GR1616:
-  format = __DRI_IMAGE_FORMAT_GR1616;
-  dri_components = __DRI_IMAGE_COMPONENTS_RG;
-  break;
-   case __DRI_IMAGE_FOURCC_YUYV:
-  format = __DRI_IMAGE_FORMAT_YUYV;
-  dri_components = __DRI_IMAGE_COMPONENTS_Y_XUXV;
-  break;
-   /*
-* For multi-planar YUV formats, we return the format of the first
-* plane only.  Since there is only one caller which supports multi-
-* planar YUV it gets to figure out the remaining planes on it's
-* own.
-*/
-   case __DRI_IMAGE_FOURCC_YUV420:
-   case __DRI_IMAGE_FOURCC_YVU420:
-  format = __DRI_IMAGE_FORMAT_R8;
-  dri_components = __DRI_IMAGE_COMPONENTS_Y_U_V;
-  break;
-   case __DRI_IMAGE_FOURCC_NV12:
-  format = __DRI_IMAGE_FORMAT_R8;
-  dri_components = __DRI_IMAGE_COMPONENTS_Y_UV;
-  break;
-   default:
-  return -1;
-   }
-   *dri_components_p = dri_components;
-   return format;
-}
-
-/* NOTE this probably isn't going to do the right thing for YUV image

[Mesa-dev] [PATCH 1/2] st/dri: allow both render and sampler compatible dma-buf formats

[Lucas Stach]

Currently all the EGL APIs are missing a way to specify how an imported
dma-buf is intended to be used. Demanding the format to be both usable
for sampling and rendering artificially restricts the list of formats a
driver is able to import.

Looking at how the Intel driver implements those DRI2 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 <l.st...@pengutronix.de>
---
 src/gallium/state_trackers/dri/dri2.c | 29 +--
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index 58a6757f037a..859161fb87ac 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -991,16 +991,21 @@ dri2_create_image_from_winsys(__DRIscreen *_screen,
struct pipe_screen *pscreen = screen->base.screen;
__DRIimage *img;
struct pipe_resource templ;
-   unsigned tex_usage;
+   unsigned tex_usage = 0;
enum pipe_format pf;
int i;
 
-   tex_usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
-
pf = dri2_format_to_pipe_format (format);
if (pf == PIPE_FORMAT_NONE)
   return NULL;
 
+   if (pscreen->is_format_supported(pscreen, pf, screen->target, 0,
+PIPE_BIND_RENDER_TARGET))
+  tex_usage |= PIPE_BIND_RENDER_TARGET;
+   if (pscreen->is_format_supported(pscreen, pf, screen->target, 0,
+PIPE_BIND_SAMPLER_VIEW))
+  tex_usage |= PIPE_BIND_SAMPLER_VIEW;
+
img = CALLOC_STRUCT(__DRIimageRec);
if (!img)
   return NULL;
@@ -1477,16 +1482,16 @@ dri2_query_dma_buf_formats(__DRIscreen *_screen, int 
max, int *formats,
 {
struct dri_screen *screen = dri_screen(_screen);
struct pipe_screen *pscreen = screen->base.screen;
-   const unsigned bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
int i, j;
 
for (i = 0, j = 0; (i < ARRAY_SIZE(fourcc_formats)) &&
  (j < max || max == 0); i++) {
-  if (pscreen->is_format_supported(pscreen,
-   fourcc_to_pipe_format(
-  fourcc_formats[i]),
-   screen->target,
-   0, bind)) {
+  enum pipe_format format = fourcc_to_pipe_format(fourcc_formats[i]);
+
+  if (pscreen->is_format_supported(pscreen, format, screen->target, 0,
+   PIPE_BIND_RENDER_TARGET) ||
+  pscreen->is_format_supported(pscreen, format, screen->target, 0,
+   PIPE_BIND_SAMPLER_VIEW)) {
  if (j < max)
 formats[j] = fourcc_formats[i];
  j++;
@@ -1504,10 +1509,12 @@ dri2_query_dma_buf_modifiers(__DRIscreen *_screen, int 
fourcc, int max,
struct dri_screen *screen = dri_screen(_screen);
struct pipe_screen *pscreen = screen->base.screen;
enum pipe_format format = fourcc_to_pipe_format(fourcc);
-   const unsigned usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
 
if (pscreen->query_dmabuf_modifiers != NULL &&
-   pscreen->is_format_supported(pscreen, format, screen->target, 0, 
usage)) {
+   (pscreen->is_format_supported(pscreen, format, screen->target, 0,
+ PIPE_BIND_RENDER_TARGET) ||
+pscreen->is_format_supported(pscreen, format, screen->target, 0,
+ PIPE_BIND_SAMPLER_VIEW))) {
   pscreen->query_dmabuf_modifiers(pscreen, format, max, modifiers,
   external_only, count);
   return true;
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] st/mesa: only define GLSL 1.4 for compat if driver supports it

[Lucas Stach]

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 4560aad780b ("mesa: add GLSLVersionCompat constant")
> Signed-off-by: Christian Gmeiner <christian.gmei...@gmail.com>

Reviewed-by: Lucas Stach <l.st...@pengutronix.de>

> ---
>  src/mesa/state_tracker/st_extensions.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index 19ef736e5b..2d56a88027 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -936,7 +936,7 @@ void st_init_extensions(struct pipe_screen *screen,
>  
> /* Figure out GLSL support and set GLSLVersion to it. */
> consts->GLSLVersion = screen->get_param(screen, 
> PIPE_CAP_GLSL_FEATURE_LEVEL);
> -   consts->GLSLVersionCompat = 140;
> +   consts->GLSLVersionCompat = _min(consts->GLSLVersion, 140);
>  
> _mesa_override_glsl_version(consts);
>  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: only define GLSL 1.4 for compat if driver supports it

[Lucas Stach]

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/mesa/state_tracker/st_extensions.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index 19ef736e5b..945ca3a16c 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -936,7 +936,11 @@ void st_init_extensions(struct pipe_screen *screen,
>  
> /* Figure out GLSL support and set GLSLVersion to it. */
> consts->GLSLVersion = screen->get_param(screen, 
> PIPE_CAP_GLSL_FEATURE_LEVEL);
> -   consts->GLSLVersionCompat = 140;
> +
> +   if (consts->GLSLVersion >= 140)
> +  consts->GLSLVersionCompat = 140;
> +   else
> +  consts->GLSLVersionCompat = 120;

A driver might want to expose the intermediate version 130 at some
point. So the compat version should really be min(GLSLVersion, 140) to
cover this, right?

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 05/14] etnaviv: take care of the number of layers

[Lucas Stach]

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 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index 3febd8daef..fbcdb4f57d 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -254,9 +254,10 @@ etna_rs_gen_clear_surface(struct etna_context
> *ctx, struct etna_surface *surf,
>    uint32_t clear_value)
>  {
> struct etna_resource *dst = etna_resource(surf->base.texture);
> +   const int layer = translate_rs_layer(surf->base.format);
> uint32_t format;
>  
> -   switch (util_format_get_blocksize(surf->base.format)) {
> +   switch (util_format_get_blocksize(surf->base.format) / layer) {
> case 2:
>    format = RS_FORMAT_A4R4G4B4;
>    break;

Doesn't this mean that we need to double the number of tiles or the
stride of the surface somewhere? Wouldn't we end up with only one half
of the surface being cleared otherwise?

Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 03/14] etnaviv: rs: add support for multi layer formats

[Lucas Stach]

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
this is highly confusing, especially since layer is already used in the
context of textures with texture arrays.

My vote would be to come up with another description for this thing.

Regards,
Lucas

> This defines what base format we can use for RS.
> 
> > Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_format.c | 56 
>  src/gallium/drivers/etnaviv/etnaviv_format.h |  3 ++
>  2 files changed, 37 insertions(+), 22 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_format.c 
> b/src/gallium/drivers/etnaviv/etnaviv_format.c
> index df4cff16d4..20beff84e8 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_format.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_format.c
> @@ -52,6 +52,10 @@ struct etna_format {
>  #define RS_FORMAT(x)  ((x) & RS_FORMAT_MASK)
>  #define RS_FORMAT_RB_SWAP 0x10
>  
> +#define RS_LAYER_MASK 0x700
> +#define RS_LAYER_SHIFT8
> +#define RS_LAYER(x)   (((x) << RS_LAYER_SHIFT) & RS_LAYER_MASK)
> +
>  #define RS_FORMAT_X8B8G8R8(RS_FORMAT_X8R8G8B8 | RS_FORMAT_RB_SWAP)
>  #define RS_FORMAT_A8B8G8R8(RS_FORMAT_A8R8G8B8 | RS_FORMAT_RB_SWAP)
>  
> @@ -120,15 +124,15 @@ static struct etna_format formats[PIPE_FORMAT_COUNT] = {
> V_(R16_SSCALED, SHORT,  NONE, NONE),
> V_(R16_FLOAT,   HALF_FLOAT, NONE, NONE),
>  
> -   _T(B4G4R4A4_UNORM, A4R4G4B4, SWIZ(X, Y, Z, W), A4R4G4B4, A4R4G4B4, 
> A4R4G4B4),
> -   _T(B4G4R4X4_UNORM, X4R4G4B4, SWIZ(X, Y, Z, W), X4R4G4B4, A4R4G4B4, 
> X4R4G4B4),
> +   _T(B4G4R4A4_UNORM, A4R4G4B4, SWIZ(X, Y, Z, W), A4R4G4B4 | RS_LAYER(1), 
> A4R4G4B4, A4R4G4B4),
> +   _T(B4G4R4X4_UNORM, X4R4G4B4, SWIZ(X, Y, Z, W), X4R4G4B4 | RS_LAYER(1), 
> A4R4G4B4, X4R4G4B4),
>  
> -   _T(L8A8_UNORM, A8L8, SWIZ(X, Y, Z, W), A4R4G4B4, NONE, NONE),
> +   _T(L8A8_UNORM, A8L8, SWIZ(X, Y, Z, W), A4R4G4B4 | RS_LAYER(1), NONE, 
> NONE),
>  
> -   _T(Z16_UNORM,  D16,  SWIZ(X, Y, Z, W), A4R4G4B4, D16, A4R4G4B4),
> -   _T(B5G6R5_UNORM,   R5G6B5,   SWIZ(X, Y, Z, W), R5G6B5,   R5G6B5,   
> R5G6B5),
> -   _T(B5G5R5A1_UNORM, A1R5G5B5, SWIZ(X, Y, Z, W), A1R5G5B5, A1R5G5B5, 
> A1R5G5B5),
> -   _T(B5G5R5X1_UNORM, X1R5G5B5, SWIZ(X, Y, Z, W), X1R5G5B5, A1R5G5B5, 
> X1R5G5B5),
> +   _T(Z16_UNORM,  D16,  SWIZ(X, Y, Z, W), A4R4G4B4 | RS_LAYER(1), 
> D16, A4R4G4B4),
> +   _T(B5G6R5_UNORM,   R5G6B5,   SWIZ(X, Y, Z, W), R5G6B5   | RS_LAYER(1), 
> R5G6B5,   R5G6B5),
> +   _T(B5G5R5A1_UNORM, A1R5G5B5, SWIZ(X, Y, Z, W), A1R5G5B5 | RS_LAYER(1), 
> A1R5G5B5, A1R5G5B5),
> +   _T(B5G5R5X1_UNORM, X1R5G5B5, SWIZ(X, Y, Z, W), X1R5G5B5 | RS_LAYER(1), 
> A1R5G5B5, X1R5G5B5),
>  
> VT(R8G8_UNORM,   UNSIGNED_BYTE,  EXT_G8R8 | EXT_FORMAT, SWIZ(X, Y, 0, 1), 
> NONE, NONE, NONE),
> V_(R8G8_SNORM,   BYTE,   NONE, NONE),
> @@ -165,26 +169,26 @@ static struct etna_format formats[PIPE_FORMAT_COUNT] = {
>  
> V_(A8B8G8R8_UNORM,   UNSIGNED_BYTE, NONE, NONE),
>  
> -   VT(R8G8B8A8_UNORM,   UNSIGNED_BYTE, A8B8G8R8, SWIZ(X, Y, Z, W), A8B8G8R8, 
> A8R8G8B8, NONE),
> -   V_(R8G8B8A8_SNORM,   BYTE,  A8B8G8R8, NONE),
> -   _T(R8G8B8X8_UNORM,   X8B8G8R8,  SWIZ(X, Y, Z, W), X8B8G8R8, X8R8G8B8, 
> NONE),
> -   V_(R8G8B8A8_UINT,UNSIGNED_BYTE, A8B8G8R8, NONE),
> -   V_(R8G8B8A8_SINT,BYTE,  A8B8G8R8, NONE),
> -   V_(R8G8B8A8_USCALED, UNSIGNED_BYTE, A8B8G8R8, NONE),
> -   V_(R8G8B8A8_SSCALED, BYTE,  A8B8G8R8, NONE),
> +   VT(R8G8B8A8_UNORM,   UNSIGNED_BYTE, A8B8G8R8, SWIZ(X, Y, Z, W), A8B8G8R8 
> | RS_LAYER(1), A8R8G8B8, NONE),
> +   V_(R8G8B8A8_SNORM,   BYTE,  A8B8G8R8 | RS_LAYER(1), NONE),
> +   _T(R8G8B8X8_UNORM,   X8B8G8R8,  SWIZ(X, Y, Z, W), X8B8G8R8 | 
> RS_LAYER(1), X8R8G8B8, NONE),
> +   V_(R8G8B8A8_UINT,UNSIGNED_BYTE, A8B8G8R8 | RS_LAYER(1), NONE),
> +   V_(R8G8B8A8_SINT,BYTE,  A8B8G8R8 | RS_LAYER(1), NONE),
> +   V_(R8G8B8A8_USCALED, UNSIGNED_BYTE, A8B8G8R8 | RS_LAYER(1), NONE),
> +   V_(R8G8B8A8_SSCALED, BYTE,  A8B8G8R8 | RS_LAYER(1), NONE),
>  
> -   _T(B8G8R8A8_UNORM, A8R8G8B8, SWIZ(X, Y, Z, W), A8R8G8B8, A8R8G8B8, 
> A8R8G8B8),
> -   _T(B8G8R8X8_UNORM, X8R8G8B8, SWIZ(X, Y, Z, W), X8R8G8B8, X8R8G8B8, 
> X8R8G8B8),
> -   _T(B8G8R8A8_SRGB,  A8R8G8B8, SWIZ(X, Y, Z, W), A8R8G8B8, A8R8G8B8, 
> A8R8G8B8),
> -   _T(B8G8R8X8_SRGB,  X8R8G8B8, SWIZ(X, Y, Z, W), X8R8G8B8, X8R8G8B8, 
> X8R8G8B8),
> +   _T(B8G8R8A8_UNORM, A8R8G8B8, SWIZ(X, Y, Z, W), A8R8G8B8 | RS_LAYER(1), 
> A8R8G8B8, A8R8G8B8),
> +   _T(B8G8R8X8_UNORM, X8R8G8B8, SWIZ(X, Y, Z, W), X8R8G8B8 | RS_LAYER(1), 
> X8R8G8B8, X8R8G8B8),
> +   _T(B8G8R8A8_SRGB,  A8R8G8B8, SWIZ(X, Y, Z, W), A8R8G8B8 | RS_LAYER(1), 
> A8R8G8B8, A8R8G8B8),
> +  

Re: [Mesa-dev] [PATCH 08/12] etnaviv: support TX performance counters

[Lucas Stach]

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(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_query_pm.c 
> b/src/gallium/drivers/etnaviv/etnaviv_query_pm.c
> index 3601d4086c..4c2a2ac7de 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_query_pm.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_query_pm.c
> @@ -276,6 +276,69 @@ static const struct etna_perfmon_config query_config[] = 
> {
>    .source = (const struct etna_perfmon_source[]) {
>   { "RA", "CULLED_QUAD_COUNT" }
>    }
> +   },
> +   {
> +  .name = "tx-total-bilinear-requests",
> +  .type = ETNA_QUERY_TX_TOTAL_BILINEAR_REQUESTS,
> +  .source = (const struct etna_perfmon_source[]) {
> + { "TX", "TOTAL_BILINEAR_REQUESTS" }
> +  }
> +   },
> +   {
> +  .name = "tx-total-trilinear-requests",
> +  .type = ETNA_QUERY_TX_TOTAL_TRILINEAR_REQUESTS,
> +  .source = (const struct etna_perfmon_source[]) {
> + { "TX", "TOTAL_TRILINEAR_REQUESTS" }
> +  }
> +   },
> +   {
> +  .name = "tx-total-discarded-texutre-requests",

^ wrong spelling of texture.

> +  .type = ETNA_QUERY_TX_TOTAL_DISCARDED_TEXTURE_REQUESTS,
> +  .source = (const struct etna_perfmon_source[]) {
> + { "TX", "TOTAL_DISCARDED_TEXTURE_REQUESTS" }
> +  }
> +   },
> +   {
> +  .name = "tx-total-texutre-requests",

again

> +  .type = ETNA_QUERY_TX_TOTAL_TEXTURE_REQUESTS,
> +  .source = (const struct etna_perfmon_source[]) {
> + { "TX", "TOTAL_TEXTURE_REQUESTS" }
> +  }
> +   },
> +   {
> +  .name = "tx-mem-read-count",
> +  .type = ETNA_QUERY_TX_MEM_READ_COUNT,
> +  .source = (const struct etna_perfmon_source[]) {
> + { "TX", "MEM_READ_COUNT" }
> +  }
> +   },
> +   {
> +  .name = "tx-mem-read-in-8b-count",
> +  .type = ETNA_QUERY_TX_MEM_READ_IN_8B_COUNT,
> +  .source = (const struct etna_perfmon_source[]) {
> + { "TX", "MEM_READ_IN_8B_COUNT" }
> +  }
> +   },
> +   {
> +  .name = "tx-cache-miss-count",
> +  .type = ETNA_QUERY_TX_CACHE_MISS_COUNT,
> +  .source = (const struct etna_perfmon_source[]) {
> + { "TX", "CACHE_MISS_COUNT" }
> +  }
> +   },
> +   {
> +  .name = "tx-cache-hit-texel-count",
> +  .type = ETNA_QUERY_TX_CACHE_HIT_TEXEL_COUNT,
> +  .source = (const struct etna_perfmon_source[]) {
> + { "TX", "CACHE_HIT_TEXEL_COUNT" }
> +  }
> +   },
> +   {
> +  .name = "tx-cache-miss-texel-count",
> +  .type = ETNA_QUERY_TX_CACHE_MISS_TEXEL_COUNT,
> +  .source = (const struct etna_perfmon_source[]) {
> + { "TX", "CACHE_MISS_TEXEL_COUNT" }
> +  }
> }
>  };
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_query_pm.h 
> b/src/gallium/drivers/etnaviv/etnaviv_query_pm.h
> index 01dd135392..9cfd06e0ec 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_query_pm.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_query_pm.h
> @@ -73,6 +73,16 @@ struct etna_screen;
>  #define ETNA_QUERY_RA_PREFETCH_CACHE_MISS_COUNTER(ETNA_PM_QUERY_BASE 
> + 32)
>  #define ETNA_QUERY_RA_CULLED_QUAD_COUNT  (ETNA_PM_QUERY_BASE 
> + 33)
>  
> +#define ETNA_QUERY_TX_TOTAL_BILINEAR_REQUESTS(ETNA_PM_QUERY_BASE 
> + 34)
> +#define ETNA_QUERY_TX_TOTAL_TRILINEAR_REQUESTS   (ETNA_PM_QUERY_BASE 
> + 35)
> +#define ETNA_QUERY_TX_TOTAL_DISCARDED_TEXTURE_REQUESTS   (ETNA_PM_QUERY_BASE 
> + 36)
> +#define ETNA_QUERY_TX_TOTAL_TEXTURE_REQUESTS (ETNA_PM_QUERY_BASE 
> + 37)
> +#define ETNA_QUERY_TX_MEM_READ_COUNT (ETNA_PM_QUERY_BASE 
> + 38)
> +#define ETNA_QUERY_TX_MEM_READ_IN_8B_COUNT   (ETNA_PM_QUERY_BASE 
> + 39)
> +#define ETNA_QUERY_TX_CACHE_MISS_COUNT   (ETNA_PM_QUERY_BASE 
> + 40)
> +#define ETNA_QUERY_TX_CACHE_HIT_TEXEL_COUNT  (ETNA_PM_QUERY_BASE 
> + 41)
> +#define ETNA_QUERY_TX_CACHE_MISS_TEXEL_COUNT (ETNA_PM_QUERY_BASE 
> + 42)
> +
>  struct etna_pm_query {
> struct etna_query base;
> struct etna_perfmon_signal *signal;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] etnaviv: advertise YUV formats as external only

[Lucas Stach]

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 <l.st...@pengutronix.de>
---
 src/gallium/drivers/etnaviv/etnaviv_screen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index e38e48c89436..3c2addb4aa5a 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -632,7 +632,7 @@ etna_screen_query_dmabuf_modifiers(struct pipe_screen 
*pscreen,
   if (modifiers)
  modifiers[num_modifiers] = supported_modifiers[i];
   if (external_only)
- external_only[num_modifiers] = 0;
+ external_only[num_modifiers] = util_format_is_yuv(format) ? 1 : 0;
   num_modifiers++;
}
 
-- 
2.16.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] gallium/util: implement util_format_is_yuv

[Lucas Stach]

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 <l.st...@pengutronix.de>
---
 src/gallium/auxiliary/util/u_format.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_format.h 
b/src/gallium/auxiliary/util/u_format.h
index 88bfd72d0538..e497b4b3375a 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -557,6 +557,18 @@ util_format_is_depth_and_stencil(enum pipe_format format)
   util_format_has_stencil(desc);
 }
 
+static inline boolean
+util_format_is_yuv(enum pipe_format format)
+{
+   const struct util_format_description *desc = 
util_format_description(format);
+
+   assert(desc);
+   if (!desc) {
+  return FALSE;
+   }
+
+   return desc->colorspace == UTIL_FORMAT_COLORSPACE_YUV;
+}
 
 /**
  * Calculates the depth format type based upon the incoming format description.
-- 
2.16.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev