Re: [Mesa-dev] XDC 2020 feedback and comments

First off, I think you all did a fantastic job. I felt that things ran very smoothly and, as far as the talks themselves go, I think it went almost as smoothly as an in-person XDC. I'm really quite impressed. I do have a couple pieces of more nuanced feedback: 1. I think we were maybe a bit

Re: Plumbing explicit synchronization through the Linux ecosystem

On Mon, Mar 16, 2020 at 4:15 PM Laurent Pinchart wrote: > > 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 wrot

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

On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay wrote: > > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote: > > > > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay: > > > I think I found a userspace-accessible way to create sync_files and > > > dma_fences that would fulfill the

Re: Plumbing explicit synchronization through the Linux ecosystem

On Tue, Mar 17, 2020 at 10:33 AM Nicolas Dufresne wrote: > > 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 Pinch

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

On Tue, Mar 17, 2020 at 12:13 PM Jacob Lifshay wrote: > > 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

Re: Plumbing explicit synchronization through the Linux ecosystem

On Tue, Mar 17, 2020 at 3:01 AM Simon Ser wrote: > > On Monday, March 16, 2020 5:04 PM, Jason Ekstrand > wrote: > > > Hopefully, that will provide some motivation for other compositors > > (kwin, gnome-shell, etc.) because they now have a real user of it in > >

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

On Wed, Mar 18, 2020 at 12:20 AM Jacob Lifshay wrote: > > On Tue, Mar 17, 2020 at 7:08 PM Jason Ekstrand wrote: > > > > On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay > > wrote: > > > > > > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote: > >

Re: Plumbing explicit synchronization through the Linux ecosystem

On Mon, Mar 16, 2020 at 6:39 PM Roman Gilg wrote: > > On Wed, Mar 11, 2020 at 8:21 PM Jason Ekstrand wrote: > > > > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand > > wrote: > > > > > > All, > > > > > > Sorry for casting such a b

Re: Plumbing explicit synchronization through the Linux ecosystem

On Mon, Mar 16, 2020 at 10:33 AM Tomek Bury wrote: > > > GL and GLES are not relevant. What is relevant is EGL, which defines > > interfaces to make things work on the native platform. > Yes and no. This is what EGL spec says about sharing a texture between > contexts: > > "OpenGL and OpenGL ES

Re: Plumbing explicit synchronization through the Linux ecosystem

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 : > >

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

it.) --Jason On March 13, 2020 21:03:21 Marek Olšák wrote: 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

Re: Plumbing explicit synchronization through the Linux ecosystem

properly everywhere quickly, a solution which lets us improve our driver kernel APIs independently of misc. Wayland compositors seems advantageous. On Wed, Mar 11, 2020 at 6:02 PM Adam Jackson wrote: > > On Wed, 2020-03-11 at 12:31 -0500, Jason Ekstrand wrote: > > > - X11: With pre

Plumbing explicit synchronization through the Linux ecosystem

mesa/mesa/-/merge_requests/4037 At this point, I welcome your thoughts, comments, objections, and maybe even help/review. :-) --Jason Ekstrand ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://li

Re: Plumbing explicit synchronization through the Linux ecosystem

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

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

I don't think we need to worry so much about the cost of CI that we need to micro-optimize to to get the minimal number of CI runs. We especially shouldn't if it begins to impact coffee quality, people's ability to merge patches in a timely manner, or visibility into what went wrong when CI

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

> Le dimanche 01 mars 2020 à 14:18 -0600, Jason Ekstrand a écrit : > > I've seen a number of suggestions which will do one or both of those things > > including: > > > > - Batching merge requests > > Agreed. Or at least I foresee quite complicated code to handl

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

On Fri, Feb 28, 2020 at 11:00 AM Rob Clark wrote: > > On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer wrote: > > > > On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote: > > > > > > We could also do stuff like reducing the amount of tests we run on each > > > commit, and punt some testing to a

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

On Sat, Feb 29, 2020 at 3:47 PM Timur Kristóf wrote: > > On Sat, 2020-02-29 at 14:46 -0500, Nicolas Dufresne wrote: > > > > > > 1. I think we should completely disable running the CI on MRs which > > > are > > > marked WIP. Speaking from personal experience, I usually make a lot > > > of > > >

[PATCH xserver] xwayland: Fix backwards need_rotate logic (v2)

-off-by: Jason Ekstrand <ja...@jlekstrand.net> Reviewed-by: Daniel Stone <dani...@collabora.com> Cc: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-output.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/hw/xwayland/xwayland-output.c b/hw

[PATCH xserver] xwayland: Fix backwards need_rotate logic

clampped to the wrong dimensions. Signed-off-by: Jason Ekstrand <ja...@jlekstrand.net> Cc: Olivier Fourdan <ofour...@redhat.com> Cc: Daniel Stone <dani...@collabora.com> --- hw/xwayland/xwayland-output.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw

[PATCH xserver] xwayland: Fix backwards need_rotate logic

clampped to the wrong dimensions. Signed-off-by: Jason Ekstrand <ja...@jlekstrand.net> Cc: Olivier Fourdan <ofour...@redhat.com> Cc: Daniel Stone <dani...@collabora.com> --- hw/xwayland/xwayland-output.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw

Re: [RFC xserver v5 13/14] glamor: Use gbm_bo_create_with_modifiers for internal pixmap allocation

On Mon, Nov 6, 2017 at 1:30 PM, Louis-Francis Ratté-Boulianne < l...@collabora.com> wrote: > Using modifier might allow the driver to use a more optimal format > (e.g. tiled/compressed). Let's try to use those if possible. > > Signed-off-by: Louis-Francis Ratté-Boulianne >

Re: [RFC v2 00/10] DRI3 v1.1: modifiers and multi-plane

On Tue, Sep 5, 2017 at 1:01 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote: > I'm pulling down your series and trying to test it all out today. FYI, > you have to pass --disable-xwayland or it won't build. > I've gotten everything built but it's not working. It cras

Re: [RFC v2 00/10] DRI3 v1.1: modifiers and multi-plane

I'm pulling down your series and trying to test it all out today. FYI, you have to pass --disable-xwayland or it won't build. On Tue, Aug 29, 2017 at 9:45 PM, Louis-Francis Ratté-Boulianne < l...@collabora.com> wrote: > Hi, > > This is the RFC v2 for DRI3 v1.1 (minus the DMA fence part of it).

Re: [Mesa-dev] Time to update GSoC/EVoC ideas page

On Fri, Jan 20, 2017 at 2:15 AM, Nicolai Hähnle wrote: > Hi Rob, > > On 19.01.2017 23:32, Rob Clark wrote: > >> Just a friendly reminder that now would be a good time to update the >> wiki page for GSoC/EVoC ideas: >> >> https://www.x.org/wiki/SummerOfCodeIdeas/ >> >> There

Re: [PATCH] radv: fix depth transitions with layerCount = VK_REMAINING_ARRAY_LAYERS

Bah... cc mesa-dev On Fri, Jan 6, 2017 at 2:04 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote: > Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net> > > I'll let Dave or Bas push though. :-) > > On Fri, Jan 6, 2017 at 12:57 PM, Pierre-Loup A. Griffais < > p

Re: [PATCH] radv: fix depth transitions with layerCount = VK_REMAINING_ARRAY_LAYERS

Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net> I'll let Dave or Bas push though. :-) On Fri, Jan 6, 2017 at 12:57 PM, Pierre-Loup A. Griffais < pgriff...@valvesoftware.com> wrote: > Interpreting layerCount literally would try to create billions o

[PATCH v3 2/4] modesetting: Add drmmode_bo_has_bo and drmmode_bo_map helper function

Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com --- hw/xfree86/drivers/modesetting/drmmode_display.c | 43 ++-- 1 file changed, 32 insertions(+), 11 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/xfree86/drivers/modesetting

[PATCH v3 4/4] modesetting: Return the crtc for a drawable even if it's rotated

All of our checks for what crtc we are on take rotation into account so we select the correct crtc. The only problem is that we weren't returning it we were rotated. This caused X to think DRI3 apps were not on any crtc and limit them to 1 FPS. Signed-off-by: Jason Ekstrand jason.ekstr

[PATCH v3 0/4] modesetting: Add RandR-based shadow buffer support

RandR shadow support for everything in the future, but we don't do that yet. Jason Ekstrand (4): modesetting: Refactor drmmode_glamor_new_screen_pixmap modesetting: Add drmmode_bo_has_bo and drmmode_bo_map helper function modesetting: Add support for using RandR shadow buffers modesetting

[PATCH v3 3/4] modesetting: Add support for using RandR shadow buffers

This replaces the stubs for shadow buffer creation/allocation with actual functions and adds a shadow_destroy function. With this, we actually get shadow buffers and RandR now works properly. Most of this is copied from the xf86-video-intel driver and modified for modesetting. v2 Jason Ekstrand

[PATCH v3 1/4] modesetting: Refactor drmmode_glamor_new_screen_pixmap

set is NULL. The drmmode_glamor_new_screen_pixmap function is now just a 3-line wrapper around drmmode_set_pixmap_bo. v2 Jason Ekstrand jason.ekstr...@intel.com: - Re-arranged code in drmmode_set_pixmap_bo and drmmode_glamor_handle_new_screen_pixmap so that glamor_set_screen_pixmap only

Re: [PATCH v2 2/6] modesetting: Use a gbm buffer for shadow if we are using glamor

On Thu, Jan 8, 2015 at 2:10 PM, Keith Packard kei...@keithp.com wrote: Jason Ekstrand ja...@jlekstrand.net writes: +old_shadow = drmmode-shadow_bo; if (!drmmode_create_bo(drmmode, drmmode-front_bo, width, height, scrn-bitsPerPixel)) @@ -1218,13

Re: [PATCH v2 2/6] modesetting: Use a gbm buffer for shadow if we are using glamor

On Thu, Jan 8, 2015 at 8:30 PM, Jason Ekstrand ja...@jlekstrand.net wrote: On Thu, Jan 8, 2015 at 2:10 PM, Keith Packard kei...@keithp.com wrote: Jason Ekstrand ja...@jlekstrand.net writes: +old_shadow = drmmode-shadow_bo; if (!drmmode_create_bo(drmmode, drmmode-front_bo

[PATCH v2 3/6] modesetting: Refactor drmmode_glamor_new_screen_pixmap

set is NULL. The drmmode_glamor_new_screen_pixmap function is now just a 3-line wrapper around drmmode_set_pixmap_bo. v2 Jason Ekstrand jason.ekstr...@intel.com: - Re-arranged code in drmmode_set_pixmap_bo and drmmode_glamor_handle_new_screen_pixmap so that glamor_set_screen_pixmap only

[PATCH v2 0/6] Add shadow FB support to the modesetting driver

. If you'd like I can put together a documentation patch, but It isn't really realted to this series. Jason Ekstrand (6): modesetting: Allocate and destroy shadow_fb in drmmode_display modesetting: Use a gbm buffer for shadow if we are using glamor modesetting: Refactor

[PATCH v2 2/6] modesetting: Use a gbm buffer for shadow if we are using glamor

The drmmode_create_bo function already checks whether we're using glamor or not and makes the right choice about gbm vs. dumb buffers for us. We just need to call it. Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com --- hw/xfree86/drivers/modesetting/driver.c | 4 +-- hw/xfree86

[PATCH v2 1/6] modesetting: Allocate and destroy shadow_fb in drmmode_display

This way all of the buffer allocation/destruction is in the same file. v2 Jason Ekstrand jason.ekstr...@intel.com: - Don't change the signature of drmmode_free_bos Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com Reviewed-by: Keith Packard kei...@keithp.com --- hw/xfree86/drivers

[PATCH v2 5/6] modesetting: Add support for using shadow buffers

This replaces the stubs for shadow buffer creation/allocation with actual functions and adds a shadow_destroy function. With this, we actually get shadow buffers and RandR now works properly. Most of this is copied from the xf86-video-intel driver and modified for modesetting. v2 Jason Ekstrand

[PATCH v2 4/6] modesetting: Add a drmmode_bo_has_bo helper function

--- hw/xfree86/drivers/modesetting/drmmode_display.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/xfree86/drivers/modesetting/drmmode_display.c index 74a9e3b..5040d38 100644 ---

[PATCH v2 6/6] modesetting: Return the crtc for a drawable even if it's rotated

All of our checks for what crtc we are on take rotation into account so we select the correct crtc. The only problem is that we weren't returning it we were rotated. This caused X to think DRI3 apps were not on any crtc and limit them to 1 FPS. Signed-off-by: Jason Ekstrand jason.ekstr

Re: [PATCH 2/4] modesetting: Use a gbm buffer for shadow if we can

On Thu, Dec 25, 2014 at 1:46 PM, Keith Packard kei...@keithp.com wrote: Jason Ekstrand ja...@jlekstrand.net writes: Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com We probably only want to use a gbm buffer if we're using glamor; otherwise, it's possible we'll get potentially slow

Re: [PATCH 1/4] modesetting: Allocate and destroy shadow_fb in drmmode_display

While these patches seem to work ok, somethings not properly getting accelerated when using a shadow buffer and I really don't know why. I guess it's still better than no shadow. On Fri, Dec 19, 2014 at 2:25 PM, Jason Ekstrand ja...@jlekstrand.net wrote: I've also pushed a branch with my

Re: [PATCH v2 1/5] present: If present_queue_vblank() fails, do present_execute().

It's been working for me since last night and has even survived sleeping a couple of times. Tested-by: Jason Ekstrand jason.ekstr...@intel.com On Thu, Dec 18, 2014 at 7:33 PM, Keith Packard kei...@keithp.com wrote: Kenneth Graunke kenn...@whitecape.org writes: Previously

[PATCH 4/4] modesetting: Add support for using shadow buffers

-by: Jason Ekstrand jason.ekstr...@intel.com --- hw/xfree86/drivers/modesetting/drmmode_display.c | 116 ++- 1 file changed, 114 insertions(+), 2 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/xfree86/drivers/modesetting/drmmode_display.c index

[PATCH 1/4] modesetting: Allocate and destroy shadow_fb in drmmode_display

This way all of the buffer allocation/destruction is in the same file. Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com --- hw/xfree86/drivers/modesetting/driver.c | 16 +--- hw/xfree86/drivers/modesetting/drmmode_display.c | 19 ++- hw/xfree86/drivers

[PATCH 2/4] modesetting: Use a gbm buffer for shadow if we can

Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com --- hw/xfree86/drivers/modesetting/driver.c | 4 +-- hw/xfree86/drivers/modesetting/drmmode_display.c | 43 +++- hw/xfree86/drivers/modesetting/drmmode_display.h | 3 +- 3 files changed, 31 insertions(+), 19

[PATCH 3/4] modesetting: Refactor drmmode_glamor_new_screen_pixmap

set is NULL. The drmmode_glamor_new_screen_pixmap function is now just a 3-line wrapper around drmmode_set_pixmap_bo. Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com --- hw/xfree86/drivers/modesetting/drmmode_display.c | 29 +++- 1 file changed, 18 insertions(+), 11

[PATCH 3/4] modesetting: Refactor drmmode_glamor_new_screen_pixmap

set is NULL. The drmmode_glamor_new_screen_pixmap function is now just a 3-line wrapper around drmmode_set_pixmap_bo. Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com --- hw/xfree86/drivers/modesetting/drmmode_display.c | 29 +++- 1 file changed, 18 insertions(+), 11

[PATCH 4/4] modesetting: Add support for using shadow buffers

-by: Jason Ekstrand jason.ekstr...@intel.com --- hw/xfree86/drivers/modesetting/drmmode_display.c | 116 ++- 1 file changed, 114 insertions(+), 2 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/xfree86/drivers/modesetting/drmmode_display.c index

[PATCH 1/4] modesetting: Allocate and destroy shadow_fb in drmmode_display

This way all of the buffer allocation/destruction is in the same file. Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com --- hw/xfree86/drivers/modesetting/driver.c | 16 +--- hw/xfree86/drivers/modesetting/drmmode_display.c | 19 ++- hw/xfree86/drivers

[PATCH 2/4] modesetting: Use a gbm buffer for shadow if we can

Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com --- hw/xfree86/drivers/modesetting/driver.c | 4 +-- hw/xfree86/drivers/modesetting/drmmode_display.c | 43 +++- hw/xfree86/drivers/modesetting/drmmode_display.h | 3 +- 3 files changed, 31 insertions(+), 19

Re: [PATCH 1/4] modesetting: Allocate and destroy shadow_fb in drmmode_display

I've also pushed a branch with my patches on top of Ken's new present patches here: http://cgit.freedesktop.org/~jekstrand/xserver/log/?h=wip/modeset-shadow On Fri, Dec 19, 2014 at 2:12 PM, Jason Ekstrand ja...@jlekstrand.net wrote: This way all of the buffer allocation/destruction

Re: [PATCH 2/2] modesetting: Detect whether damage tracking is needed

On Dec 19, 2014 9:48 PM, Keith Packard kei...@keithp.com wrote: Jason Ekstrand ja...@jlekstrand.net writes: +if (err != -EINVAL err != -ENOSYS) { I'm not terribly familiar with the ioctls here, but why are we ignoring EINVAL? The previous patch made it sound like ENOSYS was the I

Re: [PATCH v2 2/2] modesetting: Add vblank synchronization support when using Present.

already did). Without this, Jason Ekstrand and I saw compositor lockups (stuck waiting for an event that never came) when doing lid close or suspend. Also simplify the ms_present_get_crtc function. vblank.c already implements the functionality; we just need to convert types

Re: [PATCH] modesetting: Add vblank synchronization support when using Present.

On Thu, Dec 11, 2014 at 3:16 PM, Kenneth Graunke kenn...@whitecape.org wrote: modesetting hooked up vblank support for DRI2, but was missing support for vblanks in Present. This is mostly copy and pasted from Keith's code in the intel driver. Signed-off-by: Kenneth Graunke

Re: [PATCH] modesetting: Add vblank synchronization support when using Present.

it without the patch. --Jason On Fri, Dec 12, 2014 at 10:21 AM, Jason Ekstrand ja...@jlekstrand.net wrote: On Thu, Dec 11, 2014 at 3:16 PM, Kenneth Graunke kenn...@whitecape.org wrote: modesetting hooked up vblank support for DRI2, but was missing support for vblanks in Present

Re: What use do swap interval 1 and OML_sync_control divisor and remainder have?

is the only right way, let me know and I can start another email thread about that detail after preparing my material. Thanks, pq I hope that's helpful, --Jason Ekstrand ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg