Re: [PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-30 Thread Mike Lothian 
Also with the intel DDX I was seeing a black screen after the monitor
switches itself off (I can still see the cursor) VT switching away and back
again fixes the issue

I'm going to ask again that 1.20 isn't cut until at least some of these
issues are resolved

On Mon, 30 Apr 2018 at 11:36 Mike Lothian  wrote:

> Hi
>
> I'll get one raised just for that
>
> After further testing the above patch with the intel ddx I notice vulkan
> programs don't run, they exit with an assert in the mesa code something to
> do with modifiers chain
>
> I'll raise a separate bug for that, it happens with smoketest and Rise of
> the Tomb Raider
>
> On Mon, 30 Apr 2018 at 08:26 Mario Kleiner 
> wrote:
>
>> On Wed, Apr 25, 2018 at 2:23 AM, Mike Lothian 
>> wrote:
>> >
>> > The plasmashell & steam freezes aren't present with the Intel or AMDGPU
>> > DDXs, only modesetting
>> >
>> > I'm quite happy to mark
>> https://bugs.freedesktop.org/show_bug.cgi?id=105851
>> > as resolved and look into the modesetting freezes seperately
>> >
>> > Cheers again
>> >
>> > Mike
>>
>> Mike, a bug report about those freezes would be good. I see the same
>> annoying freezes of the KDE panel randomly on my old KUbuntu 16.04
>> plasmashell, only with modesetting on server 1.20, but on all gpu's.
>> So far i was mostly unsuccessful in finding the cause. The only thing
>> i found so far is that Mesa's dri3 loader always gets stuck trying to
>> get a new back buffer in dri3_find_back, apparently waiting for a
>> reply from the server that it never receives, like in this stacktrace:
>>
>> plasmashell stuck, modesetting ddx, dri3, normal or with
>> dmabuf_modifiers, raw or composited/egl - bt:
>>
>> #0  0x7feb6f5f074d in poll () at ../sysdeps/unix/syscall-template.S:84
>> #1  0x7feb736b8172 in poll (__timeout=-1, __nfds=1,
>> __fds=0x7ffdb6c2baf0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
>> #2  _xcb_conn_wait (c=c@entry=0xc25390, cond=cond@entry=0x36a40d8,
>> vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:479
>> #3  0x7feb736b9e69 in xcb_wait_for_special_event (c=0xc25390,
>> se=0x36a40b0) at xcb_in.c:795
>> #4  0x7feb6b82b246 in dri3_wait_for_event_locked (draw=0x43d6358)
>> at loader_dri3_helper.c:454
>> #5  0x7feb6b82b3b8 in dri3_find_back (draw=draw@entry=0x43d6358)
>> at loader_dri3_helper.c:580
>> #6  0x7feb6b82c506 in dri3_get_buffer (format=format@entry=4107,
>> buffer_type=buffer_type@entry=loader_dri3_buffer_back,
>> draw=draw@entry=0x43d6358, driDrawable=0x405b4c0) at
>> loader_dri3_helper.c:1656
>> #7  0x7feb6b82d291 in loader_dri3_get_buffers
>> (driDrawable=driDrawable@entry=0x405b4c0, format=4107,
>> stamp=stamp@entry=0x405b4f0,
>> loaderPrivate=loaderPrivate@entry=0x43d6358, buffer_mask=> out>, buffer_mask@entry=1, buffers=buffers@entry=0x7ffdb6c2bde0)
>> at loader_dri3_helper.c:1861
>> #8  0x7feb4b54681d in intel_update_image_buffers
>> (drawable=0x405b4c0, brw=0x16aaec0) at brw_context.c:1753
>> #9  intel_update_renderbuffers (context=context@entry=0x15bc840,
>> drawable=drawable@entry=0x405b4c0) at brw_context.c:1429
>> #10 0x7feb4b546cf1 in intel_prepare_render
>> (brw=brw@entry=0x16aaec0) at brw_context.c:1450
>> #11 0x7feb4b5419ea in brw_clear (ctx=0x16aaec0, mask=50) at
>> brw_clear.c:300
>> #12 0x7feb72f4049a in QSGBatchRenderer::Renderer::renderBatches()
>> () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
>> #13 0x7feb72f45e82 in QSGBatchRenderer::Renderer::render() () from
>> /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
>> #14 0x7feb72f51b6f in QSGRenderer::renderScene(QSGBindable const&)
>> () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
>> #15 0x7feb72f523bb in QSGRenderer::renderScene(unsigned int) ()
>> from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
>> #16 0x7feb72f6287e in
>> QSGRenderContext::renderNextFrame(QSGRenderer*, unsigned int) () from
>> /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
>> #17 0x7feb72fad0db in QQuickWindowPrivate::renderSceneGraph(QSize
>> const&) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
>> #18 0x7feb72f7d19b in ?? () from
>> /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
>> #19 0x7feb72f7e2a1 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
>> #20 0x7feb709ca05c in QApplicationPrivate::notify_helper(QObject*,
>> QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
>> #21 0x7feb709cf516 in QApplication::notify(QObject*, QEvent*) ()
>> from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
>> #22 0x7feb6fec738b in QCoreApplication::notifyInternal(QObject*,
>> QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
>> #23 0x7feb6ff1c5ed in QTimerInfoList::activateTimers() () from
>> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
>> #24 0x7feb6ff1caf1 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
>> #25 0x7feb6c384197 in g_main_context_dispatch () from
>>

Re: [PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-30 Thread Mike Lothian 
Hi

I'll get one raised just for that

After further testing the above patch with the intel ddx I notice vulkan
programs don't run, they exit with an assert in the mesa code something to
do with modifiers chain

I'll raise a separate bug for that, it happens with smoketest and Rise of
the Tomb Raider

On Mon, 30 Apr 2018 at 08:26 Mario Kleiner 
wrote:

> On Wed, Apr 25, 2018 at 2:23 AM, Mike Lothian  wrote:
> >
> > The plasmashell & steam freezes aren't present with the Intel or AMDGPU
> > DDXs, only modesetting
> >
> > I'm quite happy to mark
> https://bugs.freedesktop.org/show_bug.cgi?id=105851
> > as resolved and look into the modesetting freezes seperately
> >
> > Cheers again
> >
> > Mike
>
> Mike, a bug report about those freezes would be good. I see the same
> annoying freezes of the KDE panel randomly on my old KUbuntu 16.04
> plasmashell, only with modesetting on server 1.20, but on all gpu's.
> So far i was mostly unsuccessful in finding the cause. The only thing
> i found so far is that Mesa's dri3 loader always gets stuck trying to
> get a new back buffer in dri3_find_back, apparently waiting for a
> reply from the server that it never receives, like in this stacktrace:
>
> plasmashell stuck, modesetting ddx, dri3, normal or with
> dmabuf_modifiers, raw or composited/egl - bt:
>
> #0  0x7feb6f5f074d in poll () at ../sysdeps/unix/syscall-template.S:84
> #1  0x7feb736b8172 in poll (__timeout=-1, __nfds=1,
> __fds=0x7ffdb6c2baf0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
> #2  _xcb_conn_wait (c=c@entry=0xc25390, cond=cond@entry=0x36a40d8,
> vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:479
> #3  0x7feb736b9e69 in xcb_wait_for_special_event (c=0xc25390,
> se=0x36a40b0) at xcb_in.c:795
> #4  0x7feb6b82b246 in dri3_wait_for_event_locked (draw=0x43d6358)
> at loader_dri3_helper.c:454
> #5  0x7feb6b82b3b8 in dri3_find_back (draw=draw@entry=0x43d6358)
> at loader_dri3_helper.c:580
> #6  0x7feb6b82c506 in dri3_get_buffer (format=format@entry=4107,
> buffer_type=buffer_type@entry=loader_dri3_buffer_back,
> draw=draw@entry=0x43d6358, driDrawable=0x405b4c0) at
> loader_dri3_helper.c:1656
> #7  0x7feb6b82d291 in loader_dri3_get_buffers
> (driDrawable=driDrawable@entry=0x405b4c0, format=4107,
> stamp=stamp@entry=0x405b4f0,
> loaderPrivate=loaderPrivate@entry=0x43d6358, buffer_mask= out>, buffer_mask@entry=1, buffers=buffers@entry=0x7ffdb6c2bde0)
> at loader_dri3_helper.c:1861
> #8  0x7feb4b54681d in intel_update_image_buffers
> (drawable=0x405b4c0, brw=0x16aaec0) at brw_context.c:1753
> #9  intel_update_renderbuffers (context=context@entry=0x15bc840,
> drawable=drawable@entry=0x405b4c0) at brw_context.c:1429
> #10 0x7feb4b546cf1 in intel_prepare_render
> (brw=brw@entry=0x16aaec0) at brw_context.c:1450
> #11 0x7feb4b5419ea in brw_clear (ctx=0x16aaec0, mask=50) at
> brw_clear.c:300
> #12 0x7feb72f4049a in QSGBatchRenderer::Renderer::renderBatches()
> () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
> #13 0x7feb72f45e82 in QSGBatchRenderer::Renderer::render() () from
> /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
> #14 0x7feb72f51b6f in QSGRenderer::renderScene(QSGBindable const&)
> () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
> #15 0x7feb72f523bb in QSGRenderer::renderScene(unsigned int) ()
> from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
> #16 0x7feb72f6287e in
> QSGRenderContext::renderNextFrame(QSGRenderer*, unsigned int) () from
> /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
> #17 0x7feb72fad0db in QQuickWindowPrivate::renderSceneGraph(QSize
> const&) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
> #18 0x7feb72f7d19b in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
> #19 0x7feb72f7e2a1 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
> #20 0x7feb709ca05c in QApplicationPrivate::notify_helper(QObject*,
> QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> #21 0x7feb709cf516 in QApplication::notify(QObject*, QEvent*) ()
> from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
> #22 0x7feb6fec738b in QCoreApplication::notifyInternal(QObject*,
> QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> #23 0x7feb6ff1c5ed in QTimerInfoList::activateTimers() () from
> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> #24 0x7feb6ff1caf1 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> #25 0x7feb6c384197 in g_main_context_dispatch () from
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #26 0x7feb6c3843f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #27 0x7feb6c38449c in g_main_context_iteration () from
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #28 0x7feb6ff1d7eb in
> QEventDispatcherGlib::processEvents(QFlags)
> () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> #29 0x7feb6fec4b4a in
> QEventLoop::exec(QFlags) () from
> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> #30

Re: [PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-30 Thread Mario Kleiner 
On Wed, Apr 25, 2018 at 2:23 AM, Mike Lothian  wrote:
>
> The plasmashell & steam freezes aren't present with the Intel or AMDGPU
> DDXs, only modesetting
>
> I'm quite happy to mark https://bugs.freedesktop.org/show_bug.cgi?id=105851
> as resolved and look into the modesetting freezes seperately
>
> Cheers again
>
> Mike

Mike, a bug report about those freezes would be good. I see the same
annoying freezes of the KDE panel randomly on my old KUbuntu 16.04
plasmashell, only with modesetting on server 1.20, but on all gpu's.
So far i was mostly unsuccessful in finding the cause. The only thing
i found so far is that Mesa's dri3 loader always gets stuck trying to
get a new back buffer in dri3_find_back, apparently waiting for a
reply from the server that it never receives, like in this stacktrace:

plasmashell stuck, modesetting ddx, dri3, normal or with
dmabuf_modifiers, raw or composited/egl - bt:

#0  0x7feb6f5f074d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7feb736b8172 in poll (__timeout=-1, __nfds=1,
__fds=0x7ffdb6c2baf0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2  _xcb_conn_wait (c=c@entry=0xc25390, cond=cond@entry=0x36a40d8,
vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:479
#3  0x7feb736b9e69 in xcb_wait_for_special_event (c=0xc25390,
se=0x36a40b0) at xcb_in.c:795
#4  0x7feb6b82b246 in dri3_wait_for_event_locked (draw=0x43d6358)
at loader_dri3_helper.c:454
#5  0x7feb6b82b3b8 in dri3_find_back (draw=draw@entry=0x43d6358)
at loader_dri3_helper.c:580
#6  0x7feb6b82c506 in dri3_get_buffer (format=format@entry=4107,
buffer_type=buffer_type@entry=loader_dri3_buffer_back,
draw=draw@entry=0x43d6358, driDrawable=0x405b4c0) at
loader_dri3_helper.c:1656
#7  0x7feb6b82d291 in loader_dri3_get_buffers
(driDrawable=driDrawable@entry=0x405b4c0, format=4107,
stamp=stamp@entry=0x405b4f0,
loaderPrivate=loaderPrivate@entry=0x43d6358, buffer_mask=, buffer_mask@entry=1, buffers=buffers@entry=0x7ffdb6c2bde0)
at loader_dri3_helper.c:1861
#8  0x7feb4b54681d in intel_update_image_buffers
(drawable=0x405b4c0, brw=0x16aaec0) at brw_context.c:1753
#9  intel_update_renderbuffers (context=context@entry=0x15bc840,
drawable=drawable@entry=0x405b4c0) at brw_context.c:1429
#10 0x7feb4b546cf1 in intel_prepare_render
(brw=brw@entry=0x16aaec0) at brw_context.c:1450
#11 0x7feb4b5419ea in brw_clear (ctx=0x16aaec0, mask=50) at brw_clear.c:300
#12 0x7feb72f4049a in QSGBatchRenderer::Renderer::renderBatches()
() from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#13 0x7feb72f45e82 in QSGBatchRenderer::Renderer::render() () from
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#14 0x7feb72f51b6f in QSGRenderer::renderScene(QSGBindable const&)
() from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#15 0x7feb72f523bb in QSGRenderer::renderScene(unsigned int) ()
from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#16 0x7feb72f6287e in
QSGRenderContext::renderNextFrame(QSGRenderer*, unsigned int) () from
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#17 0x7feb72fad0db in QQuickWindowPrivate::renderSceneGraph(QSize
const&) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#18 0x7feb72f7d19b in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#19 0x7feb72f7e2a1 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#20 0x7feb709ca05c in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#21 0x7feb709cf516 in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#22 0x7feb6fec738b in QCoreApplication::notifyInternal(QObject*,
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x7feb6ff1c5ed in QTimerInfoList::activateTimers() () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x7feb6ff1caf1 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#25 0x7feb6c384197 in g_main_context_dispatch () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x7feb6c3843f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x7feb6c38449c in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#28 0x7feb6ff1d7eb in
QEventDispatcherGlib::processEvents(QFlags)
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#29 0x7feb6fec4b4a in
QEventLoop::exec(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#30 0x7feb6feccbec in QCoreApplication::exec() () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#31 0x00432d4a in main ()

Anyway this would need to go into that bug report of yours.

thanks,
-mario
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-25 Thread Mario Kleiner 
On Wed, Apr 25, 2018 at 8:50 PM, Adam Jackson  wrote:
> On Wed, 2018-04-25 at 00:23 +, Mike Lothian wrote:
>
>> Hi Mario
>>
>> Thanks for fixing this, that's xserver 1.20 working with the Intel and 
>> AMDGPU DDXs on my laptop with Kwin
>>
>> The plasmashell & steam freezes aren't present with the Intel or AMDGPU 
>> DDXs, only modesetting
>>
>> I'm quite happy to mark https://bugs.freedesktop.org/show_bug.cgi?id=105851 
>> as resolved and look into the modesetting freezes seperately
>>
>> Feel free to add my:
>>
>> Tested-by: Mike Lothian 
>
> Merged, thanks:
>
> remote: I: patch #218453 updated using rev 
> 352a5ac87fd344936b759a5766eb74271e7d295d.
> remote: I: 1 patch(es) updated to state Accepted.
> To ssh://git.freedesktop.org/git/xorg/xserver
>c6ab21022c..352a5ac87f  master -> master
>
> - ajax

Thanks. Haven't had time to test current master yet, maybe will in a
few hours. But your "dri3: Clamp to 1.0 if not all screens support
1.2" would solve the same problem as this patch, so this one might be
redundant now, apart from my lengthy commit message documenting the
problem that both patches try to solve?

Your dri3_screen_can_one_point_two() function will probably also need
to check for the info->get_formats, ->get_modifiers, ->pixmap_from_fds
etc. hooks of the version2 rec being non-NULL, instead of only
checking for dri3->info->version >= 2? The intel-ddx and nouveau-ddx
define the .version = DRI3_SCREEN_INFO_VERSION; which would be 2 when
built against server 1.20's headers, but they don't define the hooks,
so would fool the check?

-mario
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-25 Thread Adam Jackson 
On Wed, 2018-04-25 at 00:23 +, Mike Lothian wrote:

> Hi Mario
> 
> Thanks for fixing this, that's xserver 1.20 working with the Intel and AMDGPU 
> DDXs on my laptop with Kwin
> 
> The plasmashell & steam freezes aren't present with the Intel or AMDGPU DDXs, 
> only modesetting
> 
> I'm quite happy to mark https://bugs.freedesktop.org/show_bug.cgi?id=105851 
> as resolved and look into the modesetting freezes seperately
> 
> Feel free to add my:
> 
> Tested-by: Mike Lothian 

Merged, thanks:

remote: I: patch #218453 updated using rev 
352a5ac87fd344936b759a5766eb74271e7d295d.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   c6ab21022c..352a5ac87f  master -> master

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-24 Thread Mike Lothian 
On Tue, 24 Apr 2018 at 09:17 Mario Kleiner 
wrote:

> Both xf86-video-intel and xf86-video-nouveau cause OpenGL
> clients to fail when used with DRI3 on server 1.20 with Mesa 18.1.
>
> Reason is that the servers DRI3 version is now unconditionally
> reported as DRI3 1.2 to 1.2 capable clients. This causes clients
> using Mesa 18.1 to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
> DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx
> do not support the needed hooks like info->pixmap_from_fds or
> info->get_formats, info->get_modifiers. Unfortunately we can't
> simply report the servers DRI3 version as 1.0 in this case, as
> the reported version can not be specific to a X-Screen, and
> different screens may have drivers with different capabilities.
>
> Luckily the server has fallbacks to ->pixmap_from_fd, ->fd_from_pixmap,
> and simply reporting an empty set of supported modifiers for the
> DRI3GetSupportedModifiers request if the ddx doesn't support
> DRI 3.2.
>
> Clients like Mesa 18.1's dri3 loader respond to the empty set
> of reported modifiers by falling back to a dri driver selected
> buffer format (image->createImageWithModifiers responds to a
> NULL modifier_list by acting like ->createImage()). This works,
> but Mesa 18.1 will still try to use the DRI3PixmapFromBuffers
> request to create the corresponding pixmap, just passing in
> a modifier that corresponds to whatever tiling the dri driver
> selected by default. To prevent this request - and thereby
> the client - from failing with a BadImplementation error,
> remove the check for modifier == DRM_MOD_FORMAT_INVALID in
> the pixmap_from_fd fallback path of dri3_pixmap_from_fds()
> and trust that if we hit the fallback path then the client
> will have passed a buffer with some driver specific default
> tiling that can be handled by pixmap_from_fd.
>
> Another approach would be for Mesa's dri3 loader to keep
> track how a buffer was created (with explicit modifiers or
> not), and then call DRI3PixmapFromBuffers or DRI3PixmapFromBuffer,
> but then any future DRI3 client implementation would need to be
> fixed, so the server side is probably the better place for this.
>
> Tested on Intel Ivybridge and NVidia Pascal.
>
> Fixes: 6e7c40f62db6 ("dri3: Add multi-planar/modifier buffer requests")
> Signed-off-by: Mario Kleiner 
> Cc: Daniel Stone 
> Cc: Louis-Francis Ratté-Boulianne 
> ---
>  dri3/dri3_screen.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
> index 23e33f4..243dab7 100644
> --- a/dri3/dri3_screen.c
> +++ b/dri3/dri3_screen.c
> @@ -66,8 +66,7 @@ dri3_pixmap_from_fds(PixmapPtr *ppixmap, ScreenPtr
> screen,
>  if (info->version >= 2 && info->pixmap_from_fds != NULL) {
>  pixmap = (*info->pixmap_from_fds) (screen, num_fds, fds, width,
> height,
> strides, offsets, depth, bpp,
> modifier);
> -} else if (info->pixmap_from_fd != NULL && num_fds == 1 &&
> -   modifier == DRM_FORMAT_MOD_INVALID) {
> +} else if (info->pixmap_from_fd != NULL && num_fds == 1) {
>  pixmap = (*info->pixmap_from_fd) (screen, fds[0], width, height,
>strides[0], depth, bpp);
>  } else {
> --
> 2.7.4
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel


Hi Mario

Thanks for fixing this, that's xserver 1.20 working with the Intel and
AMDGPU DDXs on my laptop with Kwin

The plasmashell & steam freezes aren't present with the Intel or AMDGPU
DDXs, only modesetting

I'm quite happy to mark https://bugs.freedesktop.org/show_bug.cgi?id=105851 as
resolved and look into the modesetting freezes seperately

Feel free to add my:

Tested-by: Mike Lothian 

Cheers again

Mike
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-24 Thread Daniel Stone 
Hi Adam,

On 24 April 2018 at 20:52, Adam Jackson  wrote:
> On Tue, 2018-04-24 at 11:42 +0100, Daniel Stone wrote:
>> On 24 April 2018 at 09:17, Mario Kleiner  wrote:
>> > Both xf86-video-intel and xf86-video-nouveau cause OpenGL
>> > clients to fail when used with DRI3 on server 1.20 with Mesa 18.1.
>> >
>> > Reason is that the servers DRI3 version is now unconditionally
>> > reported as DRI3 1.2 to 1.2 capable clients. This causes clients
>> > using Mesa 18.1 to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
>> > DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx
>> > do not support the needed hooks like info->pixmap_from_fds or
>> > info->get_formats, info->get_modifiers. Unfortunately we can't
>> > simply report the servers DRI3 version as 1.0 in this case, as
>> > the reported version can not be specific to a X-Screen, and
>> > different screens may have drivers with different capabilities.
>
> I think this implies we should not advertise 1.2 if any screen lacks
> the 1.2 hooks.

To be honest, I'd be fine with that too.

>> Thanks a lot for hunting this down! This fix does still make me
>> uncomfortable though. I think a better fix would be, on the Mesa side,
>> to never call any 1.2 codepaths for the server if we get no
>> formats/modifiers back from the GetSupported calls, and to never call
>> any 1.2 codepaths for the drawable if DRIImage's
>> createImageWithModifiers does not exist or if it fails and we fall
>> back to regular createImage. That way we make sure that both sides
>> exercise the same behaviour: either both with explicit modifiers, or
>> neither.
>
> The problem with that strategy is it means 1.20 would be compatible
> with zero already-released versions of Mesa.

True, though it is only 18.1.0rc1 broken now, and we've plenty of time
before rc2.

Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-24 Thread Adam Jackson 
On Tue, 2018-04-24 at 11:42 +0100, Daniel Stone wrote:
> Hi Mario,
> 
> On 24 April 2018 at 09:17, Mario Kleiner  wrote:
> > Both xf86-video-intel and xf86-video-nouveau cause OpenGL
> > clients to fail when used with DRI3 on server 1.20 with Mesa 18.1.
> > 
> > Reason is that the servers DRI3 version is now unconditionally
> > reported as DRI3 1.2 to 1.2 capable clients. This causes clients
> > using Mesa 18.1 to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
> > DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx
> > do not support the needed hooks like info->pixmap_from_fds or
> > info->get_formats, info->get_modifiers. Unfortunately we can't
> > simply report the servers DRI3 version as 1.0 in this case, as
> > the reported version can not be specific to a X-Screen, and
> > different screens may have drivers with different capabilities.

I think this implies we should not advertise 1.2 if any screen lacks
the 1.2 hooks.

> Thanks a lot for hunting this down! This fix does still make me
> uncomfortable though. I think a better fix would be, on the Mesa side,
> to never call any 1.2 codepaths for the server if we get no
> formats/modifiers back from the GetSupported calls, and to never call
> any 1.2 codepaths for the drawable if DRIImage's
> createImageWithModifiers does not exist or if it fails and we fall
> back to regular createImage. That way we make sure that both sides
> exercise the same behaviour: either both with explicit modifiers, or
> neither.

The problem with that strategy is it means 1.20 would be compatible
with zero already-released versions of Mesa.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

2018-04-24 Thread Daniel Stone 
Hi Mario,

On 24 April 2018 at 09:17, Mario Kleiner  wrote:
> Both xf86-video-intel and xf86-video-nouveau cause OpenGL
> clients to fail when used with DRI3 on server 1.20 with Mesa 18.1.
>
> Reason is that the servers DRI3 version is now unconditionally
> reported as DRI3 1.2 to 1.2 capable clients. This causes clients
> using Mesa 18.1 to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
> DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx
> do not support the needed hooks like info->pixmap_from_fds or
> info->get_formats, info->get_modifiers. Unfortunately we can't
> simply report the servers DRI3 version as 1.0 in this case, as
> the reported version can not be specific to a X-Screen, and
> different screens may have drivers with different capabilities.

Thanks a lot for hunting this down! This fix does still make me
uncomfortable though. I think a better fix would be, on the Mesa side,
to never call any 1.2 codepaths for the server if we get no
formats/modifiers back from the GetSupported calls, and to never call
any 1.2 codepaths for the drawable if DRIImage's
createImageWithModifiers does not exist or if it fails and we fall
back to regular createImage. That way we make sure that both sides
exercise the same behaviour: either both with explicit modifiers, or
neither.

Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel