Re: [Mesa-dev] [PATCH 3/5] ffvertex: Don't try to read output registers in fog calculation

[Ian Romanick]

On 05/06/2018 05:31 PM, Timothy Arceri wrote:
> On 05/05/18 07:28, Kenneth Graunke wrote:
> 
>> On Thursday, April 26, 2018 2:28:41 PM PDT Ian Romanick wrote:
>>> From: Ian Romanick 
>>>
>>> This code was clearly never tested.  It's a good thing that no driver
>>> ever tried to enable this path.
>>>
>>> Signed-off-by: Ian Romanick 
>>> ---
>>>   src/mesa/main/ffvertex_prog.c | 10 ++
>>>   1 file changed, 6 insertions(+), 4 deletions(-)
>> That's not quite accurate.  Gallium drivers advertise NV_fog_distance,
>> but st_program calls _mesa_remove_output_reads(), which presumably
>> lowers those away.  It looks like none of the classic drivers are
>> calling that, though, so they would be broken if they tried to enable
>> this.  Either your patch, or calling _mesa_remove_output_reads(),
>> would probably solve the issue.
>>
>> At any rate, using a temporary seems reasonable.
> 
> Since this patch landed. Do you guys think we can now remove
> 
> _mesa_remove_output_reads() entirely?

Was this bit of ffvertex the only reason that function existed?  Is it
still needed for ARB assembly vertex programs?

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

[Mesa-dev] [Bug 106315] The witness + dxvk suffers flickering garbage

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106315

Matthew Scheirer  changed:

   What|Removed |Added

 CC||matt.schei...@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103852

--- Comment #18 from Ben Clapp  ---
Bug still present on 18.0.2.
I noticed flickering back and forth between a black screen and the game screen
when resizing the window, so I made a short video demonstrating this:
https://www.youtube.com/watch?v=W2yuR0-z-EU

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] ffvertex: Don't try to read output registers in fog calculation

[Timothy Arceri]

On 05/05/18 07:28, Kenneth Graunke wrote:


On Thursday, April 26, 2018 2:28:41 PM PDT Ian Romanick wrote:

From: Ian Romanick 

This code was clearly never tested.  It's a good thing that no driver
ever tried to enable this path.

Signed-off-by: Ian Romanick 
---
  src/mesa/main/ffvertex_prog.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

That's not quite accurate.  Gallium drivers advertise NV_fog_distance,
but st_program calls _mesa_remove_output_reads(), which presumably
lowers those away.  It looks like none of the classic drivers are
calling that, though, so they would be broken if they tried to enable
this.  Either your patch, or calling _mesa_remove_output_reads(),
would probably solve the issue.

At any rate, using a temporary seems reasonable.


Since this patch landed. Do you guys think we can now remove

_mesa_remove_output_reads() entirely?

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

Re: [Mesa-dev] [PATCH 1/2] mesa: add R10G10B10{A, X}2 to MESA <-> DRI format translations

[Dylan Baker]

On May 4, 2018 5:44:25 PM PDT, Chad Versace  wrote:
>Thanks for the patches. The code looks good. All my suggestions are
>merely nitpicks to make the patches follow Mesa conventions.
>
>In general, if you have questions about commit message style, examine
>the git log for previous patches that touched the same files and
>directories as yours. Sometimes, different directories in Mesa can have
>very different code style as well as commit style.
>
>First, when a patch touches src/mesa/drivers/dri/common and/or
>include/GL/internal/dri_interface.h, and touches nothing else, the
>patch
>subject should probably have the prefix "dri:". For patches that touch
>only dri_util.c, like yours, there is also a precedent for using the
>"dri_util:" prefix.
>
>On Wed 02 May 2018, Miguel Casas wrote:
>> This patch adds R10G10B10{A,X}2 MESA <-> DRI translation entries
>> in the appropriate places for dri2 functions to accept them.
>
>"DRI translation entries in the appropriate places for dri2 functions
>to
>accept them" is quite vague but a lot of text. Dense, precise git logs
>are the best. Please omit the phrase, or replace it with a precise one.
>
>At risk of over-laboring the point, short-and-sweet-and-precise like
>any
>of the following:
>
>  * Add R10G10B10{A,X}2 translation between mesa_format and DRI format.
>
>   * Add R10G10B10{A,X}2 translation between mesa_format and DRI format
>  to driGLFormatToImageFormat() and driImageFormatToGLFormat().
>
>   * Teach driGLFormatToImageFormat() and driImageFormatToGLFormat() to
>  translate __DRI_IMAGE_FORMAT_ABGR2101010 and
>  __DRI_IMAGE_FORMAT_XBGR2101010.
>
>* Teach dri_util.c to translate R10G10B10{A,X}2 between mesa_format
>  and DRI format.
>
>> BUG=https://crbug.com/776093
>> TEST=Compile and deploy mesa+this patch, then playback
>> a VP9 Profile 2 video with sw decoder using crrev.com/c/897894.
>
>The Chromium-specific taglines BUG= and TEST= appear nowhere in the
>Mesa
>git log.
>
>The BUG line should be converted to any of the following trailer lines:
>
>Bug: https://crbug.com/776903
>(This is my favorite).
>Fixes: https://crbug.com/776903
>(But only use Fixes if it fully fixes the bug).

Please only use Fixes: to declare that this patch fixed another patch, as noted 
in the documentation.

>Reference: https://crbug.com/776903
>References: https://crbug.com/776903
>(Some people use singular Reference, others plural. Shrug).
>
>The TEST line doesn't have a clear translation. Some people would
>simply
>add a paragraph to the commit message like this:
>
>Tested by playing a VP9 Profile 2 video with sw
>decoder using foo.
>
>Other people try to put in a trailer line, like below. If you use
>a trailer, then *please* indent wrapped lines with at least two spaces,
>just like RFC 822. Read man:git-interpret-trailers(1) if want to learn
>more about trailers.
>
>Test: Play a VP9 Profile 2 video with sw
>  decoder using foo.
>
>Regardless, in the test description:
>
>* Don't say you built and deployed the patch, *then* ran a test. If
>  you ran the test, then we trust you ran it with the patch applied :-)
>  Dense git log == good.
>
>* For a test like this, it's critical to mention what GPU you
>  used. If you used Eve, then saying "on Kabylake" would be
>  sufficient for this patch.
>
>* How is the VP9 video related to DRI images? Did you import each
>  frame as a dma_buf into a single EGLImage? Into multiple
> EGLImages, one per plane? I don't understand how VP9 is related to
>  this patch without more description.
>
>* Whose software decoder? I don't believe the source of the VP9
>  video is important to this patch. You could probably
>  s/video with sw decoder/video/ without losing significant
>  information. But if you think it's important to mention that the
>  video was sw-decoded, then please tell us what decoder you used.
>
>Woo... that was a lot... Thanks for your first Mesa patch!
>
>> ---
>>  src/mesa/drivers/dri/common/dri_util.c | 8 
>>  1 file changed, 8 insertions(+)
>> 
>> diff --git a/src/mesa/drivers/dri/common/dri_util.c
>b/src/mesa/drivers/dri/common/dri_util.c
>> index 7cb6248b13..78c6bbf234 100644
>> --- a/src/mesa/drivers/dri/common/dri_util.c
>> +++ b/src/mesa/drivers/dri/common/dri_util.c
>> @@ -886,6 +886,10 @@ driGLFormatToImageFormat(mesa_format format)
>>return __DRI_IMAGE_FORMAT_ARGB2101010;
>> case MESA_FORMAT_B10G10R10X2_UNORM:
>>return __DRI_IMAGE_FORMAT_XRGB2101010;
>> +   case MESA_FORMAT_R10G10B10A2_UNORM:
>> +  return __DRI_IMAGE_FORMAT_ABGR2101010;
>> +   case MESA_FORMAT_R10G10B10X2_UNORM:
>> +  return __DRI_IMAGE_FORMAT_XBGR2101010;
>> case MESA_FORMAT_B8G8R8A8_UNORM:
>>return __DRI_IMAGE_FORMAT_ARGB;
>> case MESA_FORMAT_R8G8B8A8_UNORM:
>> @@ -923,6 +927,10 @@ driImageFormatToGLFormat(uint32_t image_format)
>>

Re: [Mesa-dev] [RFC] Fix attempt for Mesa + X-Server 1.20 + modesetting-ddx hangs on KDE5.

[Mario Kleiner]

On Sun, May 6, 2018 at 1:51 PM, Tobias Klausmann
 wrote:
> Hi,
>
> fyi: there is another bugreport #106372 [1], where i bisected the problem in
> the xserver and found a problematic commit, with code which can easily be
> reverted (patch in the bugreport), maybe you could check if that fixes the
> issue as well!

Hi Tobias,

thanks for the info. Yes, that's consistent with the Mesa bug and why
it apparently happens only 1.20 modesetting-ddx - or infrequently
enough on other ddx'en for nobody making a connection.

1. Mesa feeds way too large (way in the future)  >> 2^32 targetMsc's
into the PresentPixmap request, due to the Mesa bug.

2. Other ddx truncate the way too large targetMsc back to < 2^32 when
using the old drmWaitVblank ioctl to queue a vblank event, and due to
the magic of integer 32 bit truncation, most or all of the damage is
undone. Maybe no glitch, or only a hang of a few frames duration, or
only very infrequent long hangs, depending on the exact timing of
client vs. server execution, what and how much drawing plasmashell
does, etc.

3. modesetting-ddx directly queues the too large targetMsc via the new
drmCrtcQueueSequence ioctl if running on Linux 4.15 or later, and the
kernel dutyfully waits forever -> Hang.

I think in Michel's debug patch, only applying the #if 0 for the
ms_queue_vblank() function should be enough for the ddx to work around
the Mesa bug. Fixing client bugs in the server is probably not a good
idea though, given that we know it is a Mesa bug.

I think i found - and hopefully fixed - three other bugs in the
modesetting-ddx vblank handling, but they would only help for other
issues, not this specific one.

thanks,
-mario

>
> PS: I looked into bugzilla last weekend where i bisected this issue and did
> not recheck when opening the actual bugreport (sorry for that)
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=106372
>
> Greetings,
>
> Tobias
>
>
>
> On 5/4/18 3:45 PM, Mario Kleiner wrote:
>>
>> Two patches, solving the same problem in two different ways, the 1st
>> one ready to go, the 2nd one would need the debug statements removed.
>>
>> Only apply one of those for testing, the 2nd one will be useless with
>> the 1st one applied, but demonstrates the problem.
>>
>> So X-Server 1.20 RC + modesetting-ddx with DRI3/Present hangs at least
>> KDE-5's plasmashell and makes KDE-5 unusable with that setup.
>>
>> As KDE's plasmashell uses QT-5's QtQuick OpenGL based rendering api's
>> to render scene-graphs, this bug might affect other QT applications
>> as well.
>>
>> This fix works, but it points to some problems in modesetting-ddx's
>> current vblank handling, because other ddx'en seem to be mostly
>> unaffected by this Mesa bug.
>>
>> The problem is that neither of these two fixes is a proper final
>> solution, but better than nothing. It leaves the OML_sync_control
>> extensions glXWaitForSbcOML(), glXWaitForMscOML() calls and the
>> SGI_video_sync glXWaitVideoSyncSGI() functions broken for some
>> use patterns.
>>
>> The real problem, if i understand it correctly, is the way the life-time
>> of dri3_drawables and loader_dri3_drawables is managed atm. by Mesa's
>> bindContext() functions. Whenever glXMakeCurrent() etc. are called to
>> assign new/different GLXDrawables to the same context (ie. one context
>> reused for drawing into many different drawables, as opposed to using
>> one dedicated context for each drawable), we destroy the underlying
>> DRIDrawables/dri3_drawables_loader_dri3_drawables and they lose all
>> state wrt. pending bufferswaps, msc, sbc, ust.
>>
>> Nothing in the specs says that clients should expect to lose such
>> state on a GLXDrawable d1 whenever they reassign drawables other than
>> d1 to a GL context. A sequence like...
>>
>> 1.glXMakeCurrent(context, drawable1);
>> 2.draw draw draw
>> 3.glXSwapbuffers(context, drawable1);
>> 4.glXMakeCurrent(context, drawable2); // drawable 1 loses all state!
>> 5.glXWaitForSbcOML(dpy, drawable1, ...);
>>
>> ... would probably cause a hang of the client in glXWaitForSbcOML, as
>> the function requires information stored in the "original" drawable1
>> up to step 3, but lost in step 4 due to dri3_drawable destruction.
>>
>> Patch 1 has a potentially large performance impact when switching
>> drawables on a given context, due to the enforced wait on swap completion,
>> but might save OML clients which do waits for sbc,msc on a separate
>> thread,
>> whereas patch 2 doesn't have a performance impact, but doesn't even
>> partially solve trouble with OML_sync_control.
>>
>> However, i'm totally out of time atm. and probably not the right person
>> to think about a better solution, and by dumb luck, my own application
>> doesn't recycle the same context for different drawables, but uses a
>> dedicated context for each drawable, so it dodges this bullet.
>>
>> Therefore one of these patches is either a good enough fix for the KDE
>> hang problems atm. or a diagnosis of the 

[Mesa-dev] [Bug 106420] segfault in dri2_allocate_textures(), radeonsi_dri.so 18.1-rc3 using mpv

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106420

--- Comment #1 from Axel Rohde  ---
Additional system info:
libdrm 2.4.91
Linux debi2 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 GNU/Linux
libva 2.1.0

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106420] segfault in dri2_allocate_textures(), radeonsi_dri.so 18.1-rc3 using mpv

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106420

Bug ID: 106420
   Summary: segfault in dri2_allocate_textures(), radeonsi_dri.so
18.1-rc3 using mpv
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: dr.a.ro...@gmx.de
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 139394
  --> https://bugs.freedesktop.org/attachment.cgi?id=139394=edit
valgrind.log

segfault in dri2_allocate_textures(), radeonsi_dri.so 18.1-rc3 using mpv

Component: Drivers/DRI/radeonsi

System: Debian 10 Buster Intel core i5 3550 with AMD Radeon RX550

 using AMD polaris 12 firmware from firmware linux git 

  mpv build using https://github.com/mpv-player/mpv-build  on 06 May 2018
from master  ===

commit 11289d52389f83edf9358fb3b93bb1bca32dc51c (HEAD -> master, origin/master,
origin/HEAD)
Author: Ricardo Constantino 
Date:   Thu May 3 01:40:24 2018 +0100

ytdl_hook: try to set video track first if available

Fixes
`--ytdl-format="dash-fastly_skyfire-video-363357330+dash-fastly_skyfire_sep-audio-363357330"
https://vimeo.com/108650530`

This happened because the video track also had audio available and after
adding it expecting an audio-only track, there were no more tracks with
video.


=  MESA 18.1-rc3 ==
commit ea1d5faa96e4a6b05e757aea8b88cc01f34b008f (HEAD, tag: mesa-18.1.0-rc3,
origin/18.1)
Author: Dylan Baker 
Date:   Fri May 4 10:57:29 2018 -0700

bump version to 18.1.0-rc3



==  Reproduction of crash:  =

gdb ~/SW/mpv/GIT/mpv/build/mpv 
set args --hwdec=vaapi --vo=gpu --gpu-context=x11egl --profile=opengl-hq
--autofit=100%x100% --geometry=50%:50% --osd-bar-align-y=0.95 --keep-open=yes
empirehd-allied.2016.2160p.x265.mkv
run

Set window to full screen by typing 'f'

Use the mouse to raise and lower the window repetitively (might be bound to
Alt-Mousebutton N)

/var/log/messages:
[18194.879481] mpv/vo[26395]: segfault at 68 ip 7f196346a6c8 sp
7f196a776fa0 error 4 in radeonsi_dri.so[7f1962ffd000+ba3000]
[21590.259743] mpv/vo[31046]: segfault at 18 ip 7f97e86036c8 sp
7f97eb017fa0 error 4 in radeonsi_dri.so[7f97e8196000+ba3000]
[22298.295756] mpv/vo[5716]: segfault at 0 ip 7f86d3466757 sp
7f86e2112e80 error 4 in radeonsi_dri.so[7f86d2ffd000+ba3000]
[22673.181477] mpv/vo[7291]: segfault at 0 ip 7f9088de86c5 sp
7f908b7fcfa0 error 4 in radeonsi_dri.so[7f908897b000+ba3000]
[23358.083394] mpv/vo[7551]: segfault at 10 ip 7f795f46a6c8 sp
7f796e7fdfa0 error 4 in radeonsi_dri.so[7f795effd000+ba3000]
[23386.417366] mpv/vo[7589]: segfault at 18 ip 7f75c58226c8 sp
7f75c7ffdfa0 error 4 in radeonsi_dri.so[7f75c53b5000+ba3000]
[23559.826258] mpv/vo[7651]: segfault at 0 ip 7fa2115e96c5 sp
7fa213ffdfa0 error 4 in radeonsi_dri.so[7fa21117c000+ba3000]


[Thread 0x7fffd7fff700 (LWP 13286) exited]
AV: 00:00:08 / 02:04:35 (0%) A-V:  0.000
Thread 8 "mpv/vo" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe4f45700 (LWP 13285)]
dri2_allocate_textures (ctx=0x7fffd0314770, drawable=0x7fffd039d620,
statts=, statts_count=1) at dri2.c:760
760  dri_drawable->h = texture->height0;
(gdb) bt
#0  dri2_allocate_textures (ctx=0x7fffd0314770, drawable=0x7fffd039d620,
statts=, statts_count=1) at dri2.c:760
#1  0x7fffd64b83fc in dri_st_framebuffer_validate (stctx=,
stfbi=, statts=0x7fffd039f3d0, count=1, out=0x7fffe4f44180) at
dri_drawable.c:85
#2  0x7fffd6316e0e in st_framebuffer_validate
(stfb=stfb@entry=0x7fffd039efa0, st=st@entry=0x7fffd038a7d0) at
state_tracker/st_manager.c:201
#3  0x7fffd631869b in st_manager_validate_framebuffers (st=0x7fffd038a7d0)
at state_tracker/st_manager.c:1117
#4  0x7fffd62d72b5 in st_validate_state (st=st@entry=0x7fffd038a7d0,
pipeline=pipeline@entry=ST_PIPELINE_CLEAR) at state_tracker/st_atom.c:203
#5  0x7fffd62deb9b in st_Clear (ctx=0x7fffd0368e80, mask=2) at
state_tracker/st_cb_clear.c:379
#6  0x557a5edd in gl_clear (ra=, dst=,
color=0x7fffe4f443e0, scissor=0x7fffe4f443b0) at
../video/out/opengl/ra_gl.c:662
#7  0x5579a79f in gl_video_render_frame (p=0x7fffd03dd980,
frame=frame@entry=0x7fffd1370c80, fbo=..., flags=flags@entry=3) at
../video/out/gpu/video.c:3052
#8  0x557aca2b in draw_frame (vo=0x57490f90, frame=0x7fffd1370c80)
at ../video/out/vo_gpu.c:87
#9  0x557aa71a in vo_render_frame_external (vo=vo@entry=0x57490f90)
at ../video/out/vo.c:898
#10 0x557ab018 in vo_thread (ptr=0x57490f90) at
../video/out/vo.c:1055
#11 0x711175aa in start_thread (arg=0x7fffe4f45700) at
pthread_create.c:463
#12 0x70e4ccbf in clone () at

Re: [Mesa-dev] [PATCH] wsi/x11: Don't cal pixmap_from_buffers if modifiers is not supported

[Lionel Landwerlin]

Oops, missed that v2. Still :

Reviewed-by: Lionel Landwerlin 

On 05/05/18 19:11, Jason Ekstrand wrote:

In the prime case, our modifier is always DRM_FORMAT_MOD_LINEAR and we
would end up calling dri3_pixmap_from_buffers on an X server which does
not support it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106180
Fixes: c80c08e226 "vulkan/wsi/x11: Add support for DRI3 v1.2"
---
  src/vulkan/wsi/wsi_common_x11.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
index 3a00cad..29d0e67 100644
--- a/src/vulkan/wsi/wsi_common_x11.c
+++ b/src/vulkan/wsi/wsi_common_x11.c
@@ -1055,10 +1055,8 @@ x11_image_init(VkDevice device_h, struct x11_swapchain 
*chain,
 image->pixmap = xcb_generate_id(chain->conn);
  
  #ifdef HAVE_DRI3_MODIFIERS

-   if (image->base.drm_modifier != DRM_FORMAT_MOD_INVALID) {
-  /* If the image has a modifier, we must have DRI3 v1.2. */
-  assert(chain->has_dri3_modifiers);
-
+   if (chain->has_dri3_modifiers &&
+   image->base.drm_modifier != DRM_FORMAT_MOD_INVALID) {
cookie =
   xcb_dri3_pixmap_from_buffers_checked(chain->conn,
image->pixmap,
@@ -1083,6 +1081,9 @@ x11_image_init(VkDevice device_h, struct x11_swapchain 
*chain,
/* Without passing modifiers, we can't have multi-plane RGB images. */
assert(image->base.num_planes == 1);
  
+  assert(image->base.drm_modifier == DRM_FORMAT_MOD_LINEAR ||

+ image->base.drm_modifier == DRM_FORMAT_MOD_INVALID);
+
cookie =
   xcb_dri3_pixmap_from_buffer_checked(chain->conn,
   image->pixmap,



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

Re: [Mesa-dev] [PATCH] wsi/x11: Don't cal pixmap_from_buffers if modifiers is not supported

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

s/cal/call/ :)

On 05/05/18 19:08, Jason Ekstrand wrote:

In the prime case, our modifier is always DRM_FORMAT_MOD_LINEAR and we
would end up calling dri3_pixmap_from_buffers on an X server which does
not support it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106180
Fixes: c80c08e226 "vulkan/wsi/x11: Add support for DRI3 v1.2"
---
  src/vulkan/wsi/wsi_common_x11.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
index 3a00cad..1c40271 100644
--- a/src/vulkan/wsi/wsi_common_x11.c
+++ b/src/vulkan/wsi/wsi_common_x11.c
@@ -1055,7 +1055,8 @@ x11_image_init(VkDevice device_h, struct x11_swapchain 
*chain,
 image->pixmap = xcb_generate_id(chain->conn);
  
  #ifdef HAVE_DRI3_MODIFIERS

-   if (image->base.drm_modifier != DRM_FORMAT_MOD_INVALID) {
+   if (wsi_conn->has_dri3_modifiers &&
+   image->base.drm_modifier != DRM_FORMAT_MOD_INVALID) {
/* If the image has a modifier, we must have DRI3 v1.2. */
assert(chain->has_dri3_modifiers);
  
@@ -1083,6 +1084,9 @@ x11_image_init(VkDevice device_h, struct x11_swapchain *chain,

/* Without passing modifiers, we can't have multi-plane RGB images. */
assert(image->base.num_planes == 1);
  
+  assert(image->base.drm_modifier == DRM_FORMAT_MOD_LINEAR ||

+ image->base.drm_modifier == DRM_FORMAT_MOD_INVALID);
+
cookie =
   xcb_dri3_pixmap_from_buffer_checked(chain->conn,
   image->pixmap,



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

Re: [Mesa-dev] [PATCH] intel/genxml: Fix a few invalid field widths

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 05/05/18 19:39, Chris Wilson wrote:

A couple of typos found by inspecting field.end - field.start, revealed
a few wide integers declared as bool and some that ended before they
started.

Cc: Lionel Landwerlin 

Re: [Mesa-dev] [PATCH] vulkan/wsi: Only use LINEAR modifier for prime if supported.

[Jason Ekstrand]

Rb

On May 5, 2018 06:35:46 Bas Nieuwenhuizen  wrote:


This was setting the LINEAR modifier if neither the
X server nor the driver supported modifiers.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106180
Fixes: c80c08e226 "vulkan/wsi/x11: Add support for DRI3 v1.2"
CC: 18.1 
CC: Abel Garcia Dorta 
CC: Daniel Stone 
---
src/vulkan/wsi/wsi_common.c | 3 ++-
src/vulkan/wsi/wsi_common_private.h | 1 +
src/vulkan/wsi/wsi_common_x11.c | 3 ++-
3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index fe262b4968d..87e508ddf85 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -442,6 +442,7 @@ fail:
VkResult
wsi_create_prime_image(const struct wsi_swapchain *chain,
   const VkSwapchainCreateInfoKHR *pCreateInfo,
+   bool use_modifier,
   struct wsi_image *image)
{
   const struct wsi_device *wsi = chain->wsi;
@@ -626,7 +627,7 @@ wsi_create_prime_image(const struct wsi_swapchain *chain,
   if (result != VK_SUCCESS)
  goto fail;

-   image->drm_modifier = DRM_FORMAT_MOD_LINEAR;
+   image->drm_modifier = use_modifier ? DRM_FORMAT_MOD_LINEAR : 
DRM_FORMAT_MOD_INVALID;

   image->num_planes = 1;
   image->sizes[0] = linear_size;
   image->row_pitches[0] = linear_stride;
diff --git a/src/vulkan/wsi/wsi_common_private.h 
b/src/vulkan/wsi/wsi_common_private.h

index b608119b969..90941c8201b 100644
--- a/src/vulkan/wsi/wsi_common_private.h
+++ b/src/vulkan/wsi/wsi_common_private.h
@@ -89,6 +89,7 @@ wsi_create_native_image(const struct wsi_swapchain *chain,
VkResult
wsi_create_prime_image(const struct wsi_swapchain *chain,
   const VkSwapchainCreateInfoKHR *pCreateInfo,
+   bool use_modifier,
   struct wsi_image *image);

void
diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
index 3a00caddfb9..62739b99125 100644
--- a/src/vulkan/wsi/wsi_common_x11.c
+++ b/src/vulkan/wsi/wsi_common_x11.c
@@ -1043,7 +1043,8 @@ x11_image_init(VkDevice device_h, struct 
x11_swapchain *chain,

   uint32_t bpp = 32;

   if (chain->base.use_prime_blit) {
-  result = wsi_create_prime_image(>base, pCreateInfo, 
>base);

+  bool use_modifier = num_tranches > 0;
+  result = wsi_create_prime_image(>base, pCreateInfo, 
use_modifier, >base);

   } else {
  result = wsi_create_native_image(>base, pCreateInfo,
   num_tranches, num_modifiers, modifiers,
--
2.17.0

___
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] vulkan/wsi: Only use LINEAR modifier for prime if supported.

[Jason Ekstrand]

On May 6, 2018 05:58:52 Daniel Stone  wrote:


Hi,

On 5 May 2018 at 19:07, Jason Ekstrand  wrote:
On Sat, May 5, 2018 at 6:34 AM, Bas Nieuwenhuizen  
wrote:

@@ -1043,7 +1043,8 @@ x11_image_init(VkDevice device_h, struct
x11_swapchain *chain,
uint32_t bpp = 32;

if (chain->base.use_prime_blit) {
-  result = wsi_create_prime_image(>base, pCreateInfo,
>base);
+  bool use_modifier = num_tranches > 0;
+  result = wsi_create_prime_image(>base, pCreateInfo,
use_modifier, >base);


This confused me for a bit but I think I see what's going on.  You have an X
server which doesn't know about modifiers but mesa is built with modifier
support and prime is in use.  This results in the WSI code calling
dri3_pixmap_from_buffers (plural) on an X server which doesn't support it.

I'm not sure what I think about this way of solving the problem.  In my
twisted mind, DRM_FORMAT_MOD_LINEAR should always be valid even if the
modifier is ultimately ignored.  I'm going to send a counter-patch which
solves it another way but I'm not sure if my solution is better.  Daniel, do
you have any thoughts?


Linear is fairly unique in aliasing a pre-modifier GBM use flag, as
well as something that translates well across all our drivers. That
being said, I prefer Bas's patch for consistency: currently, we
_always_ set INVALID _everywhere_ if one or more components in the
chain are not modifier-aware. I don't really see a reason to diverge
here, especially when we could end up deciding on LINEAR inside the
driver but still setting INVALID for other reasons, e.g. if the user
requests a linear VkTilingMode.


Fair enough.



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

Re: [Mesa-dev] [PATCH] vulkan/wsi: Only use LINEAR modifier for prime if supported.

[Daniel Stone]

Hi,

On 5 May 2018 at 19:07, Jason Ekstrand  wrote:
> On Sat, May 5, 2018 at 6:34 AM, Bas Nieuwenhuizen  
> wrote:
>> @@ -1043,7 +1043,8 @@ x11_image_init(VkDevice device_h, struct
>> x11_swapchain *chain,
>> uint32_t bpp = 32;
>>
>> if (chain->base.use_prime_blit) {
>> -  result = wsi_create_prime_image(>base, pCreateInfo,
>> >base);
>> +  bool use_modifier = num_tranches > 0;
>> +  result = wsi_create_prime_image(>base, pCreateInfo,
>> use_modifier, >base);
>
> This confused me for a bit but I think I see what's going on.  You have an X
> server which doesn't know about modifiers but mesa is built with modifier
> support and prime is in use.  This results in the WSI code calling
> dri3_pixmap_from_buffers (plural) on an X server which doesn't support it.
>
> I'm not sure what I think about this way of solving the problem.  In my
> twisted mind, DRM_FORMAT_MOD_LINEAR should always be valid even if the
> modifier is ultimately ignored.  I'm going to send a counter-patch which
> solves it another way but I'm not sure if my solution is better.  Daniel, do
> you have any thoughts?

Linear is fairly unique in aliasing a pre-modifier GBM use flag, as
well as something that translates well across all our drivers. That
being said, I prefer Bas's patch for consistency: currently, we
_always_ set INVALID _everywhere_ if one or more components in the
chain are not modifier-aware. I don't really see a reason to diverge
here, especially when we could end up deciding on LINEAR inside the
driver but still setting INVALID for other reasons, e.g. if the user
requests a linear VkTilingMode.

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

Re: [Mesa-dev] [RFC] Fix attempt for Mesa + X-Server 1.20 + modesetting-ddx hangs on KDE5.

[Tobias Klausmann]

Hi,

fyi: there is another bugreport #106372 [1], where i bisected the 
problem in the xserver and found a problematic commit, with code which 
can easily be reverted (patch in the bugreport), maybe you could check 
if that fixes the issue as well!


PS: I looked into bugzilla last weekend where i bisected this issue and 
did not recheck when opening the actual bugreport (sorry for that)


[1] https://bugs.freedesktop.org/show_bug.cgi?id=106372

Greetings,

Tobias


On 5/4/18 3:45 PM, Mario Kleiner wrote:

Two patches, solving the same problem in two different ways, the 1st
one ready to go, the 2nd one would need the debug statements removed.

Only apply one of those for testing, the 2nd one will be useless with
the 1st one applied, but demonstrates the problem.

So X-Server 1.20 RC + modesetting-ddx with DRI3/Present hangs at least
KDE-5's plasmashell and makes KDE-5 unusable with that setup.

As KDE's plasmashell uses QT-5's QtQuick OpenGL based rendering api's
to render scene-graphs, this bug might affect other QT applications
as well.

This fix works, but it points to some problems in modesetting-ddx's
current vblank handling, because other ddx'en seem to be mostly
unaffected by this Mesa bug.

The problem is that neither of these two fixes is a proper final
solution, but better than nothing. It leaves the OML_sync_control
extensions glXWaitForSbcOML(), glXWaitForMscOML() calls and the
SGI_video_sync glXWaitVideoSyncSGI() functions broken for some
use patterns.

The real problem, if i understand it correctly, is the way the life-time
of dri3_drawables and loader_dri3_drawables is managed atm. by Mesa's
bindContext() functions. Whenever glXMakeCurrent() etc. are called to
assign new/different GLXDrawables to the same context (ie. one context
reused for drawing into many different drawables, as opposed to using
one dedicated context for each drawable), we destroy the underlying
DRIDrawables/dri3_drawables_loader_dri3_drawables and they lose all
state wrt. pending bufferswaps, msc, sbc, ust.

Nothing in the specs says that clients should expect to lose such
state on a GLXDrawable d1 whenever they reassign drawables other than
d1 to a GL context. A sequence like...

1.glXMakeCurrent(context, drawable1);
2.draw draw draw
3.glXSwapbuffers(context, drawable1);
4.glXMakeCurrent(context, drawable2); // drawable 1 loses all state!
5.glXWaitForSbcOML(dpy, drawable1, ...);

... would probably cause a hang of the client in glXWaitForSbcOML, as
the function requires information stored in the "original" drawable1
up to step 3, but lost in step 4 due to dri3_drawable destruction.

Patch 1 has a potentially large performance impact when switching
drawables on a given context, due to the enforced wait on swap completion,
but might save OML clients which do waits for sbc,msc on a separate thread,
whereas patch 2 doesn't have a performance impact, but doesn't even
partially solve trouble with OML_sync_control.

However, i'm totally out of time atm. and probably not the right person
to think about a better solution, and by dumb luck, my own application
doesn't recycle the same context for different drawables, but uses a
dedicated context for each drawable, so it dodges this bullet.

Therefore one of these patches is either a good enough fix for the KDE
hang problems atm. or a diagnosis of the problem as a starting point for
brighter people to deal with the root cause ;-)

Thanks,
-mario

___
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

[Mesa-dev] [PATCH] mesa/formatquery: remove online compression check on is_resource_supported

[Alejandro Piñeiro]

is_resource_supported returns if the combination of
target/internalformat is supported in at least one operation. Online
compression is only mandatory for glTexImage2D. Some formats doesn't
support online compression, but can be used in any case, with
glCompressed*D methods.

Without this commit, ETC2 internalformats were returning FALSE, even
for the drivers supporting it. So any other query (like
TEXTURE_COMPRESSED) was returning FALSE/NONE instead of the proper
value.
---

This was not detected until now because most of the formats that
doesn't support online compression were added with
GL_ARB_ES3_compatibility, that was not core until 4.3. The base for
GL_ARB_internalformat_query2 is 4.2, and the piglit tests were based
on it.

When we tried to test those formats on piglit (I'm sending a series
soon) we found that they were found as not supported, even if they can
be used with CompressedTexture*D.

Note to Eleni: all this was mentioned on a review of some of your
patches, specifically in relation to TEXTURE_COMPRESSED. The issue is
that without this patch, all the queries with those internalformats
were affected, not only TEXTURE_COMPRESSED. If the specific value for
TEXTURE_COMPRESSED needs to be different (example: the current one),
would be as part of a different patch for that specific query.


 src/mesa/main/formatquery.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/mesa/main/formatquery.c b/src/mesa/main/formatquery.c
index 3b000fac5c4..84b5f512ba5 100644
--- a/src/mesa/main/formatquery.c
+++ b/src/mesa/main/formatquery.c
@@ -501,8 +501,7 @@ _is_resource_supported(struct gl_context *ctx, GLenum 
target,
 
   /* additional checks for compressed textures */
   if (_mesa_is_compressed_format(ctx, internalformat) &&
-  (!_mesa_target_can_be_compressed(ctx, target, internalformat, NULL) 
||
-   _mesa_format_no_online_compression(internalformat)))
+  !_mesa_target_can_be_compressed(ctx, target, internalformat, NULL))
  return false;
 
   break;
-- 
2.14.1

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

Re: [Mesa-dev] [RFC PATCH] mesa/st/cb_clear: in st_Clear also validate the render state (needed by virgl)

[Gert Wollny]

Dear Ilia, 

it took me a while but I think I understand now, thanks for all your
explanations. 


Am Freitag, den 04.05.2018, 18:11 -0400 schrieb Ilia Mirkin:
> 
> Rasterizer state doesn't affect the gallium clear callback. clear
> just clears -- it's a memset. However rasterizer state affects
> glClear() so  you have to make sure to keep that in mind when you try
> to implement clear() with glClear() (i.e. turn off whatever GL state
> the rasterizer may have set which would cause you issues).
I think my error was that I looked at st_Clear, which does indeed
handle all the relevant rasterization states, but because they are
handled directly there they don't need extra validation, something that
is only required for virgl, in other words what I really would want is
a replacement for st_Clear that would forward the state changes to
virgl and then call some other function glclear that sends the clear
mask to virglrenderer where everything is passed to and processed in
the host st_Clear anyway. Obviously gallium was not designed for this. 

> If you want, you could construct a temporary rasterizer state, bind
> that, do the glClear() and then bind the old one back.
This is what I now implemented in virgl, and it fixes all the tests I
was looking at. Performance wise it is not exactly nice, because it
adds two state changes, but so is the whole clear operation, and to
improve this situation one has to look beyond the current gallium
implementation. 

Thanks again, 
Gert


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