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 to
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 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:
> >
> > 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
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
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 ne
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
> >
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:
> >
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
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 m
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 :
>
explain 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
very much want to solve the problem "properly" but unless
we're very sure we can get it solved 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 Jack
on to start moving others and maybe we can actually build the
momentum to get most everything converted.
For reference, you can find the kernel RFC patches and mesa MR here:
https://lists.freedesktop.org/archives/dri-devel/2020-March/258833.html
https://gitlab.freedesktop.org/mesa/mesa/-/merge_re
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'
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
fai
hort order.
Again, sorry I was so terse. I was just trying to slow the panic.
> 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 m
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 per-weeke
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
> > > cha
igned-off-by: Jason Ekstrand
Reviewed-by: Daniel Stone
Cc: Olivier Fourdan
---
hw/xwayland/xwayland-output.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index c593896..48faeb1 100644
--- a/hw/xwayland/xwa
clampped to the wrong dimensions.
Signed-off-by: Jason Ekstrand
Cc: Olivier Fourdan
Cc: Daniel Stone
---
hw/xwayland/xwayland-output.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index c593896..257c3ee 100644
clampped to the wrong dimensions.
Signed-off-by: Jason Ekstrand
Cc: Olivier Fourdan
Cc: Daniel Stone
---
hw/xwayland/xwayland-output.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
index c593896..257c3ee 100644
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
> ---
> glamor/glamor_eg
On Tue, Sep 5, 2017 at 1:01 PM, Jason Ekstrand 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 crashes immediately
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). F
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 are currently still
Bah... cc mesa-dev
On Fri, Jan 6, 2017 at 2:04 PM, Jason Ekstrand wrote:
> Reviewed-by: Jason Ekstrand
>
> 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:
>
>> Inter
Reviewed-by: Jason Ekstrand
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 of image
> views in radv_process_depth_image_inpl
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
modese
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
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 :
- Re-arranged code in drmmode_set_pixmap_bo and
drmmode_glamor_handle_new_screen_pixmap so that glamor_set_screen_pixmap
only gets called for the screen
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
Reviewed-by:
Signed-off-by: Jason Ekstrand
---
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/drmmode_display.c
index ea59ffe
On Thu, Jan 8, 2015 at 8:30 PM, Jason Ekstrand wrote:
>
>
> On Thu, Jan 8, 2015 at 2:10 PM, Keith Packard wrote:
>
>> Jason Ekstrand writes:
>>
>> > +old_shadow = drmmode->shadow_bo;
>> >
>> > if (!drmmode_create_bo(drmmode, &
On Thu, Jan 8, 2015 at 2:10 PM, Keith Packard wrote:
> Jason Ekstrand writes:
>
> > +old_shadow = drmmode->shadow_bo;
> >
> > if (!drmmode_create_bo(drmmode, &drmmode->front_bo,
> > width, height, scrn
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
---
hw/xf
---
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
--- a/hw/xfree86/drivers/modesetting/drmmode_disp
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
---
hw/xfree86/drivers/modesetting/driver.c | 4 +--
hw/xfree86/drivers/modese
This way all of the buffer allocation/destruction is in the same file.
v2 Jason Ekstrand :
- Don't change the signature of drmmode_free_bos
Signed-off-by: Jason Ekstrand
Reviewed-by: Keith Packard
---
hw/xfree86/drivers/modesetting/driver.c | 14 --
hw/xfree86/dr
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
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 :
- Re-arranged code in drmmode_set_pixmap_bo and
drmmode_glamor_handle_new_screen_pixmap so that glamor_set_screen_pixmap
only gets called for the screen
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
On Thu, Dec 25, 2014 at 1:46 PM, Keith Packard wrote:
> Jason Ekstrand writes:
>
> > Signed-off-by: Jason Ekstrand
>
> We probably only want to use a gbm buffer if we're using glamor;
> otherwise, it's possible we'll get potentially slow video memory for our
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
wrote:
>
> I've also pushed a branch with my pa
On Dec 19, 2014 9:48 PM, "Keith Packard" wrote:
>
> Jason Ekstrand writes:
>
>
> >> +if (err != -EINVAL && err != -ENOSYS) {
> >
> > I'm not terribly familiar with the ioctls here, but why are we ignoring
> > EINVAL? The previou
not terribly familiar with the ioctls here, but why are we ignoring
EINVAL? The previous patch made it sound like ENOSYS was the "I don't
support this" error and EINVAL was a genuine error.
Apart from this my limited X knowledge says it looks perfectly
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
wrote:
>
> This way all of the buffer allocation/destruction is
Signed-off-by: Jason Ekstrand
---
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 deletions(-)
diff --git a
This way all of the buffer allocation/destruction is in the same file.
Signed-off-by: Jason Ekstrand
---
hw/xfree86/drivers/modesetting/driver.c | 16 +---
hw/xfree86/drivers/modesetting/drmmode_display.c | 19 ++-
hw/xfree86/drivers/modesetting
: Jason Ekstrand
---
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 5648d7b..8ac5c77 100644
--- a
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
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 29 +++-
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a
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
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 29 +++-
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a
Signed-off-by: Jason Ekstrand
---
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 deletions(-)
diff --git a
: Jason Ekstrand
---
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 5648d7b..8ac5c77 100644
--- a
This way all of the buffer allocation/destruction is in the same file.
Signed-off-by: Jason Ekstrand
---
hw/xfree86/drivers/modesetting/driver.c | 16 +---
hw/xfree86/drivers/modesetting/drmmode_display.c | 19 ++-
hw/xfree86/drivers/modesetting
It's been working for me since last night and has even survived sleeping a
couple of times.
Tested-by: Jason Ekstrand
On Thu, Dec 18, 2014 at 7:33 PM, Keith Packard wrote:
>
> Kenneth Graunke writes:
>
> > Previously, if present_queue_vblank() failed, we simply dropped the
ch the
> DRI2 code 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 func
ven't
seen it without the patch.
--Jason
On Fri, Dec 12, 2014 at 10:21 AM, Jason Ekstrand
wrote:
>
>
>
> On Thu, Dec 11, 2014 at 3:16 PM, Kenneth Graunke
> wrote:
>>
>> modesetting hooked up vblank support for DRI2, but was missing support
>> for vblanks in Pr
On Thu, Dec 11, 2014 at 3:16 PM, Kenneth Graunke
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
> ---
> hw/xfree86/drivers/mod
ing advantage of some new cool
> technology.
>
> Btw. if you think that using UST for presentation timing and feedback
> is nonsense, and MSC is the only right way, let me know and I can start
> another email thread about that detail after preparing my material.
>
>
> Thanks,
>
59 matches
Mail list logo
