Re: Plumbing explicit synchronization through the Linux ecosystem

On Thu., Mar. 19, 2020, 06:51 Daniel Vetter, wrote: > On Tue, Mar 17, 2020 at 11:01:57AM +0100, Michel Dänzer wrote: > > On 2020-03-16 7:33 p.m., Marek Olšák wrote: > > > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer > wrote: > > >> On 2020-0

Re: Plumbing explicit synchronization through the Linux ecosystem

On Tue., Mar. 17, 2020, 06:02 Michel Dänzer, wrote: > On 2020-03-16 7:33 p.m., Marek Olšák wrote: > > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer > wrote: > >> On 2020-03-16 4:50 a.m., Marek Olšák wrote: > >>> The synchronization works because the Mes

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

On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer wrote: > On 2020-03-16 4:50 a.m., Marek Olšák wrote: > > The synchronization works because the Mesa driver waits for idle (drains > > the GFX pipeline) at the end of command buffers and there is only 1 > > graphics queue, so

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

o have it corrected. People continue > claiming that AMD is somehow special but I have yet to grasp what makes it > so. (Not that anyone has bothered to try all that hard to explain it.) > > > --Jason > > On March 13, 2020 21:03:21 Marek Olšák wrote: > >> There is

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

There is no synchronization between processes (e.g. 3D app and compositor) within X on AMD hw. It works because of some hacks in Mesa. Marek On Wed, Mar 11, 2020 at 1:31 PM Jason Ekstrand wrote: > All, > > Sorry for casting such a broad net with this one. I'm sure most people > who reply will

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

For Mesa, we could run CI only when Marge pushes, so that it's a strictly pre-merge CI. Marek On Sat., Feb. 29, 2020, 17:20 Nicolas Dufresne, wrote: > Le samedi 29 février 2020 à 15:54 -0600, Jason Ekstrand a écrit : > > On Sat, Feb 29, 2020 at 3:47 PM Timur Kristóf > wrote: > > > On Sat,

Re: [Mesa-dev] [PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

On Wed, Jul 26, 2017 at 8:29 AM, Michel Dänzer wrote: > On 25/07/17 05:28 PM, Nicolai Hähnle wrote: >> On 22.07.2017 14:00, Daniel Stone wrote: >>> >>> I don't have any great solution off the top of my head, but I'd be >>> inclined to bundle stride in with placement. TTBOMK

Re: [PATCH xserver 1/2] Revert "glamor: Remove the FBO cache."

On Fri, Mar 3, 2017 at 9:46 AM, Michel Dänzer wrote: > From: Michel Dänzer > > This reverts commit 950ffb8d6fd1480f305e38c571bda44f247f1de2 (and parts > of commit 4b5326aeba539249fcded91bf7806a708eeca651). > > It halved (or worse) the performance with

Re: [PATCH 1/2] glamor: Add GLAMOR_ACCESS_WO

On Wed, Aug 24, 2016 at 5:27 AM, Michel Dänzer wrote: > > Adding Marek and Nicolai, maybe they have some feedback from a GL > (driver) perspective. > > > On 23/08/16 10:41 AM, Dave Airlie wrote: >> From: Michel Dänzer >> >> [airlied: rebased onto

Re: [PATCH xserver 1/2] glamor: Call eglBindAPI after eglInitialize

Not anymore. I reverted the Mesa commit. We need to keep old Glamor in a working state. Marek On Fri, Jun 3, 2016 at 3:25 AM, Michel Dänzer wrote: > From: Michel Dänzer > > Current Mesa Git master checks that the EGL display actually supports > the

Re: glamor core profile support

On Tue, Jan 19, 2016 at 1:56 AM, Dave Airlie wrote: > This series implements support for glamor in ephyr/EGL/Xwayland > to use GL core profile when it can. > > This required 4 main changes: > a) stop using client ptrs everywhere, I found 3 places left, > gradient, picture and

Re: [PATCH 0/4] fb support for 8bpp bitmaps

Even though GL has no support for 1bpp textures, they can be supported indirectly. You can do the 1bpp - 8bpp conversion on the GPU using a simple fragment shader. All you need is GL 3.0. Same for A8. You can do the swizzling in the fragment shader for GLES, but I'm not sure why we care about it.