Canceled event: XDC 2023 A Corunha Spain @ Tue Oct 17 - Thu Oct 19, 2023 (mesa-dev@lists.freedesktop.org)

[mario . kleiner . de]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VEVENT
DTSTART;VALUE=DATE:20231017
DTEND;VALUE=DATE:20231020
DTSTAMP:20230417T170848Z
ORGANIZER;CN=mario.kleiner...@gmail.com:mailto:mario.kleiner...@gmail.com
UID:65qeuuc9e0gll25tq5r7e61...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=et
 na...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:etnaviv@lists.freedesktop
 .org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=xo
 rg-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:xorg-devel@lists.freed
 esktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=am
 d-gfx list;X-NUM-GUESTS=0:mailto:amd-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=in
 tel-gfx;X-NUM-GUESTS=0:mailto:intel-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=No
 uveau Dev;X-NUM-GUESTS=0:mailto:nouv...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=mario.
 kleiner...@gmail.com;X-NUM-GUESTS=0:mailto:mario.kleiner...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=bo
 a...@foundation.x.org;X-NUM-GUESTS=0:mailto:bo...@foundation.x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=li
 bre-soc-...@lists.libre-soc.org;X-NUM-GUESTS=0:mailto:libre-soc-dev@lists.l
 ibre-soc.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ML
  mesa-dev;X-NUM-GUESTS=0:mailto:mesa-dev@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=me
 mb...@x.org;X-NUM-GUESTS=0:mailto:memb...@x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=fr
 eedr...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:freedreno@lists.freedes
 ktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=dr
 oidbit...@gmail.com;X-NUM-GUESTS=0:mailto:droidbit...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=wa
 yland-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:wayland-devel@lists
 .freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=dr
 i-devel;X-NUM-GUESTS=0:mailto:dri-de...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=si
 gles...@igalia.com;X-NUM-GUESTS=0:mailto:sigles...@igalia.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ev
 e...@lists.x.org;X-NUM-GUESTS=0:mailto:eve...@lists.x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-NUM
 -GUESTS=0:mailto:bibby.hs...@mediatek.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN="G
 arg, Rohan";X-NUM-GUESTS=0:mailto:rohan.g...@intel.com
X-GOOGLE-CONFERENCE:https://meet.google.com/azn-uwfp-pgw
CREATED:20230417T170310Z
DESCRIPTION:Hello!\n \nRegistration & Call for Proposals are now open for X
 DC 2023\, which will\ntake place on October 17-19\, 2023.\n\nhttps://xdc202
 3.x.org\n \nAs usual\, the conference is free of charge and open to the gen
 eral\npublic. If you plan on attending\, please make sure to register as ea
 rly\nas possible!\n \nIn order to register as attendee\, you will therefore
  need to register\nvia the XDC website.\n \nhttps://indico.freedesktop.org/
 event/4/registrations/\n \nIn addition to registration\, the CfP is now ope
 n for talks\, workshops\nand demos at XDC 2023. While ...\n\n-::~:~::~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\n
 Join with Google Meet: https://meet.google.com/azn-uwfp-pgw\n\nLearn more a
 bout Meet at: https://support.google.com/a/users/answer/9282720\n\nPlease d
 o not edit this section.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20230417T170847Z
LOCATION:
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:XDC 2023 A Corunha Spain
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Invitation: XDC 2023 A Corunha Spain @ Tue Oct 17 - Thu Oct 19, 2023 (mesa-dev@lists.freedesktop.org)

[mario . kleiner . de]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART;VALUE=DATE:20231017
DTEND;VALUE=DATE:20231020
DTSTAMP:20230417T170311Z
ORGANIZER;CN=mario.kleiner...@gmail.com:mailto:mario.kleiner...@gmail.com
UID:65qeuuc9e0gll25tq5r7e61...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=etna...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:etnaviv@lists.f
 reedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=xorg-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:xorg-devel@l
 ists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=amd-gfx list;X-NUM-GUESTS=0:mailto:amd-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=intel-gfx;X-NUM-GUESTS=0:mailto:intel-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Nouveau Dev;X-NUM-GUESTS=0:mailto:nouv...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=mario.kleiner...@gmail.com;X-NUM-GUESTS=0:mailto:mario.kleiner.de@gmail
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=bo...@foundation.x.org;X-NUM-GUESTS=0:mailto:bo...@foundation.x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=libre-soc-...@lists.libre-soc.org;X-NUM-GUESTS=0:mailto:libre-soc-d
 e...@lists.libre-soc.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=ML mesa-dev;X-NUM-GUESTS=0:mailto:mesa-dev@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=memb...@x.org;X-NUM-GUESTS=0:mailto:memb...@x.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=freedr...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:freedreno@lis
 ts.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=droidbit...@gmail.com;X-NUM-GUESTS=0:mailto:droidbit...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=wayland-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:wayland-d
 e...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=dri-devel;X-NUM-GUESTS=0:mailto:dri-de...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=sigles...@igalia.com;X-NUM-GUESTS=0:mailto:sigles...@igalia.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=eve...@lists.x.org;X-NUM-GUESTS=0:mailto:eve...@lists.x.org
X-GOOGLE-CONFERENCE:https://meet.google.com/azn-uwfp-pgw
X-MICROSOFT-CDO-OWNERAPPTID:1992648111
CREATED:20230417T170310Z
DESCRIPTION:Hello!\n \nRegistration & Call for Proposals are now open for X
 DC 2023\, which will\ntake place on October 17-19\, 2023.\n\nhttps://xdc202
 3.x.org\n \nAs usual\, the conference is free of charge and open to the gen
 eral\npublic. If you plan on attending\, please make sure to register as ea
 rly\nas possible!\n \nIn order to register as attendee\, you will therefore
  need to register\nvia the XDC website.\n \nhttps://indico.freedesktop.org/
 event/4/registrations/\n \nIn addition to registration\, the CfP is now ope
 n for talks\, workshops\nand demos at XDC 2023. While ...\n\n-::~:~::~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\n
 Join with Google Meet: https://meet.google.com/azn-uwfp-pgw\n\nLearn more a
 bout Meet at: https://support.google.com/a/users/answer/9282720\n\nPlease d
 o not edit this section.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20230417T170310Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:XDC 2023 A Corunha Spain
TRANSP:TRANSPARENT
BEGIN:VALARM
ACTION:EMAIL
DESCRIPTION:This is an event reminder
SUMMARY:Alarm notification
ATTENDEE:mailto:mesa-dev@lists.freedesktop.org
TRIGGER:-P0DT0H30M0S
END:VALARM
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P0DT0H30M0S
END:VALARM
BEGIN:VALARM
ACTION:EMAIL
DESCRIPTION:This is an event reminder
SUMMARY:Alarm notification
ATTENDEE:mailto:mesa-dev@lists.freedesktop.org
TRIGGER:-P0DT7H30M0S
END:VALARM
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: Headless OpenGL Rendering using SSH and X11 forwarding

[Mario Kleiner]

I think this might be because indirect GLX support is disabled by default
on X-Servers shipping in Ubuntu, so if your remotely executing client tries
to use your local X-Server over the network via the x forwarding, it will
fail. I guess without x forwarding Mesa just renders locally on the remote
machine with a software renderer. See "man xorg.conf", the section about
Option "IndirectGLX" "boolean".


On Wed, Mar 8, 2023 at 2:17 AM Richard Haney  wrote:

> Please help,
>
> I have been going around and around with this problem but cannot seem to
> make any headway. I hope that one of you OpenGL EGL experts can help. [image:
> :slight_smile:]
>
> I have created a program that uses OpenGL EGL (version 1.5) with OpenGL 3
> that successfully renders an offscreen triangle and saves it to an image
> file (PNG) when I ssh *without* X11 forwarding on my Linux (Ubuntu 22.04)
> machine.
>
> However when I try the same thing using ssh *with* X11 forwarding enabled
> I get the following EGL error when I call eglInitialize(…): 12290 (I
> *think* is EGL_BAD_ACCESS).
>
> This seems really weird and I hope it is something simple that I am just
> not currently seeing.
>
> I really like using OpenGL with EGL but need a way to remedy this
> situation if possible. Is there a way for EGL to determine if X11
> forwarding is being employed and to ignore it or some other solution?
>
> The snippet of relevant C++ code follows, with area where error occurs
> marked:
>
> #include  #include  #include  #define
> EGL_EGLEXT_PROTOTYPES #define GL_GLEXT_PROTOTYPES #include 
> #include  ... EGLDisplay display = 
> eglGetDisplay(EGL_DEFAULT_DISPLAY);
> if(display == EGL_NO_DISPLAY) { std::cerr << "Failed to get EGL display: "
> << eglGetError() << std::endl; exit(EXIT_FAILURE); } EGLint major; EGLint
> minor; if(eglInitialize(display, , ) == EGL_FALSE) { // ERROR
> 12290 is generated here std::cerr << "Failed to initialize EGL: " <<
> eglGetError() << std::endl; exit(EXIT_FAILURE); } ...
>
>
> Any help would be greatly appreciated.
>

[Mesa-dev] [PATCH] vulkan/wsi: Really terminate DRM lease in wsi_release_display().

[Mario Kleiner]

wsi_release_display() implements vkReleaseDisplayEXT() which
is supposed to return control to the lessor of an output
upon call.

We need to terminate the wsi->wait_thread when close()'ing
the wsi->fd, otherwise the wait_thread holds another reference
to the wsi->fd, keeping the lease active, and thereby the
leased output blocked, until vkDestroyInstance() is called.

This gives users their GUI back, instead of extended darkness.

Signed-off-by: Mario Kleiner 
---
 src/vulkan/wsi/wsi_common_display.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/src/vulkan/wsi/wsi_common_display.c 
b/src/vulkan/wsi/wsi_common_display.c
index 0f9a1ffe8d3..b05d7cc479d 100644
--- a/src/vulkan/wsi/wsi_common_display.c
+++ b/src/vulkan/wsi/wsi_common_display.c
@@ -1228,6 +1228,18 @@ wsi_display_start_wait_thread(struct wsi_display *wsi)
return 0;
 }
 
+static void
+wsi_display_stop_wait_thread(struct wsi_display *wsi)
+{
+   pthread_mutex_lock(>wait_mutex);
+   if (wsi->wait_thread) {
+  pthread_cancel(wsi->wait_thread);
+  pthread_join(wsi->wait_thread, NULL);
+  wsi->wait_thread = 0;
+   }
+   pthread_mutex_unlock(>wait_mutex);
+}
+
 /*
  * Wait for at least one event from the kernel to be processed.
  * Call with wait_mutex held
@@ -1936,12 +1948,7 @@ wsi_display_finish_wsi(struct wsi_device *wsi_device,
  vk_free(wsi->alloc, connector);
   }
 
-  pthread_mutex_lock(>wait_mutex);
-  if (wsi->wait_thread) {
- pthread_cancel(wsi->wait_thread);
- pthread_join(wsi->wait_thread, NULL);
-  }
-  pthread_mutex_unlock(>wait_mutex);
+  wsi_display_stop_wait_thread(wsi);
   pthread_mutex_destroy(>wait_mutex);
   pthread_cond_destroy(>wait_cond);
 
@@ -1961,9 +1968,12 @@ wsi_release_display(VkPhysicalDevice
physical_device,
   (struct wsi_display *) wsi_device->wsi[VK_ICD_WSI_PLATFORM_DISPLAY];
 
if (wsi->fd >= 0) {
+  wsi_display_stop_wait_thread(wsi);
+
   close(wsi->fd);
   wsi->fd = -1;
}
+
 #ifdef VK_USE_PLATFORM_XLIB_XRANDR_EXT
wsi_display_connector_from_handle(display)->output = None;
 #endif
-- 
2.25.1

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

[Mesa-dev] [PATCH] drirc: Add sddm-greeter to adaptive_sync blacklist.

[Mario Kleiner]

This is the sddm login screen.

Fixes: a9c36dbf9c56 ("drirc: Initial blacklist for adaptive sync")
Signed-off-by: Mario Kleiner 
Cc: 19.0 
---
 src/util/00-mesa-defaults.conf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf
index cb0e6e659e2..43fe95b8810 100644
--- a/src/util/00-mesa-defaults.conf
+++ b/src/util/00-mesa-defaults.conf
@@ -346,6 +346,9 @@ TODO: document the other workarounds.
 
 
 
+
+
+
 
 
 
-- 
2.17.1

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

Re: [Mesa-dev] Fwd: Review for last remaining Mesa wayland-drm depth 30 bits?

[Mario Kleiner]

Thanks for the quick review!

Patchwork didn't pick the r-b's up though. Do i need to do anything /
ping somebody to get those merged to master ideally before the close
19.0 branchpoint and not overlooked?

thanks,
-mario

On Tue, Jan 29, 2019 at 5:13 PM Daniel Stone  wrote:
>
> Hi,
>
> On Tue, 29 Jan 2019 at 16:05, Adam Jackson  wrote:
> > On Tue, 2019-01-29 at 14:45 +0100, Mario Kleiner wrote:
> > > could i get some review of the last two missing patches of mine for
> > > depth 30 support in Mesa's egl/wayland wl-drm backend? They are over
> > > six months old now, well-tested at time of original submission:
> > >
> > > https://patchwork.freedesktop.org/project/mesa/list/?submitter=14956
> > >
> > > Would be good to get this into Mesa 19 before new color formats are
> > > added. Should be useful for new formats as well.
> >
> > 4 and 5 are:
> >
> > Reviewed-by: Adam Jackson 
>
> And they are also:
> Reviewed-by: Daniel Stone 
>
> Thanks for chasing this up!
>
> Cheers,
> Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Fwd: Review for last remaining Mesa wayland-drm depth 30 bits?

[Mario Kleiner]

Hi,

could i get some review of the last two missing patches of mine for
depth 30 support in Mesa's egl/wayland wl-drm backend? They are over
six months old now, well-tested at time of original submission:

https://patchwork.freedesktop.org/project/mesa/list/?submitter=14956

Would be good to get this into Mesa 19 before new color formats are
added. Should be useful for new formats as well.

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

[Mesa-dev] [PATCH] radeonsi: Fix use of 1- or 2- component GL_DOUBLE vbo's.

[Mario Kleiner]

With Mesa 18.1, commit be973ed21f6e, si_llvm_load_input_vs()
changed the number of source 32-bit wide dword components
used for fetching vertex attributes into the vertex shader
from a constant 4 to a variable num_channels number, depending
on input data format, with some special case handling for
input data formats like 64-Bit doubles.

In the case of a GL_DOUBLE input data format with one
or two components though, e.g, submitted via ...

a) glTexCoordPointer(1, GL_DOUBLE, 0, buffer);
b) glTexCoordPointer(2, GL_DOUBLE, 0, buffer);

... the input format would be SI_FIX_FETCH_RG_64_FLOAT,
but no special case handling was implemented for that
case, so in the default path the number of 32-bit
dwords would be set to the number of float input components
derived from info->input_usage_mask. This ends with corrupted
input to the vertex shader, because fetching a 64-bit double
from the vbo requires fetching two 32-bit dwords instead of 1,
and fetching a two double input requires 4 dword fetches
instead of 2, so in these cases the vertex shader receives
incomplete/truncated input data:

a) float v = gl_MultiTexCoord0.x;  -> v.x is corrupted.
b) vec2  v = gl_MultiTexCoord0.xy; -> v.x is assigned
   correctly, but v.y is corrupted.

This happens with the standard TGSI IR compiled shaders.
Under NIR with R600_DEBUG=nir, we got correct behavior
because the current radeonsi nir code always assigns
info->input_usage_mask = TGSI_WRITEMASK_XYZW, thereby
always fetches 4 dwords regardless of what the shader
actually needs.

Fix this by properly assigning 2 or 4 dword fetches for
one or two component GL_DOUBLE input.

Fixes: be973ed21f6e ("radeonsi: load the right number of
   components for VS inputs and TBOs")

Signed-off-by: Mario Kleiner 
Cc: mesa-sta...@lists.freedesktop.org
Cc: Marek Olšák 
---
 src/gallium/drivers/radeonsi/si_shader.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 190edce..14bb875 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -561,6 +561,14 @@ void si_llvm_load_input_vs(
 
/* Do multiple loads for special formats. */
switch (fix_fetch) {
+   case SI_FIX_FETCH_RG_64_FLOAT:
+   num_fetches = 1; /* 1 2-dword or 4-dword load */
+   fetch_stride = 0;
+   if (util_last_bit(info->input_usage_mask[input_index]) >= 2)
+   num_channels = 4; /* 2 doubles in 4 dwords */
+   else
+   num_channels = 2; /* 1 double in 2 dwords */
+   break;
case SI_FIX_FETCH_RGB_64_FLOAT:
num_fetches = 3; /* 3 2-dword loads */
fetch_stride = 8;
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] i965/screen: MOD_FORMAT_Y_TILED is only supported by gen9+

[Mario Kleiner]

Ok, we have a diagnosis of the real issue, thanks Jason. With that i
leave dealing with it to the experts. If some testing or light review
of the proper solution is needed on the modesetting-ddx side, happy to
do that.

-mario



On Tue, Jul 31, 2018 at 6:01 PM, Jason Ekstrand  wrote:
> NAK.
>
> On SNB+, we'd like to get Y-tiling when the surface is only being used by
> the compositor and reserve X-tiling for scanout surfaces.  With the
> modifiers negotiation framework, the X server should be able to figure out
> that the window is being composited (or blitted) and request Y-tiling.  If
> the surface is full-screen, it should know this and either require X-tiling
> because that's all KMS advertises or not flip the buffer because it uses a
> modifier that's unsupported by the kernel.  I think you have an X server
> bug.
>
> --Jason
>
> On Tue, Jul 31, 2018 at 7:54 AM Mario Kleiner 
> wrote:
>>
>> At least that's what the Linux 4.18 i915 drm/kms driver
>> thinks, and the disagreement between kms and Mesa leads to
>> pageflipping failure with X-Server 1.20's dmabuf modifiers
>> enabled modesetting-ddx, at least as tested on a gen 7
>> Ivybridge system.
>>
>> Signed-off-by: Mario Kleiner 
>> ---
>>  src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
>> b/src/mesa/drivers/dri/i965/intel_screen.c
>> index cb35741..ef04ffb 100644
>> --- a/src/mesa/drivers/dri/i965/intel_screen.c
>> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
>> @@ -309,7 +309,7 @@ static const struct {
>>  } supported_modifiers[] = {
>> { .modifier = DRM_FORMAT_MOD_LINEAR   , .since_gen = 1 },
>> { .modifier = I915_FORMAT_MOD_X_TILED , .since_gen = 1 },
>> -   { .modifier = I915_FORMAT_MOD_Y_TILED , .since_gen = 6 },
>> +   { .modifier = I915_FORMAT_MOD_Y_TILED , .since_gen = 9 },
>> { .modifier = I915_FORMAT_MOD_Y_TILED_CCS , .since_gen = 9 },
>>  };
>>
>> --
>> 2.7.4
>>
>> ___
>> 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] i965/screen: MOD_FORMAT_Y_TILED is only supported by gen9+

[Mario Kleiner]

At least that's what the Linux 4.18 i915 drm/kms driver
thinks, and the disagreement between kms and Mesa leads to
pageflipping failure with X-Server 1.20's dmabuf modifiers
enabled modesetting-ddx, at least as tested on a gen 7
Ivybridge system.

Signed-off-by: Mario Kleiner 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index cb35741..ef04ffb 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -309,7 +309,7 @@ static const struct {
 } supported_modifiers[] = {
{ .modifier = DRM_FORMAT_MOD_LINEAR   , .since_gen = 1 },
{ .modifier = I915_FORMAT_MOD_X_TILED , .since_gen = 1 },
-   { .modifier = I915_FORMAT_MOD_Y_TILED , .since_gen = 6 },
+   { .modifier = I915_FORMAT_MOD_Y_TILED , .since_gen = 9 },
{ .modifier = I915_FORMAT_MOD_Y_TILED_CCS , .since_gen = 9 },
 };
 
-- 
2.7.4

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

Re: [Mesa-dev] Mesa 18.2.0 release plan

[Mario Kleiner]

On Tue, Jul 31, 2018 at 2:35 PM, Andres Gomez  wrote:
> Hi Mario,

Hi Andres,

>
> Given the current patches and the talk I had yesterday in IRC with
> Daniel and Eric it seems best case scenario is that we could only have
> the 3 first patches from:
> https://patchwork.freedesktop.org/series/44671/
>

I'll take what i can get ;-), thanks!

> Landing before branching point. Not the 4/5 and 5/5 nor, it seems:

Given that 3/5 is ok, and 229397 is exactly the same mechanism, just
applied to the dri3 buffer sharing instead of eglCreateImage, maybe it
would be possible to still get that one in? It would finish at least
the native X11 side of "Optimus" on nouveau? And make nouveau depth 30
somewhat usable on server 1.20's modesetting ddx. In terms of
immediate usefulness for nouveau, that's the favorite patch. If there
aren't fundamental problems with that one, but style issues or such, i
could send some cleanup patch after the branch-point, if that helps?

> https://patchwork.freedesktop.org/patch/229397/
>
> I could delay for a bit the branching but it seems like these patches
> are going to need some more time so I think I will keep the schedule as
> it is.

Holding up the schedule is not worth it, i agree. But i'd need to know
what is missing with the current patch set, if they need more time? I
didn't get any new feedback to the last revision in 1.5 months, and i
know it works well on all relevant hardware combos as far as my
testing with weston and x11 goes, so if there's something i would need
to change, somebody has to tell me. Or is it just lack of independent
testing or time for someone to review atm.?

There's also this weston branch i used for testing: None of the new
deptth 30 patches there have been submitted to wayland ml yet, that
would be a tbd. once mesa is done:

https://github.com/kleinerm/weston/commits/westonnew10bpc

>
> Let me know if I can do something else.

Actually, another unrelated thing that got stalled on my side the last
days, sorry. X-Server 1.20 + modesetting-ddx + dmabuf_modifier support
(enabled by default now iirc) causes pageflipping to fail on at least
Intel Ivybridge (gen 7 hw), whereas it works with the intel-ddx, and
on older (gen 5 ironlake) hardware.

There is a disagreement between Mesa's i965 intel dri driver and the
Linux i915 kms driver about which hardware gen supports
I915_FORMAT_MOD_Y_TILED, causing the kernel to reject the flip. Kernel
thinks gen >= 9, Mesa thinks gen >=6. I'll send out a patch now which
would fix Mesa on current kernels up to 4.18, but haven't looked if
Mesa is wrong or the kms driver is wrong. So this trivial patch would
be worthwile to include if this is indeed Mesa in the wrong.

thanks,
-mario

>
> Br.
>
> PS: If you would like to talk directly to me, I hang out at freenode's
> IRC as "tanty". You can find me in the #dri-devel room, for example.
>
> On Thu, 2018-07-26 at 16:42 +0200, Mario Kleiner wrote:
>> Hello Andreas,
>>
>> the improved color depth 30 rendering support for nouveau is imho
>> ready for merging since about a month:
>>
>> https://patchwork.freedesktop.org/project/mesa/patches/?submitter=14956
>>
>> The patch series submitted at 2018-06-13, and the single patch
>> "loader_dri3: Handle mismatched depth 30 formats for Prime
>> renderoffload." from 2018-06-04.
>>
>> All patches have been successfully tested by myself on various
>> permuations of intel/amd/nvidia hardware and prime combo's of
>> intel+nvidia, amd+nvidia and nvidia+amd under wayland-weston and x11.
>> All review comments have been addressed.
>>
>> Patch [4/5] egl/wayland: Allow client->server format conversion for
>> PRIME offload. (v2)
>> and
>> Patch [5/5] egl/wayland-drm: Only announce formats via wl_drm which
>> the driver supports.
>> and
>> Patch loader_dri3: Handle mismatched depth 30 formats for Prime 
>> renderoffload.
>>
>> still need r-b's, although 4/5 got some review from Eric Engestroem,
>> but no r-b tag so far.
>>
>> The remaining patches should be straightforward to review, and the
>> loader_dri3 patch is essentially the same as the already reviewed
>> [3/5], just applied to x11+prime instead of x11+eglCreateImage().
>> Cc'ing some people who are somewhat familiar with the patches already.
>>
>> It would be good to get these merged for 18.2 before some changes in
>> Mesa break them again, given that they involve a lot of time intense
>> manual and tedious testing on lots of combos whenever i need to touch
>> them again. Also, more work to do on the x-server, weston, side, but
>> that needs a new baseline in Mesa before it makes sense for me to pile
>> on more work.
>>
>> Thanks,
>> -

Re: [Mesa-dev] Mesa 18.2.0 release plan

[Mario Kleiner]

Hello Andreas,

the improved color depth 30 rendering support for nouveau is imho
ready for merging since about a month:

https://patchwork.freedesktop.org/project/mesa/patches/?submitter=14956

The patch series submitted at 2018-06-13, and the single patch
"loader_dri3: Handle mismatched depth 30 formats for Prime
renderoffload." from 2018-06-04.

All patches have been successfully tested by myself on various
permuations of intel/amd/nvidia hardware and prime combo's of
intel+nvidia, amd+nvidia and nvidia+amd under wayland-weston and x11.
All review comments have been addressed.

Patch [4/5] egl/wayland: Allow client->server format conversion for
PRIME offload. (v2)
and
Patch [5/5] egl/wayland-drm: Only announce formats via wl_drm which
the driver supports.
and
Patch loader_dri3: Handle mismatched depth 30 formats for Prime renderoffload.

still need r-b's, although 4/5 got some review from Eric Engestroem,
but no r-b tag so far.

The remaining patches should be straightforward to review, and the
loader_dri3 patch is essentially the same as the already reviewed
[3/5], just applied to x11+prime instead of x11+eglCreateImage().
Cc'ing some people who are somewhat familiar with the patches already.

It would be good to get these merged for 18.2 before some changes in
Mesa break them again, given that they involve a lot of time intense
manual and tedious testing on lots of combos whenever i need to touch
them again. Also, more work to do on the x-server, weston, side, but
that needs a new baseline in Mesa before it makes sense for me to pile
on more work.

Thanks,
-mario




On Wed, Jul 18, 2018 at 12:55 AM, Andres Gomez  wrote:
> Hi all,
>
> Here is the tentative release plan for 18.2.0.
>
> Although the initial plan was to have the first release candidate by
> the end of this week, a slip of mind in my side on sending this plan is
> shifting the current schedule at mesa3d.org. We'll update the release
> schedule there soon.
>
>  Aug 01 2018 - Feature freeze/Release candidate 1
>  Aug 08 2018 - Release candidate 2
>  Aug 15 2018 - Release candidate 3
>  Aug 22 2018 - Release candidate 4/final release
>
> This gives us approximately two weeks until the branch point.
>
> Note: In the spririt of keeping things clearer and more transparent, we
> will be keeping track of any features planned for the release in
> Bugzilla [1].
>
> Do add a separate "Depends on" for each work you have planned.
> Alternatively you can reply to this email and I'll add them for you.
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=106156
>
> --
> Br,
>
> Andres
> ___
> 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] loader_dri3: Handle mismatched depth 30 formats for Prime renderoffload.

[Mario Kleiner]

Ping. One more loose patch following the same logic/principle as the
x11+egl patch for nouveau depth 30, that would benefit from a r-b and
ideally make it into Mesa 18.2. to clear out nouveau depth 30 support.

Obsessively tested by now by myself on intel, amd, nouveau and
dri3/present with prime renderoffload for intel+nouveau, amd+nouveau
and nouveau+amd, on native x11 with the patched nouveau-ddx and
server-1.20 modesetting-ddx. It makes many things better, but nothing
worse, as far as my testing goes.

It would be great to get this merged for Mesa 18.2. Can i bribe
somebody into this, in exchange for a beer on xdc2018, assuming i
manage to make it there?

thanks,
-mario

On Thu, Jun 14, 2018 at 6:04 AM, Mario Kleiner
 wrote:
> Detect if the display (X-Server) gpu and Prime renderoffload gpu prefer
> different channel ordering for color depth 30 formats ([X/A]BGR2101010
> vs. [X/A]RGB2101010) and perform format conversion during the blitImage()
> detiling op from tiled backbuffer -> linear buffer.
>
> For this we need to find the visual (= red channel mask) for the
> X-Drawable used to display on the server gpu. We use the same proven
> logic for finding that visual as in commit "egl/x11: Handle both depth
> 30 formats for eglCreateImage()".
>
> This is mostly to allow "NVidia Optimus" at depth 30, as Intel/AMD
> gpu's prefer xRGB2101010 ordering, whereas NVidia gpu's prefer
> xBGR2101010 ordering, so we can offload to nouveau without getting
> funky colors.
>
> Tested on Intel single gpu, NVidia single gpu, Intel + NVidia prime
> offload with DRI3/Present.
>
> Note: An unintended but pleasant surprise of this patch is that it also
> seems to make the modesetting-ddx of server 1.20.0 work at depth 30
> on nouveau, at least with unredirected "classic" X rendering, and
> with redirected desktop compositing under XRender accel, and with OpenGL
> compositing under GLX. Only X11 compositing via OpenGL + EGL still gives
> funky colors. modesetting-ddx + glamor are not yet ready to deal with
> nouveau's ABGR2101010 format, and treat it as ARGB2101010, also exposing
> X-visuals with ARGB2101010 style channel masks. Seems somehow this triggers
> the logic in this patch on modesetting-ddx + depth 30 + DRI3 buffer sharing
> and does the "wrong" channel swizzling that then cancels out the "wrong"
> swizzling of glamor and we end up with the proper pixel formatting in
> the scanout buffer :). This so far tested on a NVA5 Tesla card under KDE5
> Plasma as shipping with Ubuntu 16.04.4 LTS.
>
> Signed-off-by: Mario Kleiner 
> Cc: Ilia Mirkin 
> Cc: Eric Engestrom 
> ---
>  src/loader/loader_dri3_helper.c | 83 -
>  src/loader/loader_dri3_helper.h |  1 +
>  2 files changed, 83 insertions(+), 1 deletion(-)
>
> diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
> index f0ff2f07bd..a9a18921ce 100644
> --- a/src/loader/loader_dri3_helper.c
> +++ b/src/loader/loader_dri3_helper.c
> @@ -64,6 +64,55 @@ dri3_flush_present_events(struct loader_dri3_drawable 
> *draw);
>  static struct loader_dri3_buffer *
>  dri3_find_back_alloc(struct loader_dri3_drawable *draw);
>
> +static xcb_screen_t *
> +get_screen_for_root(xcb_connection_t *conn, xcb_window_t root)
> +{
> +   xcb_screen_iterator_t screen_iter =
> +   xcb_setup_roots_iterator(xcb_get_setup(conn));
> +
> +   for (; screen_iter.rem; xcb_screen_next (_iter)) {
> +  if (screen_iter.data->root == root)
> + return screen_iter.data;
> +   }
> +
> +   return NULL;
> +}
> +
> +static xcb_visualtype_t *
> +get_xcb_visualtype_for_depth(struct loader_dri3_drawable *draw, int depth)
> +{
> +   xcb_visualtype_iterator_t visual_iter;
> +   xcb_screen_t *screen = draw->screen;
> +   xcb_depth_iterator_t depth_iter;
> +
> +   if (!screen)
> +  return NULL;
> +
> +   depth_iter = xcb_screen_allowed_depths_iterator(screen);
> +   for (; depth_iter.rem; xcb_depth_next(_iter)) {
> +  if (depth_iter.data->depth != depth)
> + continue;
> +
> +  visual_iter = xcb_depth_visuals_iterator(depth_iter.data);
> +  if (visual_iter.rem)
> + return visual_iter.data;
> +   }
> +
> +   return NULL;
> +}
> +
> +/* Get red channel mask for given drawable at given depth. */
> +static unsigned int
> +dri3_get_red_mask_for_depth(struct loader_dri3_drawable *draw, int depth)
> +{
> +   xcb_visualtype_t *visual = get_xcb_visualtype_for_depth(draw, depth);
> +
> +   if (visual)
> +  return visual->red_mask;
> +
> +   return 0;
> +}
> +
>  /**
>   * Do we have blit functionality in the image blit extension?
>   *
> @@ -323,6 +372,7 @@ loader_d

Re: [Mesa-dev] Nouveau depth 30 stuff again..

[Mario Kleiner]

Ping? I think this series should be ready for merging, had all review
comments addressed and was obsessively tested by myself on intel, amd,
nouveau and dri3/present with prime renderoffload for intel+nouveau,
amd+nouveau and nouveau+amd, on both native x11 and wayland+weston. It
makes many things better, but nothing worse, as far as my testing
goes.

It would be great to get this merged for Mesa 18.2. Can i bribe
somebody into this, in exchange for a beer on xdc2018, assuming i
manage to make it there?

Cheers,
-mario

On Wed, Jun 13, 2018 at 6:04 AM, Mario Kleiner
 wrote:
> A resend of the series, with all of Eric Engestroems review comments
> addressed and retested on all combos of intel, nvidia, intel+nvidia
> prime.
>
> Rebased and retested against current Mesa master, otherwise only
> style fixes and an additional assert for documentation, no real
> functional changes.
>
> Please merge, thanks
> -mario
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] loader_dri3: Handle mismatched depth 30 formats for Prime renderoffload.

[Mario Kleiner]

Detect if the display (X-Server) gpu and Prime renderoffload gpu prefer
different channel ordering for color depth 30 formats ([X/A]BGR2101010
vs. [X/A]RGB2101010) and perform format conversion during the blitImage()
detiling op from tiled backbuffer -> linear buffer.

For this we need to find the visual (= red channel mask) for the
X-Drawable used to display on the server gpu. We use the same proven
logic for finding that visual as in commit "egl/x11: Handle both depth
30 formats for eglCreateImage()".

This is mostly to allow "NVidia Optimus" at depth 30, as Intel/AMD
gpu's prefer xRGB2101010 ordering, whereas NVidia gpu's prefer
xBGR2101010 ordering, so we can offload to nouveau without getting
funky colors.

Tested on Intel single gpu, NVidia single gpu, Intel + NVidia prime
offload with DRI3/Present.

Note: An unintended but pleasant surprise of this patch is that it also
seems to make the modesetting-ddx of server 1.20.0 work at depth 30
on nouveau, at least with unredirected "classic" X rendering, and
with redirected desktop compositing under XRender accel, and with OpenGL
compositing under GLX. Only X11 compositing via OpenGL + EGL still gives
funky colors. modesetting-ddx + glamor are not yet ready to deal with
nouveau's ABGR2101010 format, and treat it as ARGB2101010, also exposing
X-visuals with ARGB2101010 style channel masks. Seems somehow this triggers
the logic in this patch on modesetting-ddx + depth 30 + DRI3 buffer sharing
and does the "wrong" channel swizzling that then cancels out the "wrong"
swizzling of glamor and we end up with the proper pixel formatting in
the scanout buffer :). This so far tested on a NVA5 Tesla card under KDE5
Plasma as shipping with Ubuntu 16.04.4 LTS.

Signed-off-by: Mario Kleiner 
Cc: Ilia Mirkin 
Cc: Eric Engestrom 
---
 src/loader/loader_dri3_helper.c | 83 -
 src/loader/loader_dri3_helper.h |  1 +
 2 files changed, 83 insertions(+), 1 deletion(-)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index f0ff2f07bd..a9a18921ce 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -64,6 +64,55 @@ dri3_flush_present_events(struct loader_dri3_drawable *draw);
 static struct loader_dri3_buffer *
 dri3_find_back_alloc(struct loader_dri3_drawable *draw);
 
+static xcb_screen_t *
+get_screen_for_root(xcb_connection_t *conn, xcb_window_t root)
+{
+   xcb_screen_iterator_t screen_iter =
+   xcb_setup_roots_iterator(xcb_get_setup(conn));
+
+   for (; screen_iter.rem; xcb_screen_next (_iter)) {
+  if (screen_iter.data->root == root)
+ return screen_iter.data;
+   }
+
+   return NULL;
+}
+
+static xcb_visualtype_t *
+get_xcb_visualtype_for_depth(struct loader_dri3_drawable *draw, int depth)
+{
+   xcb_visualtype_iterator_t visual_iter;
+   xcb_screen_t *screen = draw->screen;
+   xcb_depth_iterator_t depth_iter;
+
+   if (!screen)
+  return NULL;
+
+   depth_iter = xcb_screen_allowed_depths_iterator(screen);
+   for (; depth_iter.rem; xcb_depth_next(_iter)) {
+  if (depth_iter.data->depth != depth)
+ continue;
+
+  visual_iter = xcb_depth_visuals_iterator(depth_iter.data);
+  if (visual_iter.rem)
+ return visual_iter.data;
+   }
+
+   return NULL;
+}
+
+/* Get red channel mask for given drawable at given depth. */
+static unsigned int
+dri3_get_red_mask_for_depth(struct loader_dri3_drawable *draw, int depth)
+{
+   xcb_visualtype_t *visual = get_xcb_visualtype_for_depth(draw, depth);
+
+   if (visual)
+  return visual->red_mask;
+
+   return 0;
+}
+
 /**
  * Do we have blit functionality in the image blit extension?
  *
@@ -323,6 +372,7 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
   return 1;
}
 
+   draw->screen = get_screen_for_root(draw->conn, reply->root);
draw->width = reply->width;
draw->height = reply->height;
draw->depth = reply->depth;
@@ -1030,6 +1080,36 @@ dri3_cpp_for_format(uint32_t format) {
}
 }
 
+/* Map format of render buffer to corresponding format for the linear_buffer
+ * used for sharing with the display gpu of a Prime setup (== 
is_different_gpu).
+ * Usually linear_format == format, except for depth >= 30 formats, where
+ * different gpu vendors have different preferences wrt. color channel 
ordering.
+ */
+static uint32_t
+dri3_linear_format_for_format(struct loader_dri3_drawable *draw, uint32_t 
format)
+{
+   switch (format) {
+  case  __DRI_IMAGE_FORMAT_XRGB2101010:
+  case  __DRI_IMAGE_FORMAT_XBGR2101010:
+ /* Different preferred formats for different hw */
+ if (dri3_get_red_mask_for_depth(draw, 30) == 0x3ff)
+return __DRI_IMAGE_FORMAT_XBGR2101010;
+ else
+return __DRI_IMAGE_FORMAT_XRGB2101010;
+
+  case  __DRI_IMAGE_FORMAT_ARGB2101010:
+  case  __DRI_IMAGE_FORMAT_ABGR2101010:
+ /* Different pre

[Mesa-dev] [PATCH 1/5] egl/wayland: Add 10bpc BGR configs

[Mario Kleiner]

From: Daniel Stone 

Add support for XBGR2101010 and ABGR2101010.

Signed-off-by: Daniel Stone 
Reviewed-by: Eric Engestrom 
Reviewed-by: Mario Kleiner 
Tested-by: Mario Kleiner 
Tested-by: Ilia Mirkin 
---
 src/egl/drivers/dri2/platform_wayland.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 11026f9..f64fde8 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -83,6 +83,18 @@ static const struct dri2_wl_visual {
  { 0x3ff0, 0x000ffc00, 0x03ff, 0xc000 }
},
{
+ "XBGR2101010",
+ WL_DRM_FORMAT_XBGR2101010, WL_SHM_FORMAT_XBGR2101010,
+ __DRI_IMAGE_FORMAT_XBGR2101010, 32,
+ { 0x03ff, 0x000ffc00, 0x3ff0, 0x }
+   },
+   {
+ "ABGR2101010",
+ WL_DRM_FORMAT_ABGR2101010, WL_SHM_FORMAT_ABGR2101010,
+ __DRI_IMAGE_FORMAT_ABGR2101010, 32,
+ { 0x03ff, 0x000ffc00, 0x3ff0, 0xc000 }
+   },
+   {
  "XRGB",
  WL_DRM_FORMAT_XRGB, WL_SHM_FORMAT_XRGB,
  __DRI_IMAGE_FORMAT_XRGB, 32,
-- 
2.7.4

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

[Mesa-dev] [PATCH 5/5] egl/wayland-drm: Only announce formats via wl_drm which the driver supports.

[Mario Kleiner]

Check if a pixel format is supported by the Wayland servers gpu driver
before exposing it to the client via wl_drm, so we avoid reporting formats
to the client which the server gpu can't handle.

Restrict this reporting to the new color depth 30 formats for now, as the
ARGB/XRGB and RGB565 formats are probably supported by every gpu under
the sun.

Atm. this is mostly useful to allow proper PRIME renderoffload for depth
30 formats on the typical Intel iGPU + NVidia dGPU "NVidia Optimus" laptop
combo.

Tested on Intel, AMD, NVidia with single-gpu setup and on a Intel + NVidia
Optimus setup.

Signed-off-by: Mario Kleiner 
Cc: Eric Engestrom 
Cc: Daniel Stone 
---
 src/egl/drivers/dri2/egl_dri2.c   |  3 ++-
 src/egl/drivers/dri2/egl_dri2.h   |  2 ++
 src/egl/drivers/dri2/platform_wayland.c   | 18 ++
 src/egl/wayland/wayland-drm/wayland-drm.c | 31 +++
 src/egl/wayland/wayland-drm/wayland-drm.h |  2 ++
 5 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 45d0c72..db0895c 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -2766,7 +2766,8 @@ dri2_bind_wayland_display_wl(_EGLDriver *drv, _EGLDisplay 
*disp,
const struct wayland_drm_callbacks wl_drm_callbacks = {
   .authenticate = (int(*)(void *, uint32_t)) dri2_dpy->vtbl->authenticate,
   .reference_buffer = dri2_wl_reference_buffer,
-  .release_buffer = dri2_wl_release_buffer
+  .release_buffer = dri2_wl_release_buffer,
+  .is_format_supported = dri2_wl_is_format_supported
};
int flags = 0;
uint64_t cap;
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 7e7032d..53b40f2 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -450,6 +450,8 @@ EGLBoolean
 dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay *disp);
 void
 dri2_teardown_wayland(struct dri2_egl_display *dri2_dpy);
+bool
+dri2_wl_is_format_supported(void* user_data, uint32_t format);
 #else
 static inline EGLBoolean
 dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay *disp)
diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 6a083e4..696fec9 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -182,6 +182,24 @@ dri2_wl_visual_idx_from_shm_format(uint32_t shm_format)
return -1;
 }
 
+bool
+dri2_wl_is_format_supported(void* user_data, uint32_t format)
+{
+   _EGLDisplay *disp = (_EGLDisplay *) user_data;
+   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+   int j = dri2_wl_visual_idx_from_fourcc(format);
+
+   if (j == -1)
+  return false;
+
+   for (int i = 0; dri2_dpy->driver_configs[i]; i++)
+  if (j == dri2_wl_visual_idx_from_config(dri2_dpy,
+  dri2_dpy->driver_configs[i]))
+ return true;
+
+   return false;
+}
+
 static int
 roundtrip(struct dri2_egl_display *dri2_dpy)
 {
diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c 
b/src/egl/wayland/wayland-drm/wayland-drm.c
index 3c6696d..51cdd2c 100644
--- a/src/egl/wayland/wayland-drm/wayland-drm.c
+++ b/src/egl/wayland/wayland-drm/wayland-drm.c
@@ -111,6 +111,8 @@ drm_create_buffer(struct wl_client *client, struct 
wl_resource *resource,
  uint32_t stride, uint32_t format)
 {
 switch (format) {
+case WL_DRM_FORMAT_ABGR2101010:
+case WL_DRM_FORMAT_XBGR2101010:
 case WL_DRM_FORMAT_ARGB2101010:
 case WL_DRM_FORMAT_XRGB2101010:
 case WL_DRM_FORMAT_ARGB:
@@ -210,10 +212,31 @@ bind_drm(struct wl_client *client, void *data, uint32_t 
version, uint32_t id)
wl_resource_set_implementation(resource, _interface, data, NULL);
 
wl_resource_post_event(resource, WL_DRM_DEVICE, drm->device_name);
-   wl_resource_post_event(resource, WL_DRM_FORMAT,
-  WL_DRM_FORMAT_ARGB2101010);
-   wl_resource_post_event(resource, WL_DRM_FORMAT,
-  WL_DRM_FORMAT_XRGB2101010);
+
+   if (drm->callbacks.is_format_supported(drm->user_data,
+  WL_DRM_FORMAT_ARGB2101010)) {
+   wl_resource_post_event(resource, WL_DRM_FORMAT,
+  WL_DRM_FORMAT_ARGB2101010);
+   }
+
+   if (drm->callbacks.is_format_supported(drm->user_data,
+  WL_DRM_FORMAT_XRGB2101010)) {
+   wl_resource_post_event(resource, WL_DRM_FORMAT,
+  WL_DRM_FORMAT_XRGB2101010);
+   }
+
+   if (drm->callbacks.is_format_supported(drm->user_data,
+  WL_DRM_FORMAT_ABGR2101010)) {
+   wl_

[Mesa-dev] [PATCH 2/5] gbm: Add support for 10bpp BGR formats

[Mario Kleiner]

From: Daniel Stone 

Add support for XBGR2101010 and ABGR2101010 formats.

Signed-off-by: Daniel Stone 
Reviewed-by: Mario Kleiner 
Tested-by: Mario Kleiner 
Tested-by: Ilia Mirkin 
---
 src/gbm/backends/dri/gbm_dri.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index df20db4..b3d6ceb 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -580,6 +580,14 @@ static const struct gbm_dri_visual gbm_dri_visuals_table[] 
= {
  GBM_FORMAT_ARGB2101010, __DRI_IMAGE_FORMAT_ARGB2101010,
  { 0x3ff0, 0x000ffc00, 0x03ff, 0xc000 },
},
+   {
+ GBM_FORMAT_XBGR2101010, __DRI_IMAGE_FORMAT_XBGR2101010,
+ { 0x03ff, 0x000ffc00, 0x3ff0, 0x },
+   },
+   {
+ GBM_FORMAT_ABGR2101010, __DRI_IMAGE_FORMAT_ABGR2101010,
+ { 0x03ff, 0x000ffc00, 0x3ff0, 0xc000 },
+   },
 };
 
 /* The two GBM_BO_FORMAT_[XA]RGB formats alias the GBM_FORMAT_*
-- 
2.7.4

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

[Mesa-dev] Nouveau depth 30 stuff again..

[Mario Kleiner]

A resend of the series, with all of Eric Engestroems review comments
addressed and retested on all combos of intel, nvidia, intel+nvidia
prime.

Rebased and retested against current Mesa master, otherwise only
style fixes and an additional assert for documentation, no real
functional changes.

Please merge, thanks
-mario

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

[Mesa-dev] [PATCH 3/5] egl/x11: Handle both depth 30 formats for eglCreateImage(). (v4)

[Mario Kleiner]

We need to distinguish if the backing storage of a pixmap
is XRGB2101010 or XBGR2101010, as different gpu hw supports
different formats. NVidia hw prefers XBGR, whereas AMD and
Intel are happy with XRGB.

Use the red channel mask of the first depth 30 visual of
the x-screen to distinguish which hw format to choose.

This fixes desktop composition of color depth 30 windows
when the X11 compositor uses EGL.

v2: Switch from using the visual of the root window to simply
using the first depth 30 visual for the x-screen, as testing
shows that each driver only exports either xrgb ordering or
xbgr ordering for the channel masks of its depth 30 visuals,
so this should be unambiguous and avoid trouble if X ever
supports depth 30 pixmaps on screens with a non-depth 30 root
window visual. This per Michels suggestion.

v3: No change to v2, but spent some time testing this more on
AMD hw, with my software hacked up to intentionally choose
pixel formats/visual with the non-preferred xBGR2101010
ordering on the ati-ddx, also with a standard non-OpenGL
X-Window with depth 30 visual, to make sure that things show
up properly with the right colors on the screen when going
through EGL+OpenGL based compositing on KDE-5. Iow. to confirm
that my explanation to the v2 patch on the mailing list of why
it should work and the actual practice agree (or possibly that
i am good at fooling myself during testing ;).

v4: Drop the local `red_mask` and just `return visual->red_mask`/
`return 0`, as suggested by Eric Engestrom.

Rebased onto current master, to take the cleanup via the new
function dri2_format_for_depth() into account.

Signed-off-by: Mario Kleiner 
Reviewed-by: Eric Engestrom 
---
 src/egl/drivers/dri2/egl_dri2.h  |  7 +
 src/egl/drivers/dri2/platform_x11.c  | 44 +++-
 src/egl/drivers/dri2/platform_x11_dri3.c |  4 +--
 src/egl/drivers/dri2/platform_x11_dri3.h |  2 +-
 4 files changed, 48 insertions(+), 9 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index adabc52..7e7032d 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -413,6 +413,8 @@ EGLBoolean
 dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp);
 void
 dri2_teardown_x11(struct dri2_egl_display *dri2_dpy);
+unsigned int
+dri2_x11_get_red_mask_for_depth(struct dri2_egl_display *dri2_dpy, int depth);
 #else
 static inline EGLBoolean
 dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp)
@@ -421,6 +423,11 @@ dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp)
 }
 static inline void
 dri2_teardown_x11(struct dri2_egl_display *dri2_dpy) {}
+static inline unsigned int
+dri2_x11_get_red_mask_for_depth(struct dri2_egl_display *dri2_dpy, int depth)
+{
+   return 0;
+}
 #endif
 
 #ifdef HAVE_DRM_PLATFORM
diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index ea9b0cc..cfa5c4a 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -56,7 +56,7 @@ dri2_x11_swap_interval(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *surf,
EGLint interval);
 
 uint32_t
-dri2_format_for_depth(uint32_t depth);
+dri2_format_for_depth(struct dri2_egl_display *dri2_dpy, uint32_t depth);
 
 static void
 swrastCreateDrawable(struct dri2_egl_display * dri2_dpy,
@@ -212,6 +212,36 @@ get_xcb_screen(xcb_screen_iterator_t iter, int screen)
 return NULL;
 }
 
+static xcb_visualtype_t *
+get_xcb_visualtype_for_depth(struct dri2_egl_display *dri2_dpy, int depth)
+{
+   xcb_visualtype_iterator_t visual_iter;
+   xcb_screen_t *screen = dri2_dpy->screen;
+   xcb_depth_iterator_t depth_iter = 
xcb_screen_allowed_depths_iterator(screen);
+
+   for (; depth_iter.rem; xcb_depth_next(_iter)) {
+  if (depth_iter.data->depth != depth)
+ continue;
+
+  visual_iter = xcb_depth_visuals_iterator(depth_iter.data);
+  if (visual_iter.rem)
+ return visual_iter.data;
+   }
+
+   return NULL;
+}
+
+/* Get red channel mask for given depth. */
+unsigned int
+dri2_x11_get_red_mask_for_depth(struct dri2_egl_display *dri2_dpy, int depth)
+{
+   xcb_visualtype_t *visual = get_xcb_visualtype_for_depth(dri2_dpy, depth);
+
+   if (visual)
+  return visual->red_mask;
+
+   return 0;
+}
 
 /**
  * Called via eglCreateWindowSurface(), drv->API.CreateWindowSurface().
@@ -1010,7 +1040,7 @@ dri2_x11_copy_buffers(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *surf,
 }
 
 uint32_t
-dri2_format_for_depth(uint32_t depth)
+dri2_format_for_depth(struct dri2_egl_display *dri2_dpy, uint32_t depth)
 {
switch (depth) {
case 16:
@@ -1018,7 +1048,11 @@ dri2_format_for_depth(uint32_t depth)
case 24:
   return __DRI_IMAGE_FORMAT_XRGB;
case 30:
-  return __DRI_IMAGE_FORMAT_XRGB2101010;
+  /* Different preferred formats for different hw */
+  if (dri2_x11_get_red

[Mesa-dev] [PATCH 4/5] egl/wayland: Allow client->server format conversion for PRIME offload. (v2)

[Mario Kleiner]

Support PRIME render offload between a Wayland server gpu and a Wayland
client gpu with different channel ordering for their color formats,
e.g., between Intel drivers which currently only support ARGB2101010
and XRGB2101010 import/display and nouveau which only supports ABGR2101010
rendering and display on nv-50 and later.

In the wl_visuals table, we also store for each format an alternate
sibling format which stores colors at the same precision, but with
different channel ordering, e.g., ARGB2101010 <-> ABGR2101010.

If a given client-gpu renderable format is not supported by the server
for import, but the alternate format is supported by the server, expose
the client-gpu renderable format as a valid EGLConfig to the client. At
eglSwapBuffers time, during the blitImage() detiling blit from the client
backbuffer to the linear buffer, the client format is converted to the
server supported format. As we have to do a copy for PRIME anyway,
this channel swizzling conversion comes essentially for free.

Note that even if a server gpu in principle does support sampling
from the clients native format, this conversion will be a performance
advantage if it allows to convert to the servers preferred format
for direct scanout, as the Wayland compositor may then be able to
directly page-flip a fullscreen client wl_buffer onto the primary
plane, or onto a hardware overlay plane, avoiding an extra data copy
for desktop composition.

Tested so far under Weston with: nouveau single-gpu, Intel single-gpu,
AMD single-gpu, "Optimus" Intel server iGPU for display + NVidia
client dGPU for rendering.

v2: Implement minor review comments by Eric Engestrom: Add some
comment and assert, and some style fixes for clarity.
No functional change.

Signed-off-by: Mario Kleiner 
Cc: Eric Engestrom 
---
 src/egl/drivers/dri2/platform_wayland.c | 80 +
 1 file changed, 71 insertions(+), 9 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index f64fde8..6a083e4 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -67,49 +67,57 @@ static const struct dri2_wl_visual {
uint32_t wl_drm_format;
uint32_t wl_shm_format;
int dri_image_format;
+   /* alt_dri_image_format is a substitute wl_buffer format to use for a
+* wl-server unsupported dri_image_format, ie. some other dri_image_format 
in
+* the table, of the same precision but with different channel ordering, or
+* __DRI_IMAGE_FORMAT_NONE if an alternate format is not needed or 
supported.
+* The code checks if alt_dri_image_format can be used as a fallback for a
+* dri_image_format for a given wl-server implementation.
+*/
+   int alt_dri_image_format;
int bpp;
unsigned int rgba_masks[4];
 } dri2_wl_visuals[] = {
{
  "XRGB2101010",
  WL_DRM_FORMAT_XRGB2101010, WL_SHM_FORMAT_XRGB2101010,
- __DRI_IMAGE_FORMAT_XRGB2101010, 32,
+ __DRI_IMAGE_FORMAT_XRGB2101010, __DRI_IMAGE_FORMAT_XBGR2101010, 32,
  { 0x3ff0, 0x000ffc00, 0x03ff, 0x }
},
{
  "ARGB2101010",
  WL_DRM_FORMAT_ARGB2101010, WL_SHM_FORMAT_ARGB2101010,
- __DRI_IMAGE_FORMAT_ARGB2101010, 32,
+ __DRI_IMAGE_FORMAT_ARGB2101010, __DRI_IMAGE_FORMAT_ABGR2101010, 32,
  { 0x3ff0, 0x000ffc00, 0x03ff, 0xc000 }
},
{
  "XBGR2101010",
  WL_DRM_FORMAT_XBGR2101010, WL_SHM_FORMAT_XBGR2101010,
- __DRI_IMAGE_FORMAT_XBGR2101010, 32,
+ __DRI_IMAGE_FORMAT_XBGR2101010, __DRI_IMAGE_FORMAT_XRGB2101010, 32,
  { 0x03ff, 0x000ffc00, 0x3ff0, 0x }
},
{
  "ABGR2101010",
  WL_DRM_FORMAT_ABGR2101010, WL_SHM_FORMAT_ABGR2101010,
- __DRI_IMAGE_FORMAT_ABGR2101010, 32,
+ __DRI_IMAGE_FORMAT_ABGR2101010, __DRI_IMAGE_FORMAT_ARGB2101010, 32,
  { 0x03ff, 0x000ffc00, 0x3ff0, 0xc000 }
},
{
  "XRGB",
  WL_DRM_FORMAT_XRGB, WL_SHM_FORMAT_XRGB,
- __DRI_IMAGE_FORMAT_XRGB, 32,
+ __DRI_IMAGE_FORMAT_XRGB, __DRI_IMAGE_FORMAT_NONE, 32,
  { 0x00ff, 0xff00, 0x00ff, 0x }
},
{
  "ARGB",
  WL_DRM_FORMAT_ARGB, WL_SHM_FORMAT_ARGB,
- __DRI_IMAGE_FORMAT_ARGB, 32,
+ __DRI_IMAGE_FORMAT_ARGB, __DRI_IMAGE_FORMAT_NONE, 32,
  { 0x00ff, 0xff00, 0x00ff, 0xff00 }
},
{
  "RGB565",
  WL_DRM_FORMAT_RGB565, WL_SHM_FORMAT_RGB565,
- __DRI_IMAGE_FORMAT_RGB565, 16,
+ __DRI_IMAGE_FORMAT_RGB565, __DRI_IMAGE_FORMAT_NONE, 16,
  { 0xf800, 0x07e0, 0x001f, 0x }
},
 };
@@ -449,15 +457,29 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
int use_flags;
int visual_idx;
unsigned int dri_image_format;
+   unsigned int linear_dri_image_format;
uint64_t *modifiers;
int num_modifiers;
 
visua

Re: [Mesa-dev] [PATCH 4/5] egl/wayland: Allow client->server format conversion for PRIME offload.

[Mario Kleiner]

On Mon, May 21, 2018 at 4:42 PM, Eric Engestrom
<eric.engest...@intel.com> wrote:
> On Saturday, 2018-05-19 05:32:41 +0200, Mario Kleiner wrote:
>> Support PRIME render offload between a Wayland server gpu and a Wayland
>> client gpu with different channel ordering for their color formats,
>> e.g., between Intel drivers which currently only support ARGB2101010
>> and XRGB2101010 import/display and nouveau which only supports ABGR2101010
>> rendering and display on nv-50 and later.
>>
>> In the wl_visuals table, we also store for each format an alternate
>> sibling format which stores colors at the same precision, but with
>> different channel ordering, e.g., ARGB2101010 <-> ABGR2101010.
>>
>> If a given client-gpu renderable format is not supported by the server
>> for import, but the alternate format is supported by the server, expose
>> the client-gpu renderable format as a valid EGLConfig to the client. At
>> eglSwapBuffers time, during the blitImage() detiling blit from the client
>> backbuffer to the linear buffer, the client format is converted to the
>> server supported format. As we have to do a copy for PRIME anyway,
>> this channel swizzling conversion comes essentially for free.
>>
>> Note that even if a server gpu in principle does support sampling
>> from the clients native format, this conversion will be a performance
>> advantage if it allows to convert to the servers preferred format
>> for direct scanout, as the Wayland compositor may then be able to
>> directly page-flip a fullscreen client wl_buffer onto the primary
>> plane, or onto a hardware overlay plane, avoiding an extra data copy
>> for desktop composition.
>>
>> Tested so far under Weston with: nouveau single-gpu, Intel single-gpu,
>> AMD single-gpu, "Optimus" Intel server iGPU for display + NVidia
>> client dGPU for rendering.
>>
>> Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
>> Cc: Daniel Stone <dani...@collabora.com>
>> ---
>>  src/egl/drivers/dri2/platform_wayland.c | 67 
>> -
>>  1 file changed, 58 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/egl/drivers/dri2/platform_wayland.c 
>> b/src/egl/drivers/dri2/platform_wayland.c
>> index 89a7f90118..fb364a6233 100644
>> --- a/src/egl/drivers/dri2/platform_wayland.c
>> +++ b/src/egl/drivers/dri2/platform_wayland.c
>> @@ -68,49 +68,50 @@ static const struct dri2_wl_visual {
>> uint32_t wl_drm_format;
>> uint32_t wl_shm_format;
>> int dri_image_format;
>> +   int alt_dri_image_format;
>

Thanks for the review.

> A comment here wouldn't hurt, to explain what this "alt" is to someone
> who sees the code after it landed :)
>

Will do, although i usually feel a bit guilty that my patches usually
suffer from over-commenting and essay length commit messages :)

>> int bpp;
>> unsigned int rgba_masks[4];
>>  } dri2_wl_visuals[] = {
>> {
>>   "XRGB2101010",
>>   WL_DRM_FORMAT_XRGB2101010, WL_SHM_FORMAT_XRGB2101010,
>> - __DRI_IMAGE_FORMAT_XRGB2101010, 32,
>> + __DRI_IMAGE_FORMAT_XRGB2101010, __DRI_IMAGE_FORMAT_XBGR2101010, 32,
>>   { 0x3ff0, 0x000ffc00, 0x03ff, 0x }
>> },
>> {
>>   "ARGB2101010",
>>   WL_DRM_FORMAT_ARGB2101010, WL_SHM_FORMAT_ARGB2101010,
>> - __DRI_IMAGE_FORMAT_ARGB2101010, 32,
>> + __DRI_IMAGE_FORMAT_ARGB2101010, __DRI_IMAGE_FORMAT_ABGR2101010, 32,
>>   { 0x3ff0, 0x000ffc00, 0x03ff, 0xc000 }
>> },
>> {
>>   "XBGR2101010",
>>   WL_DRM_FORMAT_XBGR2101010, WL_SHM_FORMAT_XBGR2101010,
>> - __DRI_IMAGE_FORMAT_XBGR2101010, 32,
>> + __DRI_IMAGE_FORMAT_XBGR2101010, __DRI_IMAGE_FORMAT_XRGB2101010, 32,
>>   { 0x03ff, 0x000ffc00, 0x3ff0, 0x }
>> },
>> {
>>   "ABGR2101010",
>>   WL_DRM_FORMAT_ABGR2101010, WL_SHM_FORMAT_ABGR2101010,
>> - __DRI_IMAGE_FORMAT_ABGR2101010, 32,
>> + __DRI_IMAGE_FORMAT_ABGR2101010, __DRI_IMAGE_FORMAT_ARGB2101010, 32,
>>   { 0x03ff, 0x000ffc00, 0x3ff0, 0xc000 }
>> },
>> {
>>   "XRGB",
>>   WL_DRM_FORMAT_XRGB, WL_SHM_FORMAT_XRGB,
>> - __DRI_IMAGE_FORMAT_XRGB, 32,
>> + __DRI_IMAGE_FORMAT_XRGB, __DRI_IMAGE_FORMAT_NONE, 32,
>>   { 0x00ff, 0xff00, 0x00ff, 0x }
>> },
>> {
>>   "ARGB",
>>   WL

[Mesa-dev] [PATCH 4/5] egl/wayland: Allow client->server format conversion for PRIME offload.

[Mario Kleiner]

Support PRIME render offload between a Wayland server gpu and a Wayland
client gpu with different channel ordering for their color formats,
e.g., between Intel drivers which currently only support ARGB2101010
and XRGB2101010 import/display and nouveau which only supports ABGR2101010
rendering and display on nv-50 and later.

In the wl_visuals table, we also store for each format an alternate
sibling format which stores colors at the same precision, but with
different channel ordering, e.g., ARGB2101010 <-> ABGR2101010.

If a given client-gpu renderable format is not supported by the server
for import, but the alternate format is supported by the server, expose
the client-gpu renderable format as a valid EGLConfig to the client. At
eglSwapBuffers time, during the blitImage() detiling blit from the client
backbuffer to the linear buffer, the client format is converted to the
server supported format. As we have to do a copy for PRIME anyway,
this channel swizzling conversion comes essentially for free.

Note that even if a server gpu in principle does support sampling
from the clients native format, this conversion will be a performance
advantage if it allows to convert to the servers preferred format
for direct scanout, as the Wayland compositor may then be able to
directly page-flip a fullscreen client wl_buffer onto the primary
plane, or onto a hardware overlay plane, avoiding an extra data copy
for desktop composition.

Tested so far under Weston with: nouveau single-gpu, Intel single-gpu,
AMD single-gpu, "Optimus" Intel server iGPU for display + NVidia
client dGPU for rendering.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: Daniel Stone <dani...@collabora.com>
---
 src/egl/drivers/dri2/platform_wayland.c | 67 -
 1 file changed, 58 insertions(+), 9 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 89a7f90118..fb364a6233 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -68,49 +68,50 @@ static const struct dri2_wl_visual {
uint32_t wl_drm_format;
uint32_t wl_shm_format;
int dri_image_format;
+   int alt_dri_image_format;
int bpp;
unsigned int rgba_masks[4];
 } dri2_wl_visuals[] = {
{
  "XRGB2101010",
  WL_DRM_FORMAT_XRGB2101010, WL_SHM_FORMAT_XRGB2101010,
- __DRI_IMAGE_FORMAT_XRGB2101010, 32,
+ __DRI_IMAGE_FORMAT_XRGB2101010, __DRI_IMAGE_FORMAT_XBGR2101010, 32,
  { 0x3ff0, 0x000ffc00, 0x03ff, 0x }
},
{
  "ARGB2101010",
  WL_DRM_FORMAT_ARGB2101010, WL_SHM_FORMAT_ARGB2101010,
- __DRI_IMAGE_FORMAT_ARGB2101010, 32,
+ __DRI_IMAGE_FORMAT_ARGB2101010, __DRI_IMAGE_FORMAT_ABGR2101010, 32,
  { 0x3ff0, 0x000ffc00, 0x03ff, 0xc000 }
},
{
  "XBGR2101010",
  WL_DRM_FORMAT_XBGR2101010, WL_SHM_FORMAT_XBGR2101010,
- __DRI_IMAGE_FORMAT_XBGR2101010, 32,
+ __DRI_IMAGE_FORMAT_XBGR2101010, __DRI_IMAGE_FORMAT_XRGB2101010, 32,
  { 0x03ff, 0x000ffc00, 0x3ff0, 0x }
},
{
  "ABGR2101010",
  WL_DRM_FORMAT_ABGR2101010, WL_SHM_FORMAT_ABGR2101010,
- __DRI_IMAGE_FORMAT_ABGR2101010, 32,
+ __DRI_IMAGE_FORMAT_ABGR2101010, __DRI_IMAGE_FORMAT_ARGB2101010, 32,
  { 0x03ff, 0x000ffc00, 0x3ff0, 0xc000 }
},
{
  "XRGB",
  WL_DRM_FORMAT_XRGB, WL_SHM_FORMAT_XRGB,
- __DRI_IMAGE_FORMAT_XRGB, 32,
+ __DRI_IMAGE_FORMAT_XRGB, __DRI_IMAGE_FORMAT_NONE, 32,
  { 0x00ff, 0xff00, 0x00ff, 0x }
},
{
  "ARGB",
  WL_DRM_FORMAT_ARGB, WL_SHM_FORMAT_ARGB,
- __DRI_IMAGE_FORMAT_ARGB, 32,
+ __DRI_IMAGE_FORMAT_ARGB, __DRI_IMAGE_FORMAT_NONE, 32,
  { 0x00ff, 0xff00, 0x00ff, 0xff00 }
},
{
  "RGB565",
  WL_DRM_FORMAT_RGB565, WL_SHM_FORMAT_RGB565,
- __DRI_IMAGE_FORMAT_RGB565, 16,
+ __DRI_IMAGE_FORMAT_RGB565, __DRI_IMAGE_FORMAT_NONE, 16,
  { 0xf800, 0x07e0, 0x001f, 0x }
},
 };
@@ -450,15 +451,23 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
int use_flags;
int visual_idx;
unsigned int dri_image_format;
+   unsigned int linear_dri_image_format;
uint64_t *modifiers;
int num_modifiers;
 
visual_idx = dri2_wl_visual_idx_from_fourcc(dri2_surf->format);
assert(visual_idx != -1);
dri_image_format = dri2_wl_visuals[visual_idx].dri_image_format;
+   linear_dri_image_format = dri_image_format;
modifiers = u_vector_tail(_dpy->wl_modifiers[visual_idx]);
num_modifiers = u_vector_length(_dpy->wl_modifiers[visual_idx]);
 
+   /* Substitute dri image format if server does not support original format */
+   if (!(dri2_dpy->formats & (1 << visual_idx)))
+  linear_dri_image_format = 
dri2_wl_visuals[visual_idx].alt_dri_

[Mesa-dev] [PATCH 5/5] egl/wayland-drm: Only announce formats via wl_drm which the driver supports.

[Mario Kleiner]

Check if a pixel format is supported by the Wayland servers gpu driver
before exposing it to the client via wl_drm, so we avoid reporting formats
to the client which the server gpu can't handle.

Restrict this reporting to the new color depth 30 formats for now, as the
ARGB/XRGB and RGB565 formats are probably supported by every gpu under
the sun.

Atm. this is mostly useful to allow proper PRIME renderoffload for depth
30 formats on the typical Intel iGPU + NVidia dGPU "NVidia Optimus" laptop
combo.

Tested on Intel, AMD, NVidia with single-gpu setup and on a Intel + NVidia
Optimus setup.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: Daniel Stone <dani...@collabora.com>
---
 src/egl/drivers/dri2/egl_dri2.c   |  3 ++-
 src/egl/drivers/dri2/egl_dri2.h   |  2 ++
 src/egl/drivers/dri2/platform_wayland.c   | 18 ++
 src/egl/wayland/wayland-drm/wayland-drm.c | 31 +++
 src/egl/wayland/wayland-drm/wayland-drm.h |  2 ++
 5 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 45d0c7275c..db0895c2b0 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -2766,7 +2766,8 @@ dri2_bind_wayland_display_wl(_EGLDriver *drv, _EGLDisplay 
*disp,
const struct wayland_drm_callbacks wl_drm_callbacks = {
   .authenticate = (int(*)(void *, uint32_t)) dri2_dpy->vtbl->authenticate,
   .reference_buffer = dri2_wl_reference_buffer,
-  .release_buffer = dri2_wl_release_buffer
+  .release_buffer = dri2_wl_release_buffer,
+  .is_format_supported = dri2_wl_is_format_supported
};
int flags = 0;
uint64_t cap;
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 7e7032d989..53b40f2efa 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -450,6 +450,8 @@ EGLBoolean
 dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay *disp);
 void
 dri2_teardown_wayland(struct dri2_egl_display *dri2_dpy);
+bool
+dri2_wl_is_format_supported(void* user_data, uint32_t format);
 #else
 static inline EGLBoolean
 dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay *disp)
diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index fb364a6233..ba4bbc5d5f 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -176,6 +176,24 @@ dri2_wl_visual_idx_from_shm_format(uint32_t shm_format)
return -1;
 }
 
+bool
+dri2_wl_is_format_supported(void* user_data, uint32_t format)
+{
+   _EGLDisplay *disp = (_EGLDisplay *) user_data;
+   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+   int j = dri2_wl_visual_idx_from_fourcc(format);
+
+   if (j == -1)
+  return false;
+
+   for (int i = 0; dri2_dpy->driver_configs[i]; i++)
+  if (j == dri2_wl_visual_idx_from_config(dri2_dpy,
+  dri2_dpy->driver_configs[i]))
+ return true;
+
+   return false;
+}
+
 static int
 roundtrip(struct dri2_egl_display *dri2_dpy)
 {
diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c 
b/src/egl/wayland/wayland-drm/wayland-drm.c
index 3c6696dbff..51cdd2cb84 100644
--- a/src/egl/wayland/wayland-drm/wayland-drm.c
+++ b/src/egl/wayland/wayland-drm/wayland-drm.c
@@ -111,6 +111,8 @@ drm_create_buffer(struct wl_client *client, struct 
wl_resource *resource,
  uint32_t stride, uint32_t format)
 {
 switch (format) {
+case WL_DRM_FORMAT_ABGR2101010:
+case WL_DRM_FORMAT_XBGR2101010:
 case WL_DRM_FORMAT_ARGB2101010:
 case WL_DRM_FORMAT_XRGB2101010:
 case WL_DRM_FORMAT_ARGB:
@@ -210,10 +212,31 @@ bind_drm(struct wl_client *client, void *data, uint32_t 
version, uint32_t id)
wl_resource_set_implementation(resource, _interface, data, NULL);
 
wl_resource_post_event(resource, WL_DRM_DEVICE, drm->device_name);
-   wl_resource_post_event(resource, WL_DRM_FORMAT,
-  WL_DRM_FORMAT_ARGB2101010);
-   wl_resource_post_event(resource, WL_DRM_FORMAT,
-  WL_DRM_FORMAT_XRGB2101010);
+
+   if (drm->callbacks.is_format_supported(drm->user_data,
+  WL_DRM_FORMAT_ARGB2101010)) {
+   wl_resource_post_event(resource, WL_DRM_FORMAT,
+  WL_DRM_FORMAT_ARGB2101010);
+   }
+
+   if (drm->callbacks.is_format_supported(drm->user_data,
+  WL_DRM_FORMAT_XRGB2101010)) {
+   wl_resource_post_event(resource, WL_DRM_FORMAT,
+  WL_DRM_FORMAT_XRGB2101010);
+   }
+
+   if (drm->callbacks.is_format_supported(drm->user_data,
+  WL_DRM_FORMAT_ABGR2101

[Mesa-dev] [PATCH 3/5] egl/x11: Handle both depth 30 formats for eglCreateImage(). (v3)

[Mario Kleiner]

We need to distinguish if the backing storage of a pixmap
is XRGB2101010 or XBGR2101010, as different gpu hw supports
different formats. NVidia hw prefers XBGR, whereas AMD and
Intel are happy with XRGB.

Use the red channel mask of the first depth 30 visual of
the x-screen to distinguish which hw format to choose.

This fixes desktop composition of color depth 30 windows
when the X11 compositor uses EGL.

v2: Switch from using the visual of the root window to simply
using the first depth 30 visual for the x-screen, as testing
shows that each driver only exports either xrgb ordering or
xbgr ordering for the channel masks of its depth 30 visuals,
so this should be unambiguous and avoid trouble if X ever
supports depth 30 pixmaps on screens with a non-depth 30 root
window visual. This per Michels suggestion.

v3: No change to v2, but spent some time testing this more on
AMD hw, with my software hacked up to intentionally choose
pixel formats/visual with the non-preferred xBGR2101010
ordering on the ati-ddx, also with a standard non-OpenGL
X-Window with depth 30 visual, to make sure that things show
up properly with the right colors on the screen when going
through EGL+OpenGL based compositing on KDE-5. Iow. to confirm
that my explanation to the v2 patch on the mailing list of why
it should work and the actual practice agree (or possibly that
i am good at fooling myself during testing ;).

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: Michel Dänzer <michel.daen...@amd.com>
---
 src/egl/drivers/dri2/egl_dri2.h  |  7 +++
 src/egl/drivers/dri2/platform_x11.c  | 36 +++-
 src/egl/drivers/dri2/platform_x11_dri3.c | 12 +++
 3 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index adabc527f8..7e7032d989 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -413,6 +413,8 @@ EGLBoolean
 dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp);
 void
 dri2_teardown_x11(struct dri2_egl_display *dri2_dpy);
+unsigned int
+dri2_x11_get_red_mask_for_depth(struct dri2_egl_display *dri2_dpy, int depth);
 #else
 static inline EGLBoolean
 dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp)
@@ -421,6 +423,11 @@ dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp)
 }
 static inline void
 dri2_teardown_x11(struct dri2_egl_display *dri2_dpy) {}
+static inline unsigned int
+dri2_x11_get_red_mask_for_depth(struct dri2_egl_display *dri2_dpy, int depth)
+{
+   return 0;
+}
 #endif
 
 #ifdef HAVE_DRM_PLATFORM
diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index 7aca0a9020..aabae02adb 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -209,6 +209,36 @@ get_xcb_screen(xcb_screen_iterator_t iter, int screen)
 return NULL;
 }
 
+static xcb_visualtype_t *
+get_xcb_visualtype_for_depth(struct dri2_egl_display *dri2_dpy, int depth)
+{
+   xcb_visualtype_iterator_t visual_iter;
+   xcb_screen_t *screen = dri2_dpy->screen;
+   xcb_depth_iterator_t depth_iter = 
xcb_screen_allowed_depths_iterator(screen);
+
+   for (; depth_iter.rem; xcb_depth_next(_iter)) {
+  if (depth_iter.data->depth != depth)
+ continue;
+
+  visual_iter = xcb_depth_visuals_iterator(depth_iter.data);
+  if (visual_iter.rem)
+ return visual_iter.data;
+   }
+
+   return NULL;
+}
+
+/* Get red channel mask for given depth. */
+unsigned int
+dri2_x11_get_red_mask_for_depth(struct dri2_egl_display *dri2_dpy, int depth)
+{
+   unsigned int red_mask = 0;
+   xcb_visualtype_t *visual = get_xcb_visualtype_for_depth(dri2_dpy, depth);
+   if (visual)
+  red_mask = visual->red_mask;
+
+   return red_mask;
+}
 
 /**
  * Called via eglCreateWindowSurface(), drv->API.CreateWindowSurface().
@@ -1058,7 +1088,11 @@ dri2_create_image_khr_pixmap(_EGLDisplay *disp, 
_EGLContext *ctx,
   format = __DRI_IMAGE_FORMAT_XRGB;
   break;
case 30:
-  format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  /* Different preferred formats for different hw */
+  if (dri2_x11_get_red_mask_for_depth(dri2_dpy, 30) == 0x3ff)
+ format = __DRI_IMAGE_FORMAT_XBGR2101010;
+  else
+ format = __DRI_IMAGE_FORMAT_XRGB2101010;
   break;
case 32:
   format = __DRI_IMAGE_FORMAT_ARGB;
diff --git a/src/egl/drivers/dri2/platform_x11_dri3.c 
b/src/egl/drivers/dri2/platform_x11_dri3.c
index 5cb6d65c0a..9525b20158 100644
--- a/src/egl/drivers/dri2/platform_x11_dri3.c
+++ b/src/egl/drivers/dri2/platform_x11_dri3.c
@@ -40,7 +40,7 @@
 #include "loader_dri3_helper.h"
 
 static uint32_t
-dri3_format_for_depth(uint32_t depth)
+dri3_format_for_depth(struct dri2_egl_display *dri2_dpy, uint32_t depth)
 {
switch (depth) {
case 16:
@@ -48,7 +48,11 @@ dri3_format_for_depth(uint32_t

[Mesa-dev] [PATCH 1/5] egl/wayland: Add 10bpc BGR configs

[Mario Kleiner]

From: Daniel Stone <dani...@collabora.com>

Add support for XBGR2101010 and ABGR2101010.

Signed-off-by: Daniel Stone <dani...@collabora.com>
Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>
Reviewed-by: Mario Kleiner <mario.kleiner...@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner...@gmail.com>
Tested-by: Ilia Mirkin <imir...@alum.mit.edu>
---
 src/egl/drivers/dri2/platform_wayland.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 63da21cdf5..89a7f90118 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -84,6 +84,18 @@ static const struct dri2_wl_visual {
  { 0x3ff0, 0x000ffc00, 0x03ff, 0xc000 }
},
{
+ "XBGR2101010",
+ WL_DRM_FORMAT_XBGR2101010, WL_SHM_FORMAT_XBGR2101010,
+ __DRI_IMAGE_FORMAT_XBGR2101010, 32,
+ { 0x03ff, 0x000ffc00, 0x3ff0, 0x }
+   },
+   {
+ "ABGR2101010",
+ WL_DRM_FORMAT_ABGR2101010, WL_SHM_FORMAT_ABGR2101010,
+ __DRI_IMAGE_FORMAT_ABGR2101010, 32,
+ { 0x03ff, 0x000ffc00, 0x3ff0, 0xc000 }
+   },
+   {
  "XRGB",
  WL_DRM_FORMAT_XRGB, WL_SHM_FORMAT_XRGB,
  __DRI_IMAGE_FORMAT_XRGB, 32,
-- 
2.13.0.rc1.294.g07d810a77f

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

[Mesa-dev] Wrap up of depth 30 patches for nouveau.

[Mario Kleiner]

Hi,

this series contains all the remaining patches for depth 30 support
on nouveau and possible future driver with xBGR2101010 ordering
instead of the xRGB2101010 ordering already supported since Mesa 18.0.
These are the ones i obsessively tested with success.

First two patches are Daniel's, which have been reviewed and tested
by myself, Ilia and Eric, but for some reason Patchwork didn't detect
the R-b and t-b statements, so i added them to make it easier for it.

The egl/x11 patch is identical to v2, just more tested on ati-ddx to
make sure the machine agrees with my explanation to v2 of why it should
work fine.

Patches 4 and 5 are new: 4 Replaces the hard-coding of 2101010 formats
by actually detecting which formats are supported. Together with patch 5
that is not only nicer, but may also provide more opportunity to page-flip
in some cases.

Patch 5 is needed for Prime render offload from a Wayland server to a
Wayland client running on a different gpu, on at least Intel + NVidia,
but also helps to enable page-flipping more often. I tested this with
Weston + depth 30 enablement patches. While render offload always works
now, for page flipping (zero-copy present) i needed to disable the new
dmabuf-import path atm. on some gpu's, as Weston's current dmabuf import
and/or atomic modesetting is not yet ready to always allow page-flipping.
But that's a todo for Weston, this patch just enables it in principle.

What is still missing in Mesa is proper Prime offload under regular X
between gpu's with mismatched channel ordering like Intel + NVidia, ie.
the equivalent of patches 4 and 5 for X11. Atm. render offload would simply
display with swapped red and blue channels in such a case. I probably
won't have time or ideas to look into this within the next month or two.

Thanks,
-mario

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

[Mesa-dev] [PATCH 2/5] gbm: Add support for 10bpp BGR formats

[Mario Kleiner]

From: Daniel Stone <dani...@collabora.com>

Add support for XBGR2101010 and ABGR2101010 formats.

Signed-off-by: Daniel Stone <dani...@collabora.com>
Reviewed-by: Mario Kleiner <mario.kleiner...@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner...@gmail.com>
Tested-by: Ilia Mirkin <imir...@alum.mit.edu>
---
 src/gbm/backends/dri/gbm_dri.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index df20db4021..b3d6ceb15a 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -580,6 +580,14 @@ static const struct gbm_dri_visual gbm_dri_visuals_table[] 
= {
  GBM_FORMAT_ARGB2101010, __DRI_IMAGE_FORMAT_ARGB2101010,
  { 0x3ff0, 0x000ffc00, 0x03ff, 0xc000 },
},
+   {
+ GBM_FORMAT_XBGR2101010, __DRI_IMAGE_FORMAT_XBGR2101010,
+ { 0x03ff, 0x000ffc00, 0x3ff0, 0x },
+   },
+   {
+ GBM_FORMAT_ABGR2101010, __DRI_IMAGE_FORMAT_ABGR2101010,
+ { 0x03ff, 0x000ffc00, 0x3ff0, 0xc000 },
+   },
 };
 
 /* The two GBM_BO_FORMAT_[XA]RGB formats alias the GBM_FORMAT_*
-- 
2.13.0.rc1.294.g07d810a77f

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

[Mario Kleiner]

On Sun, May 6, 2018 at 1:51 PM, Tobias Klausmann
<tobias.johannes.klausm...@mni.thm.de> 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.

Re: [Mesa-dev] [PATCH 1/2] loader_dri3: Wait for pending swaps to complete before drawable_fini.

[Mario Kleiner]

On Sat, May 5, 2018 at 4:44 PM, Roman Gilg  wrote:
> Without this patch plasmashell on Xserver/Mesa master freezes on me
> when opening the launcher menu (Kickoff). With the patch haven't
> experienced freezes yet.
>
> Haven't tested the Steam client yet. Might be a different problem though.
>
> Tested-by: Roman Gilg 
>

Thanks. Can you see if you get any freezes in kwin_x11 by "violent
alt-tabbing" with patch 1? I've seen two such freezes within 8 hours
of normal use yesterday, each occuring when i alt-tabbed (normally)
and the switcher side panel moved out from the left. Desktop was
mostly blocked then, i assume it was kwin_x11 that got stuck. When
VT-switching to the console and attaching gdb to kwin_x11 the
backtrace showed it blocked in the loader_dri3_swapbuffer_barrier()
from patch 1. I don't know if that was the cause of the freeze, or if
something unrelated was going wrong and kwin just happens to block
there when one VT switches away from the X-Server while kwin does its
thing. Freezes happened both with compositing enabled and disabled.

So far, only using patch 2/2, i haven't seen any new freezes, but
looking at the debug output i get a lot of these when alt-tabbing:

INIT: wxh = 264 x 1062, drawable 54662577 eid 54662586
QXcbConnection: XCB error: 3 (BadWindow), sequence: 13890, resource
id: 54662577, major code: 20 (GetProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 13902, resource
id: 54662577, major code: 20 (GetProperty), minor code: 0
FINI: wxh = 264 x 1062, drawable 54662577 eid 54662586 recv_sbc 3,
send_sbc 4 PENDING 1
INIT: wxh = 264 x 1062, drawable 54662633 eid 54662644
QXcbConnection: XCB error: 3 (BadWindow), sequence: 14502, resource
id: 54662633, major code: 20 (GetProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 14514, resource
id: 54662633, major code: 20 (GetProperty), minor code: 0
FINI: wxh = 264 x 1062, drawable 54662633 eid 54662644 recv_sbc 2,
send_sbc 3 PENDING 1

Curiously my display is only 1050 pixels high, that window looks higher.

Anyway, would be good to know if patch 1/1 replaces a high frequency
of lockups of plasmashell by a low frequency of lockups of kwin_x11 if
you notice something like that.

Ideally one of the more experienced Mesa developers would find a
better solution than one of these patches, at least long-term.

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

Re: [Mesa-dev] [PATCH 2/2] loader_dri3: Variant 2: Wait for pending swaps to complete before drawable_fini.

[Mario Kleiner]

On Sat, May 5, 2018 at 4:08 AM, Mike Lothian  wrote:
> I definately saw the steam bug with patch 1 but not with plasmashell,
> I started seeing it with patch 2 but it seemed to fix itself
>

I had two hangs of kwin_x11 within the last 6 hours when alt-tabbing
between windows, where it got stuck in the
loader_dri3_swapbuffer_barrier() from patch 1/2. Not sure how that is
possible, or if the stacktrace was misleading, because i had to VT
switch to a text console to attach the debugger and this might be just
a side effect of that. But if it is true, then patch 1/2 would not be
it. Also 1/2 has a potential performance impact, whereas 2/2 doesn't.
However 2/2 would also need more work, as i can think of more complex
scenarios where it would filter the wrong events, although not in the
case of plasmashell or steam. Probably we'd need to sacrifice a few
sbc bits in the Present events serial field to transport a unique tag
for each incarnation of the loader_dri3_drawable, like a mini-hash of
the draw->eid. Ugly ugly...

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

Re: [Mesa-dev] [PATCH 2/2] loader_dri3: Variant 2: Wait for pending swaps to complete before drawable_fini.

[Mario Kleiner]

On Fri, May 4, 2018 at 6:45 PM, Mike Lothian <m...@fireburn.co.uk> wrote:
> Hi
>
> The first hunk doesn't apply, the other 3 gives this with GCC 8.1
>

Oops, the perils of applying debug patches on top of debug patches...

Can you add a...

#include 

at the top of the file, e.g, after '#include 

 #include 
 #include 
 #include 
-
+#include 
 #include 
 #include 
 #include 

Then it should compile, albeit with some format warnings, but those
shouldn't affect the outcome.
-mario

>
> ../mesa-/src/loader/loader_dri3_helper.c: In function
> ‘dri3_handle_present_event’:
> ../mesa-/src/loader/loader_dri3_helper.c:376:13: error: implicit
> declaration of function ‘printf’
> [-Werror=implicit-function-declaration]
>  printf("ORPHAN-C: %d x %d, drawable %d: recv %u vs send_sbc 
> %lu\n",
>  ^~
> ../mesa-/src/loader/loader_dri3_helper.c:376:13: warning:
> incompatible implicit declaration of built-in function ‘printf’
> ../mesa-/src/loader/loader_dri3_helper.c:376:13: note: include
> ‘’ or provide a declaration of ‘printf’
> ../mesa-/src/loader/loader_dri3_helper.c:39:1:
> +#include 
>
> ../mesa-/src/loader/loader_dri3_helper.c:376:13:
>  printf("ORPHAN-C: %d x %d, drawable %d: recv %u vs send_sbc 
> %lu\n",
>  ^~
> ../mesa-/src/loader/loader_dri3_helper.c:376:75: warning: format
> ‘%lu’ expects argument of type ‘long unsigned int’, but argument 6 has
> type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
>  printf("ORPHAN-C: %d x %d, drawable %d: recv %u vs send_sbc 
> %lu\n",
>  ~~^
>  %llu
> ../mesa-/src/loader/loader_dri3_helper.c:378:20:
> draw->send_sbc);
> ~~
> ../mesa-/src/loader/loader_dri3_helper.c:430:10: warning:
> incompatible implicit declaration of built-in function ‘printf’
>   printf("ORPHAN-I: %d x %d, drawable %d: recv %u vs send_sbc %lu\n",
>   ^~
> ../mesa-/src/loader/loader_dri3_helper.c:430:10: note: include
> ‘’ or provide a declaration of ‘printf’
> ../mesa-/src/loader/loader_dri3_helper.c:430:72: warning: format
> ‘%lu’ expects argument of type ‘long unsigned int’, but argument 6 has
> type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
>   printf("ORPHAN-I: %d x %d, drawable %d: recv %u vs send_sbc %lu\n",
>   ~~^
>   %llu
> ../mesa-/src/loader/loader_dri3_helper.c:432:17:
>  draw->send_sbc);
>  ~~
> ../mesa-/src/loader/loader_dri3_helper.c: In function
> ‘dri3_update_drawable’:
> ../mesa-/src/loader/loader_dri3_helper.c:1454:7: warning:
> incompatible implicit declaration of built-in function ‘printf’
>printf("INIT: wxh = %d x %d, drawable %d eid %d\n",
> draw->width, draw->height, draw->drawable, draw->eid);
>^~
> ../mesa-/src/loader/loader_dri3_helper.c:1454:7: note: include
> ‘’ or provide a declaration of ‘printf’
> cc1: some warnings being treated as errors
>
> Cheers
>
> Mike
>
> On 4 May 2018 at 14:45, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
>> See previous patch in series for explanation of the problem.
>>
>> This method avoids a blocking loader_dri3_swapbuffer_barrier() call
>> whenever a GL contexts drawables are changed via glXMakeCurrent et al.
>>
>> Instead it filters out the "orphaned" PresentNotify events from
>> previous incarnations of the loader_dri3_drawable. This should deal
>> correctly with PixmapInvalidate, PixmapPresentCompleteNotify and
>> MscCompleteNotify events, but i don't know a way to filter out
>> WindowConfigureNotify events, or if it even matters to filter them.
>>
>> This PoC one is only meaningful if the first patch is omitted, and
>> shows the spurious "ORPHAN" printouts which would hang KDE plasmashell
>> if not filtered out.
>>
>> Test from a terminal: killall plasmashell; plasmashell
>> Wiggly the mouse around, click etc. on the KDE taskbar, K-Menu,
>> system tray icons, trigger volume/brightness feedback widgets
>> to provoke the occassional ORPHAN event.
>>
>> Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
>> Cc: xorg-de...@lists.x.org
>> Cc: dan...@fooishbar.org
>> Cc: eero.t.tammi...@intel.com
>> Cc: m...@fireburn.

Re: [Mesa-dev] [PATCH 1/2] loader_dri3: Wait for pending swaps to complete before drawable_fini.

[Mario Kleiner]

On Fri, May 4, 2018 at 6:31 PM, Mike Lothian <m...@fireburn.co.uk> wrote:
> Hi
>
> I'm still seeing the freeze in the Steam client with this patch
>
> Just about to test the other one
>

Thanks for testing. So the plasmashell hang is gone, right?
Maybe the steam issue is a different bug. With *only* patch 2/2
applied, seing ORPHAN printouts would hint at a similar problem,
absence of them would probably mean something else.

-mario

> Mike
>
> On 4 May 2018 at 17:17, Mike Lothian <m...@fireburn.co.uk> wrote:
>> Hi Mario
>>
>> Again thanks for looking into this issue :D
>>
>> Tested-by: Mike Lothian <m...@fireburn.co.uk>
>>
>> I'll give the other patch a whirl now
>>
>> Cheers
>>
>> Mike
>>
>> On 4 May 2018 at 14:45, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
>>> Before destroying the loader_dri3_drawable, make sure all pending
>>> swaps for it have completed. This guides against the following scenario,
>>> which happens, e.g., with KDE Plasma-5's plasmashell (which uses
>>> QT-5's QtGui/QtQuick for rendering), when it repaints multiple
>>> UI elements, each represented by its own Window/GLXDrawable, using
>>> one common GLXContext for all GLXDrawable's:
>>>
>>> 1. glXMakeCurrent(dpy, drawable1, context);
>>> 2. glXXX render to drawable1
>>> 3. glXSwapBuffers(dpy, drawable1); #1
>>> 4. glXMakeCurrent(dpy, drawable2, context);
>>> 5. glXXX render to drawable2
>>> 6. glXSwapBuffers(dpy, drawable2);
>>> // While the swap #1 is still pending for drawable1:
>>> 7. glXMakeCurrent(dpy, drawable1, context);
>>> 8. glXXX render to drawable1
>>> 9. glXSwapBuffers(dpy, drawable1);
>>>
>>> Binding a different drawable2 to the same context via glXMakeCurrent
>>> will cause its previous drawable1 to be released (cfe. dri3_bind_context
>>> -> driReleaseDrawables), which in turn calls loader_dri3_drawable_fini().
>>> This unselects for Present notify event delivery on the associated
>>> X-Window and loses all dri3 related state. If drawable1 is selected for
>>> the context again [7], a new incarnation of loader_dri3_drawable is
>>> created in dri3_bind_context->driFetchDrawable->dri3_create_drawable->
>>> loader_dri3_drawable_init(), which again selects for Present notify
>>> event delivery for the underlying X-Window, but the new incarnation lost
>>> all state wrt. to previous rendering and swaps. The server now delivers
>>> PresentPixmapIdle and PresentPixmapComplete events from the completed
>>> previous swapbuffers call #1 [3] to the new loader_dri3_drawable, which
>>> doesn't expect those. One problem is that the new incarnation has a
>>> draw->send_sbc == 0, but now receives PresentPixmapComplete events with
>>> sbc's > 0, therefore updating draw->recv_sbc to > 0 in
>>> dri3_handle_present_event(). The draw->recv_sbc > draw_send_sbc is
>>> misinterpreted as sbc wraparound, triggers recv_sbc wraparound handling
>>> and ends up with a very large draw->recv_sbc. During the next swapbuffers
>>> call [9], the totally wrong recv_sbc is used for calculating the target_msc
>>> for the PresentPixmap request, leading to a target_msc billions of vblanks
>>> in the future, leading to a swap that never completes and thereby frozen UI
>>> and hang of the client.
>>>
>>> Make sure that a loader_dri3_drawable can only be destroyed after all
>>> its pending swaps have completed, to prevent misdelivery of PresentNotify
>>> events to the right X-Window, but the wrong incarnation of the associated
>>> loader_dri3_drawable.
>>>
>>> Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
>>> Cc: xorg-de...@lists.x.org
>>> Cc: dan...@fooishbar.org
>>> Cc: eero.t.tammi...@intel.com
>>> Cc: m...@fireburn.co.uk
>>> ---
>>>  src/loader/loader_dri3_helper.c | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/src/loader/loader_dri3_helper.c 
>>> b/src/loader/loader_dri3_helper.c
>>> index 6bb11c4..7bd79af 100644
>>> --- a/src/loader/loader_dri3_helper.c
>>> +++ b/src/loader/loader_dri3_helper.c
>>> @@ -234,6 +234,9 @@ loader_dri3_drawable_fini(struct loader_dri3_drawable 
>>> *draw)
>>>  {
>>> int i;
>>>
>>> +   if (draw->special_event)
>>> +  loader_dri3_swapbuffer_barrier(draw);
>>> +
>>> draw->ext->core->destroyDrawable(draw->dri_drawable);
>>>
>>> for (i = 0; i < ARRAY_SIZE(draw->buffers); i++) {
>>> --
>>> 2.7.4
>>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] loader_dri3: Wait for pending swaps to complete before drawable_fini.

[Mario Kleiner]

Before destroying the loader_dri3_drawable, make sure all pending
swaps for it have completed. This guides against the following scenario,
which happens, e.g., with KDE Plasma-5's plasmashell (which uses
QT-5's QtGui/QtQuick for rendering), when it repaints multiple
UI elements, each represented by its own Window/GLXDrawable, using
one common GLXContext for all GLXDrawable's:

1. glXMakeCurrent(dpy, drawable1, context);
2. glXXX render to drawable1
3. glXSwapBuffers(dpy, drawable1); #1
4. glXMakeCurrent(dpy, drawable2, context);
5. glXXX render to drawable2
6. glXSwapBuffers(dpy, drawable2);
// While the swap #1 is still pending for drawable1:
7. glXMakeCurrent(dpy, drawable1, context);
8. glXXX render to drawable1
9. glXSwapBuffers(dpy, drawable1);

Binding a different drawable2 to the same context via glXMakeCurrent
will cause its previous drawable1 to be released (cfe. dri3_bind_context
-> driReleaseDrawables), which in turn calls loader_dri3_drawable_fini().
This unselects for Present notify event delivery on the associated
X-Window and loses all dri3 related state. If drawable1 is selected for
the context again [7], a new incarnation of loader_dri3_drawable is
created in dri3_bind_context->driFetchDrawable->dri3_create_drawable->
loader_dri3_drawable_init(), which again selects for Present notify
event delivery for the underlying X-Window, but the new incarnation lost
all state wrt. to previous rendering and swaps. The server now delivers
PresentPixmapIdle and PresentPixmapComplete events from the completed
previous swapbuffers call #1 [3] to the new loader_dri3_drawable, which
doesn't expect those. One problem is that the new incarnation has a
draw->send_sbc == 0, but now receives PresentPixmapComplete events with
sbc's > 0, therefore updating draw->recv_sbc to > 0 in
dri3_handle_present_event(). The draw->recv_sbc > draw_send_sbc is
misinterpreted as sbc wraparound, triggers recv_sbc wraparound handling
and ends up with a very large draw->recv_sbc. During the next swapbuffers
call [9], the totally wrong recv_sbc is used for calculating the target_msc
for the PresentPixmap request, leading to a target_msc billions of vblanks
in the future, leading to a swap that never completes and thereby frozen UI
and hang of the client.

Make sure that a loader_dri3_drawable can only be destroyed after all
its pending swaps have completed, to prevent misdelivery of PresentNotify
events to the right X-Window, but the wrong incarnation of the associated
loader_dri3_drawable.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: xorg-de...@lists.x.org
Cc: dan...@fooishbar.org
Cc: eero.t.tammi...@intel.com
Cc: m...@fireburn.co.uk
---
 src/loader/loader_dri3_helper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 6bb11c4..7bd79af 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -234,6 +234,9 @@ loader_dri3_drawable_fini(struct loader_dri3_drawable *draw)
 {
int i;
 
+   if (draw->special_event)
+  loader_dri3_swapbuffer_barrier(draw);
+
draw->ext->core->destroyDrawable(draw->dri_drawable);
 
for (i = 0; i < ARRAY_SIZE(draw->buffers); i++) {
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/2] loader_dri3: Variant 2: Wait for pending swaps to complete before drawable_fini.

[Mario Kleiner]

See previous patch in series for explanation of the problem.

This method avoids a blocking loader_dri3_swapbuffer_barrier() call
whenever a GL contexts drawables are changed via glXMakeCurrent et al.

Instead it filters out the "orphaned" PresentNotify events from
previous incarnations of the loader_dri3_drawable. This should deal
correctly with PixmapInvalidate, PixmapPresentCompleteNotify and
MscCompleteNotify events, but i don't know a way to filter out
WindowConfigureNotify events, or if it even matters to filter them.

This PoC one is only meaningful if the first patch is omitted, and
shows the spurious "ORPHAN" printouts which would hang KDE plasmashell
if not filtered out.

Test from a terminal: killall plasmashell; plasmashell
Wiggly the mouse around, click etc. on the KDE taskbar, K-Menu,
system tray icons, trigger volume/brightness feedback widgets
to provoke the occassional ORPHAN event.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: xorg-de...@lists.x.org
Cc: dan...@fooishbar.org
Cc: eero.t.tammi...@intel.com
Cc: m...@fireburn.co.uk
---
 src/loader/loader_dri3_helper.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 7bd79af..123a996 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -234,6 +234,10 @@ loader_dri3_drawable_fini(struct loader_dri3_drawable 
*draw)
 {
int i;
 
+   printf("FINI: wxh = %d x %d, drawable %d eid %d recv_sbc %lu, send_sbc %lu 
PENDING %lu\n",
+  draw->width, draw->height, draw->drawable, draw->eid, 
draw->recv_sbc, draw->send_sbc,
+  draw->send_sbc - draw->recv_sbc);
+
if (draw->special_event)
   loader_dri3_swapbuffer_barrier(draw);
 
@@ -373,6 +377,15 @@ dri3_handle_present_event(struct loader_dri3_drawable 
*draw,
* checking for wrap.
*/
   if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP) {
+ /* Filter out orphan events sent for a previous incarnation of draw. 
*/
+ if (!(draw->send_sbc & 0xLL) &&
+ ce->serial > draw->send_sbc) {
+printf("ORPHAN-C: %d x %d, drawable %d: recv %u vs send_sbc %lu\n",
+   draw->width, draw->height, draw->drawable, ce->serial,
+   draw->send_sbc);
+break;
+ }
+
  draw->recv_sbc = (draw->send_sbc & 0xLL) | ce->serial;
  if (draw->recv_sbc > draw->send_sbc)
 draw->recv_sbc -= 0x1;
@@ -418,6 +431,15 @@ dri3_handle_present_event(struct loader_dri3_drawable 
*draw,
   xcb_present_idle_notify_event_t *ie = (void *) ge;
   int b;
 
+  /* Filter out orphan events sent for a previous incarnation of draw. */
+  if (!(draw->send_sbc & 0xLL) &&
+  ie->serial > draw->send_sbc) {
+ printf("ORPHAN-I: %d x %d, drawable %d: recv %u vs send_sbc %lu\n",
+draw->width, draw->height, draw->drawable, ie->serial,
+draw->send_sbc);
+ break;
+  }
+
   for (b = 0; b < ARRAY_SIZE(draw->buffers); b++) {
  struct loader_dri3_buffer *buf = draw->buffers[b];
 
@@ -1435,6 +1457,8 @@ dri3_update_drawable(__DRIdrawable *driDrawable,
  xcb_unregister_for_special_event(draw->conn, draw->special_event);
  draw->special_event = NULL;
   }
+
+  printf("INIT: wxh = %d x %d, drawable %d eid %d\n", draw->width, 
draw->height, draw->drawable, draw->eid);
}
dri3_flush_present_events(draw);
mtx_unlock(>mtx);
-- 
2.7.4

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

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

[Mario Kleiner]

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

Re: [Mesa-dev] [PATCH 3/3] egl/x11: Handle both depth 30 formats for eglCreateImage().

[Mario Kleiner]

On 04/12/2018 07:43 PM, Ilia Mirkin wrote:

On Thu, Apr 12, 2018 at 1:18 PM, Mario Kleiner
<mario.kleiner...@gmail.com> wrote:

X11 Prime renderoffload is another unsolved problem with nouveau depth 30.
Currently we get swapped red-blue with intel + nvidia. We could extend the
buffer creation code to convert nouveau's rgba format into the bgra format
wanted by intel or amd display gpu's during the blitImage call for
converting the tiled renderbuffer to the linear buffer, like i try for the
wayland+egl case. But we'd need to know what the display gpu wants. Haven't
looked into that.


FWIW the NVIDIA hardware is perfectly happy to render into BGR10_A2.
Just can't display it.

   -ilia



Yes, but due to one of your earlier depth 30 commits we only expose 
formats with PIPE_BIND_DISPLAY_TARGET, so that ability is hidden from 
driver independent code like the EGL platform code, GLX etc. to prevent 
exposing formats that the hw can't display.


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

Re: [Mesa-dev] [PATCH 3/3] egl/x11: Handle both depth 30 formats for eglCreateImage().

[Mario Kleiner]

On 04/10/2018 06:49 PM, Ilia Mirkin wrote:

On Tue, Apr 10, 2018 at 4:42 AM, Michel Dänzer <mic...@daenzer.net> wrote:

On 2018-04-10 10:22 AM, Mario Kleiner wrote:

On 04/09/2018 12:12 PM, Michel Dänzer wrote:

On 2018-04-06 08:56 PM, Mario Kleiner wrote:

I'm interested in the full xdpyinfo *at screen depth 30*, in particular
whether it lists only one variant of depth 30 visuals. If so, one
possibility for a kludge would be to just look at any depth 30 visual.


Ok, the fresh v2 patch implements that kludge. This one retested to work
on nouveau, ati, intel.

On intel and nouveau we only get one channel mask for depth 30 visuals
in xdpyinfo. On amd we get both masks for xrgb2101010 and xbgr2101010,
as the amd gallium drivers expose both formats, but the ordering is
xrgb2101010 first, so that's fine when picking the first depth 30 visual
to get the channel mask for decisions.


Hmm, that sounds fragile though when there are both variants; is there
any guarantee they can't appear in the opposite order?


Afaics the rough order is determined by how the state tracker builds the 
list of __DRIconfig's in


mesa/src/gallium/state_trackers/dri/dri_screen.c:dri_fill_in_modes(),

ie. the ordering in the mesa_formats[] table at the top of that 
function. MESA_FORMAT_B10G10R10A2_UNORM and 
MESA_FORMAT_B10G10R10X2_UNORM are before MESA_FORMAT_R10G10B10A2_UNORM 
and MESA_FORMAT_R10G10B10X2_UNORM, and that is a requirement of the 
implementation that BGR[A/X] always comes before RGB[A/X].


The server processes those in the order they were generated when 
building visuals: xserver/glx/glxscreens.c:__glXScreenInit() converts 
pGlxScreen->fbconfigs retrieved from the Mesa driver into visuals. That 
fbconfigs list is always traversed in forward order.


So this should hopefully guarantee that for a given depth we always get 
the bgr10 formats we want before the rgb10 formats, and the order stays 
the way we want, with the desired bgr10 format as first depth 30 format.


That said, looking at line 388 of xserver/glx/glxscreens.c, i wonder if 
that check "if (depth == pScreen->visuals[i].nplanes)" is actually 
sufficient? Maybe we should check for compatible channel masks there and 
reject fbconfigs which don't find an existing X visual with matching 
channel mask? We do check the channel mask in pickFBConfig() when 
choosing FBConfigs for existing X Visuals in pass 1, but not when adding 
new X Visuals for FBConfigs that don't have existing X Visuals in pass 
2. That might get rid of the ambiguity and prevent exposing visuals that 
the ddx/kms driver won't be able display properly?




It seems like nouveau is stirring a bit of a hornet's nest here.
Unfortunately there's not a whole lot I can do about hw scanout format
support (rgb10x2 only, no bgr10x2 support until Kepler), but is there
something else that the DDX and/or mesa driver should be doing to
avoid some of this pain?

Should we get the *other* ddx's to avoid exposing both masks?


I think the ddx's only expose one mask per ddx, and seing both might be 
a X-Server problem (see above)? Maybe it could be beneficial if we 
stopped the amd gallium drivers from marking the R10G10B10[X/A]2 configs 
as PIPE_BIND_DISPLAY_TARGET if there isn't a use case for which they do 
that, apart from the hw/driver being capable of supporting it? Intel 
only supports bgrx ordering, nouveau only rgbx, amd both.


I have some half-finished wayland egl patches where it might help for 
the multi-gpu prime renderoffload case to feed wl_buffers in a format 
optimal for display on the server gpu instead of feeding them in a 
format that can be displayed by the server gpu but requires an extra 
copy. Not sure yet, half finished/half tested stuff, may not work out at 
all in the end.


X11 Prime renderoffload is another unsolved problem with nouveau depth 
30. Currently we get swapped red-blue with intel + nvidia. We could 
extend the buffer creation code to convert nouveau's rgba format into 
the bgra format wanted by intel or amd display gpu's during the 
blitImage call for converting the tiled renderbuffer to the linear 
buffer, like i try for the wayland+egl case. But we'd need to know what 
the display gpu wants. Haven't looked into that.


-mario



   -ilia


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

Re: [Mesa-dev] [PATCH 3/3] egl/x11: Handle both depth 30 formats for eglCreateImage().

[Mario Kleiner]

On 04/09/2018 12:12 PM, Michel Dänzer wrote:

On 2018-04-06 08:56 PM, Mario Kleiner wrote:

On 04/06/2018 06:41 PM, Michel Dänzer wrote:

On 2018-04-06 06:18 PM, Mario Kleiner wrote:

On Fri, Apr 6, 2018 at 12:01 PM, Michel Dänzer <mic...@daenzer.net>
wrote:

On 2018-03-27 07:53 PM, Daniel Stone wrote:

On 12 March 2018 at 20:45, Mario Kleiner
<mario.kleiner...@gmail.com> wrote:

We need to distinguish if a backing pixmap of a window is
XRGB2101010 or XBGR2101010, as different gpu hw supports
different formats. NVidia hw prefers XBGR, whereas AMD and
Intel are happy with XRGB.

We use the red channel mask of the visual to distinguish at
depth 30, but because we can't easily get the associated
visual of a Pixmap, we use the visual of the x-screens root
window instead as a proxy.

This fixes desktop composition of color depth 30 windows
when the X11 compositor uses EGL.


I have no reason to doubt your testing, so this patch is:
Acked-by: Daniel Stone <dani...@collabora.com>

But it does rather fill me with trepidation, given that X11 Pixmaps
are supposed to be a dumb 'bag of bits', doing nothing else than
providing the same number and size of channels to the actual client
data for the Visual associated with the Window.


As far as X11 is concerned, the number of channels and their sizes
don't
even matter; a pixmap is simply a container for an unsigned integer
of n
bits (where n is the pixmap depth) per pixel, with no inherent meaning
attached to those values.

That said, I'm not sure this is true for EGL as well. But even if it
isn't, there would have to be another mechanism to determine the
format,
e.g. a config associated with the EGL pixmap. The pixmap doesn't even
necessarily have the same depth as the root window, so using the
latter's visual doesn't make much sense.


Hi Michel. I thought with this patch i was implementing what you
proposed earlier as a heuristic on how to get around the "pixmaps
don't have an inherent format, only a depth" problem?


Do you have a pointer to that discussion?


Ok, apologies, i think i was just taking your comment too far as an
inspiration. The best i can find in my inbox atm. is this message of
yours from 24th November 2017 10:44 AM in a mesa-dev thread "Re:
[Mesa-dev] 10-bit Mesa/Gallium support":

"Apologies for the badly formatted followup before, let's try that again:

On 2017-11-23 07:31 PM, Mario Kleiner wrote:


3. In principle the clean solution for nouveau would be to upgrade the
ddx to drmAddFB2 ioctl, and use xbgr2101010 scanout to support
everything back to nv50+, but everything we have in X or Wayland is
meant for xrgb2101010 not xbgr2101010. And we run into ambiguities of
what, e.g., a depth 30 pixmap means in some extensions like
glx_texture_form_pixmap.


A pixmap itself never has a format per se, it's just a container for an
n-bit integer value per pixel (where n is the pixmap depth). A
compositor using GLX_EXT_texture_from_pixmap has to determine the format
from the corresponding window's visual.
"

There's nothing in there that suggests my root window solution.
I guess i thought given that we can not get the visual of the window 
corresponding to the pixmap, let's find some window which is a good enough 
proxy for onscreen windows with associated depth 30 pixmaps on the same 
x-screen.


A pixmap isn't necessarily associated with any window.



My (possibly inaccurate) understanding is that one can only create a
depth 30 pixmap if the x-screen runs at depth >= 30. It only exposes
depth 30 as supported pixmap format (xdpyinfo) if xorg.conf
DefaultDepth 30 is selected, whereas other depths like
1,4,8,15,16,24,32 are always supported at default depth 24.


That sounds like an X server issue. Just like 32, there's no fundamental
reason a pixmap couldn't have depth 30 despite the screen depth being lower.

Out of curiosity, can you share the output of xdpyinfo with nouveau at
depth 30?


[...]


At least i don't remember seeing any "depth 30, ..." line ever on any 
driver+gpu combo if i run X at default depth 24?


I'm not questioning that's currently the case, I'm saying there's no
particular reason for it, so expect it to change at some point.



Ah ok, thanks for the explanation.



I'm interested in the full xdpyinfo *at screen depth 30*, in particular
whether it lists only one variant of depth 30 visuals. If so, one
possibility for a kludge would be to just look at any depth 30 visual.



Ok, the fresh v2 patch implements that kludge. This one retested to work 
on nouveau, ati, intel.


On intel and nouveau we only get one channel mask for depth 30 visuals 
in xdpyinfo. On amd we get both masks for xrgb2101010 and xbgr2101010, 
as the amd gallium drivers expose both formats, but the ordering is 
xrgb2101010 first, so that's fine when picking the first depth 30 visual 
to get the channel mask for decisions.





The basic problem with EGL based compositing is that for eglCreate

[Mesa-dev] [PATCH] egl/x11: Handle both depth 30 formats for eglCreateImage(). (v2)

[Mario Kleiner]

We need to distinguish if the backing storage of a pixmap
is XRGB2101010 or XBGR2101010, as different gpu hw supports
different formats. NVidia hw prefers XBGR, whereas AMD and
Intel are happy with XRGB.

Use the red channel mask of the first depth 30 visual of
the x-screen to distinguish which hw format to choose.

This fixes desktop composition of color depth 30 windows
when the X11 compositor uses EGL.

v2: Switch from using the visual of the root window to simply
using the first depth 30 visual for the x-screen, as testing
shows that each driver only exports either xrgb ordering or
xbgr ordering for the channel masks of its depth 30 visuals,
so this should be unambiguous and avoid trouble if X ever
supports depth 30 pixmaps on screens with a non-depth 30 root
window visual. This per Michels suggestion.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: Michel Dänzer <michel.daen...@amd.com>
---
 src/egl/drivers/dri2/egl_dri2.h  |  7 +++
 src/egl/drivers/dri2/platform_x11.c  | 36 +++-
 src/egl/drivers/dri2/platform_x11_dri3.c | 12 +++
 3 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index adabc52..7e7032d 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -413,6 +413,8 @@ EGLBoolean
 dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp);
 void
 dri2_teardown_x11(struct dri2_egl_display *dri2_dpy);
+unsigned int
+dri2_x11_get_red_mask_for_depth(struct dri2_egl_display *dri2_dpy, int depth);
 #else
 static inline EGLBoolean
 dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp)
@@ -421,6 +423,11 @@ dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp)
 }
 static inline void
 dri2_teardown_x11(struct dri2_egl_display *dri2_dpy) {}
+static inline unsigned int
+dri2_x11_get_red_mask_for_depth(struct dri2_egl_display *dri2_dpy, int depth)
+{
+   return 0;
+}
 #endif
 
 #ifdef HAVE_DRM_PLATFORM
diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index 6c287b4..47dd268 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -209,6 +209,36 @@ get_xcb_screen(xcb_screen_iterator_t iter, int screen)
 return NULL;
 }
 
+static xcb_visualtype_t *
+get_xcb_visualtype_for_depth(struct dri2_egl_display *dri2_dpy, int depth)
+{
+   xcb_visualtype_iterator_t visual_iter;
+   xcb_screen_t *screen = dri2_dpy->screen;
+   xcb_depth_iterator_t depth_iter = 
xcb_screen_allowed_depths_iterator(screen);
+
+   for (; depth_iter.rem; xcb_depth_next(_iter)) {
+  if (depth_iter.data->depth != depth)
+ continue;
+
+  visual_iter = xcb_depth_visuals_iterator(depth_iter.data);
+  if (visual_iter.rem)
+ return visual_iter.data;
+   }
+
+   return NULL;
+}
+
+/* Get red channel mask for given depth. */
+unsigned int
+dri2_x11_get_red_mask_for_depth(struct dri2_egl_display *dri2_dpy, int depth)
+{
+   unsigned int red_mask = 0;
+   xcb_visualtype_t *visual = get_xcb_visualtype_for_depth(dri2_dpy, depth);
+   if (visual)
+  red_mask = visual->red_mask;
+
+   return red_mask;
+}
 
 /**
  * Called via eglCreateWindowSurface(), drv->API.CreateWindowSurface().
@@ -1050,7 +1080,11 @@ dri2_create_image_khr_pixmap(_EGLDisplay *disp, 
_EGLContext *ctx,
   format = __DRI_IMAGE_FORMAT_XRGB;
   break;
case 30:
-  format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  /* Different preferred formats for different hw */
+  if (dri2_x11_get_red_mask_for_depth(dri2_dpy, 30) == 0x3ff)
+ format = __DRI_IMAGE_FORMAT_XBGR2101010;
+  else
+ format = __DRI_IMAGE_FORMAT_XRGB2101010;
   break;
case 32:
   format = __DRI_IMAGE_FORMAT_ARGB;
diff --git a/src/egl/drivers/dri2/platform_x11_dri3.c 
b/src/egl/drivers/dri2/platform_x11_dri3.c
index a41e401..6c522ae 100644
--- a/src/egl/drivers/dri2/platform_x11_dri3.c
+++ b/src/egl/drivers/dri2/platform_x11_dri3.c
@@ -40,7 +40,7 @@
 #include "loader_dri3_helper.h"
 
 static uint32_t
-dri3_format_for_depth(uint32_t depth)
+dri3_format_for_depth(struct dri2_egl_display *dri2_dpy, uint32_t depth)
 {
switch (depth) {
case 16:
@@ -48,7 +48,11 @@ dri3_format_for_depth(uint32_t depth)
case 24:
   return __DRI_IMAGE_FORMAT_XRGB;
case 30:
-  return __DRI_IMAGE_FORMAT_XRGB2101010;
+  /* Different preferred formats for different hw */
+  if (dri2_x11_get_red_mask_for_depth(dri2_dpy, 30) == 0x3ff)
+ return __DRI_IMAGE_FORMAT_XBGR2101010;
+  else
+ return __DRI_IMAGE_FORMAT_XRGB2101010;
case 32:
   return __DRI_IMAGE_FORMAT_ARGB;
default:
@@ -293,7 +297,7 @@ dri3_create_image_khr_pixmap(_EGLDisplay *disp, _EGLContext 
*ctx,
   return NULL;
}
 
-   format = dri3_format_for_depth(bp_reply->depth);
+   format = dri3_format_for_depth(dri2_

Re: [Mesa-dev] [PATCH 3/3] egl/x11: Handle both depth 30 formats for eglCreateImage().

[Mario Kleiner]

On 04/06/2018 06:41 PM, Michel Dänzer wrote:

On 2018-04-06 06:18 PM, Mario Kleiner wrote:

On Fri, Apr 6, 2018 at 12:01 PM, Michel Dänzer <mic...@daenzer.net> wrote:

On 2018-03-27 07:53 PM, Daniel Stone wrote:

On 12 March 2018 at 20:45, Mario Kleiner <mario.kleiner...@gmail.com> wrote:

We need to distinguish if a backing pixmap of a window is
XRGB2101010 or XBGR2101010, as different gpu hw supports
different formats. NVidia hw prefers XBGR, whereas AMD and
Intel are happy with XRGB.

We use the red channel mask of the visual to distinguish at
depth 30, but because we can't easily get the associated
visual of a Pixmap, we use the visual of the x-screens root
window instead as a proxy.

This fixes desktop composition of color depth 30 windows
when the X11 compositor uses EGL.


I have no reason to doubt your testing, so this patch is:
Acked-by: Daniel Stone <dani...@collabora.com>

But it does rather fill me with trepidation, given that X11 Pixmaps
are supposed to be a dumb 'bag of bits', doing nothing else than
providing the same number and size of channels to the actual client
data for the Visual associated with the Window.


As far as X11 is concerned, the number of channels and their sizes don't
even matter; a pixmap is simply a container for an unsigned integer of n
bits (where n is the pixmap depth) per pixel, with no inherent meaning
attached to those values.

That said, I'm not sure this is true for EGL as well. But even if it
isn't, there would have to be another mechanism to determine the format,
e.g. a config associated with the EGL pixmap. The pixmap doesn't even
necessarily have the same depth as the root window, so using the
latter's visual doesn't make much sense.


Hi Michel. I thought with this patch i was implementing what you
proposed earlier as a heuristic on how to get around the "pixmaps
don't have an inherent format, only a depth" problem?


Do you have a pointer to that discussion?



Ok, apologies, i think i was just taking your comment too far as an 
inspiration. The best i can find in my inbox atm. is this message of 
yours from 24th November 2017 10:44 AM in a mesa-dev thread "Re: 
[Mesa-dev] 10-bit Mesa/Gallium support":


"Apologies for the badly formatted followup before, let's try that again:

On 2017-11-23 07:31 PM, Mario Kleiner wrote:
>
> 3. In principle the clean solution for nouveau would be to upgrade the
> ddx to drmAddFB2 ioctl, and use xbgr2101010 scanout to support
> everything back to nv50+, but everything we have in X or Wayland is
> meant for xrgb2101010 not xbgr2101010. And we run into ambiguities of
> what, e.g., a depth 30 pixmap means in some extensions like
> glx_texture_form_pixmap.

A pixmap itself never has a format per se, it's just a container for an
n-bit integer value per pixel (where n is the pixmap depth). A
compositor using GLX_EXT_texture_from_pixmap has to determine the format
from the corresponding window's visual.


--
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
"

There's nothing in there that suggests my root window solution.
I guess i thought given that we can not get the visual of the window 
corresponding to the pixmap, let's find some window which is a good 
enough proxy for onscreen windows with associated depth 30 pixmaps on 
the same x-screen.





My (possibly inaccurate) understanding is that one can only create a
depth 30 pixmap if the x-screen runs at depth >= 30. It only exposes
depth 30 as supported pixmap format (xdpyinfo) if xorg.conf
DefaultDepth 30 is selected, whereas other depths like
1,4,8,15,16,24,32 are always supported at default depth 24.


That sounds like an X server issue. Just like 32, there's no fundamental
reason a pixmap couldn't have depth 30 despite the screen depth being lower.

Out of curiosity, can you share the output of xdpyinfo with nouveau at
depth 30?



Will have to do that later at the machine. But unless i misremember that 
as well, xdpyinfo always gives me this, if i run at DefaultDepth 24:


"number of supported pixmap formats:7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:minimum 8, maximum 255
"

At least i don't remember seeing any "depth 30, ..." line ever on any 
driver+gpu combo if i run X at default depth 24?





Iff depth 30 is selected, then the root window has depth 30, and a depth 30
visual. If each driver only exports one channel ordering for depth 30,
then the channel ordering of any pixmaps associated drawable should be
the same as the one of the roo

Re: [Mesa-dev] [PATCH 3/3] egl/x11: Handle both depth 30 formats for eglCreateImage().

[Mario Kleiner]

On Fri, Apr 6, 2018 at 12:01 PM, Michel Dänzer <mic...@daenzer.net> wrote:
> On 2018-03-27 07:53 PM, Daniel Stone wrote:
>> On 12 March 2018 at 20:45, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
>>> We need to distinguish if a backing pixmap of a window is
>>> XRGB2101010 or XBGR2101010, as different gpu hw supports
>>> different formats. NVidia hw prefers XBGR, whereas AMD and
>>> Intel are happy with XRGB.
>>>
>>> We use the red channel mask of the visual to distinguish at
>>> depth 30, but because we can't easily get the associated
>>> visual of a Pixmap, we use the visual of the x-screens root
>>> window instead as a proxy.
>>>
>>> This fixes desktop composition of color depth 30 windows
>>> when the X11 compositor uses EGL.
>>
>> I have no reason to doubt your testing, so this patch is:
>> Acked-by: Daniel Stone <dani...@collabora.com>
>>
>> But it does rather fill me with trepidation, given that X11 Pixmaps
>> are supposed to be a dumb 'bag of bits', doing nothing else than
>> providing the same number and size of channels to the actual client
>> data for the Visual associated with the Window.
>
> As far as X11 is concerned, the number of channels and their sizes don't
> even matter; a pixmap is simply a container for an unsigned integer of n
> bits (where n is the pixmap depth) per pixel, with no inherent meaning
> attached to those values.
>
> That said, I'm not sure this is true for EGL as well. But even if it
> isn't, there would have to be another mechanism to determine the format,
> e.g. a config associated with the EGL pixmap. The pixmap doesn't even
> necessarily have the same depth as the root window, so using the
> latter's visual doesn't make much sense.
>

Hi Michel. I thought with this patch i was implementing what you
proposed earlier as a heuristic on how to get around the "pixmaps
don't have an inherent format, only a depth" problem?

My (possibly inaccurate) understanding is that one can only create a
depth 30 pixmap if the x-screen runs at depth >= 30. It only exposes
depth 30 as supported pixmap format (xdpyinfo) if xorg.conf
DefaultDepth 30 is selected, whereas other depths like
1,4,8,15,16,24,32 are always supported at default depth 24. Iff depth
30 is selected, then the root window has depth 30, and a depth 30
visual. If each driver only exports one channel ordering for depth 30,
then the channel ordering of any pixmaps associated drawable should be
the same as the one of the root window.

Wrong thinking?
-mario


>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] wayland-drm: Expose server-side xbgr2101010 and abgr2101010 formats.

[Mario Kleiner]

On Tue, Mar 27, 2018 at 7:45 PM, Daniel Stone <dan...@fooishbar.org> wrote:
> Hi Ilia,
>
> On 14 March 2018 at 19:02, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>> On Tue, Mar 13, 2018 at 5:30 AM, Daniel Stone <dan...@fooishbar.org> wrote:
>>> On 12 March 2018 at 20:45, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
>>>> This way the wayland server can signal support for these formats
>>>> to wayland EGL clients. This is currently used by nouveau for 10
>>>> bpc support.
>>>>
>>>> Tested with glmark2-wayland and glmark2-es2-wayland under weston
>>>> to now expose 10 bpc EGL configs under nouveau.
>>>
>>> Do we need a way to ensure that the backend driver does actually
>>> support BGR for texturing? AFAIK, if a client happens to select a BGR
>>> config on other drivers now - using a compositor which does not
>>> implement wl_drm - this will break for them.
>>
>> I think in practice, every hw driver can support both for texturing if
>> it can support one, since swizzles are always possible (due to
>> ARB_texture_swizzle).
>>
>> In practice at least nouveau prior to Mario's patches only supported
>> it one way. I just checked r600, radeonsi, i965 and freedreno, and
>> they appear to support both for texturing. I think that covers the
>> majority of the likely 10bpc users.
>
> Fair enough. My only remaining issue - and there's nothing the patch
> can really do about it - is a bit of a crapshoot. wayland-drm has no
> hint that the underlying KMS device prefers ABGR to ARGB, and clients
> have no way of determining the channel order even if they did want to
> hardcode it for a specific usecase. So nothing in here really
> guarantees that we'll get scanout. But, that being said, this seems
> harmless enough, so this patch is:
> Reviewed-by: Daniel Stone <dani...@collabora.com>
>
> Cheers,
> Daniel

Agreed. It doesn't seem to hurt, but isn't guaranteed to work in all
cases, at least not for prime renderoffload.

While it did work on single-gpu combos, and when testing prime
renderoffload from amd to nouveau, and from nouveau to amd, and intel
to amd, it didn't work on the prime combo intel as wayland server gpu,
nouveau as renderoffload client gpu, although in principle intel hw
does support sampling that format, according to the format table in
the i965 driver. The driver doesn't expose it though. So the common
"Optimus" Intel igpu + NVidia dgpu case doesn't work atm.

Until last wednesday i've worked on some patch that may get around
that, then i got sidetracked by new dri3.2 problems and other things.
Testing on the half-finished patch doesn't look too bad, but i'm not
yet sure if it will work out or run into other obstacles

The idea is that in the wayland server part, we can figure out which
gpu driver is associated with the dri2_dpy, and from there get to the
dri_configs exposed by the driver for rendering, assuming that if a
driver can render to a format, it will also be able to sample from it
for compositing - and ideally scan out from it if it's our lucky day.

On the wayland-client side, the code that generates eglconfigs from
supported visuals and driver dri_configs does this:

1. Build the list of eglconfigs like now in the wayland client egl code.

2. Check if there are dri_config formats supported by the client
driver that didn't get assigned in step 1 because the wayland server
doesn't support them for import. If so, check if there is a fallback
format supported by the server, e.g., for abgr2101010 the fallback
would be argb2101010. If that's the case, add the format to the list
of eglconfigs, as if it would be natively supported.

3. In the get_back_bo path, detect if we deal with the fallback case
from 2. If so, assign the fallback format for creation of the
linear_copy buffer. This way the actual back buffer used for rendering
has the format supported by the client driver, e.g., abgr2101010 for
nouveau, but the linear_copy buffer has the format of the server
driver, e.g., argb2101010 for intel. The blitImage detiling blit used
for prime renderoffload will then not only convert the tiled
renderbuffer into a linear buffer for import by the server, but also
perform a pixelformat conversion to what the server gpu supports.

This does at least work for "Optimus" with Intel gpu assigned to
weston, exporting argb2101010 as supported format, and nouveau
assigned to the wayland client, which then renders abgr2101010 but
converts to argb2101010 during the blitImage detiling blit. The nice
thing here is that for fullscreen wl_surfaces/buffers it allows the
wayland server to directly pageflip the wl_buffer to the scanout, as
it is in the optimal format for the server gpu.

Attached the current diffs for reference

[Mesa-dev] [PATCH 2/3] nv50, nvc0: Support BGRX1010102 and RGBX1010102 for sampling.

[Mario Kleiner]

Add them as usable for textures, so they can be used by
Wayland drm in 10 bpc mode and for X11 compositing under
GLX and EGL. We need these formats to be supported at
least for sampling, otherwise GLX_texture_from_pixmap
and the equivalent EGL image extension won't work with
X11 drawables of depth 30 and just display an all black
window.

Do not expose these formats as renderable, and thereby
not as a fbconfig/EGLConfig/Visual, as NVidia hw does
not support 10 bpc unorm formats without alpha channel.

Tested under X11 + GLX/EGL + DRI2/DRI3 for compositing,
and under Wayland+Weston drm backend with a Tesla and
Pascal gpu.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/gallium/drivers/nouveau/nv50/nv50_formats.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_formats.c 
b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
index fc5deac..0ead8ac 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_formats.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
@@ -153,7 +153,9 @@ const struct nv50_format 
nv50_format_table[PIPE_FORMAT_COUNT] =
F3(A, R9G9B9E5_FLOAT, NONE, R, G, B, xx, FLOAT, E5B9G9R9_SHAREDEXP, T),
 
C4(A, R10G10B10A2_UNORM, RGB10_A2_UNORM, R, G, B, A, UNORM, A2B10G10R10, 
TD),
+   F3(A, R10G10B10X2_UNORM, RGB10_A2_UNORM, R, G, B, xx, UNORM, A2B10G10R10, 
T),
C4(A, B10G10R10A2_UNORM, BGR10_A2_UNORM, B, G, R, A, UNORM, A2B10G10R10, 
IB),
+   F3(A, B10G10R10X2_UNORM, BGR10_A2_UNORM, B, G, R, xx, UNORM, A2B10G10R10, 
T),
C4(A, R10G10B10A2_SNORM, NONE, R, G, B, A, SNORM, A2B10G10R10, T),
C4(A, B10G10R10A2_SNORM, NONE, B, G, R, A, SNORM, A2B10G10R10, T),
C4(A, R10G10B10A2_UINT, RGB10_A2_UINT, R, G, B, A, UINT, A2B10G10R10, TR),
-- 
2.7.4

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

[Mesa-dev] More pieces for xbgr2101010/abgr2101010 support.

[Mario Kleiner]

These are needed together with Daniel Stone's 10 bpc bgr patches
to make nouveau's 10 bpc support more complete.

All tested on nouveau on a nv96 as primary/display gpu and also
with a radeon as prime renderoffload gpu, and then the other way
round with radeon primary + nouveau renderoffload. Also tested
under X11 DRI2 and DRI3/Present, GLX and EGL, composited and
unredirected. And with Waylands weston normal and with prime
renderoffload.

Patch 1 completes Daniels patches. Patch 2 makes weston work
on nouveau with gbm-format=xbgr2101010, and enables x11 compositing
of depth 30 drawables. Patch 3 makes sure we get the right colors
when compositing on x11 + EGL.

Some patches on top of weston master to test gbm-format=xbgr2101010
are here: https://github.com/kleinerm/weston/tree/westonnew10bpc

-mario

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

[Mesa-dev] [PATCH 3/3] egl/x11: Handle both depth 30 formats for eglCreateImage().

[Mario Kleiner]

We need to distinguish if a backing pixmap of a window is
XRGB2101010 or XBGR2101010, as different gpu hw supports
different formats. NVidia hw prefers XBGR, whereas AMD and
Intel are happy with XRGB.

We use the red channel mask of the visual to distinguish at
depth 30, but because we can't easily get the associated
visual of a Pixmap, we use the visual of the x-screens root
window instead as a proxy.

This fixes desktop composition of color depth 30 windows
when the X11 compositor uses EGL.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/egl/drivers/dri2/egl_dri2.h  |  7 ++
 src/egl/drivers/dri2/platform_x11.c  | 37 +++-
 src/egl/drivers/dri2/platform_x11_dri3.c |  7 +-
 3 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index d36d02c..a399b06 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -402,6 +402,8 @@ EGLBoolean
 dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp);
 void
 dri2_teardown_x11(struct dri2_egl_display *dri2_dpy);
+unsigned int
+dri2_x11_get_red_mask(struct dri2_egl_display *dri2_dpy);
 #else
 static inline EGLBoolean
 dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp)
@@ -410,6 +412,11 @@ dri2_initialize_x11(_EGLDriver *drv, _EGLDisplay *disp)
 }
 static inline void
 dri2_teardown_x11(struct dri2_egl_display *dri2_dpy) {}
+static inline unsigned int
+dri2_x11_get_red_mask(struct dri2_egl_display *dri2_dpy)
+{
+   return 0;
+}
 #endif
 
 #ifdef HAVE_DRM_PLATFORM
diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index 6c287b4..da28981 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -209,6 +209,37 @@ get_xcb_screen(xcb_screen_iterator_t iter, int screen)
 return NULL;
 }
 
+static xcb_visualtype_t *
+get_xcb_visualtype(struct dri2_egl_display *dri2_dpy)
+{
+   xcb_visualtype_iterator_t visual_iter;
+   xcb_screen_t *screen = dri2_dpy->screen;
+   xcb_visualid_t visual_id = screen->root_visual;
+   xcb_depth_iterator_t depth_iter = 
xcb_screen_allowed_depths_iterator(screen);
+
+   for (; depth_iter.rem; xcb_depth_next(_iter)) {
+  visual_iter = xcb_depth_visuals_iterator(depth_iter.data);
+
+  for (; visual_iter.rem; xcb_visualtype_next(_iter)) {
+ if (visual_iter.data->visual_id == visual_id)
+return visual_iter.data;
+  }
+   }
+
+   return NULL;
+}
+
+/* Get red channel mask of the root windows visual for our x-screen */
+unsigned int
+dri2_x11_get_red_mask(struct dri2_egl_display *dri2_dpy)
+{
+   unsigned int red_mask = 0;
+   xcb_visualtype_t *visual = get_xcb_visualtype(dri2_dpy);
+   if (visual)
+  red_mask = visual->red_mask;
+
+   return red_mask;
+}
 
 /**
  * Called via eglCreateWindowSurface(), drv->API.CreateWindowSurface().
@@ -1050,7 +1081,11 @@ dri2_create_image_khr_pixmap(_EGLDisplay *disp, 
_EGLContext *ctx,
   format = __DRI_IMAGE_FORMAT_XRGB;
   break;
case 30:
-  format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  /* Different preferred formats for different hw */
+  if (dri2_x11_get_red_mask(dri2_dpy) == 0x3ff)
+ format = __DRI_IMAGE_FORMAT_XBGR2101010;
+  else
+ format = __DRI_IMAGE_FORMAT_XRGB2101010;
   break;
case 32:
   format = __DRI_IMAGE_FORMAT_ARGB;
diff --git a/src/egl/drivers/dri2/platform_x11_dri3.c 
b/src/egl/drivers/dri2/platform_x11_dri3.c
index 2073c59..667c845 100644
--- a/src/egl/drivers/dri2/platform_x11_dri3.c
+++ b/src/egl/drivers/dri2/platform_x11_dri3.c
@@ -282,7 +282,12 @@ dri3_create_image_khr_pixmap(_EGLDisplay *disp, 
_EGLContext *ctx,
   format = __DRI_IMAGE_FORMAT_XRGB;
   break;
case 30:
-  format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  /* Different preferred formats for different hw */
+  if (dri2_x11_get_red_mask(dri2_dpy) == 0x3ff)
+ format = __DRI_IMAGE_FORMAT_XBGR2101010;
+  else
+ format = __DRI_IMAGE_FORMAT_XRGB2101010;
+
   break;
case 32:
   format = __DRI_IMAGE_FORMAT_ARGB;
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/3] wayland-drm: Expose server-side xbgr2101010 and abgr2101010 formats.

[Mario Kleiner]

This way the wayland server can signal support for these formats
to wayland EGL clients. This is currently used by nouveau for 10
bpc support.

Tested with glmark2-wayland and glmark2-es2-wayland under weston
to now expose 10 bpc EGL configs under nouveau.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/egl/wayland/wayland-drm/wayland-drm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c 
b/src/egl/wayland/wayland-drm/wayland-drm.c
index 3c6696d..7d44d38 100644
--- a/src/egl/wayland/wayland-drm/wayland-drm.c
+++ b/src/egl/wayland/wayland-drm/wayland-drm.c
@@ -111,6 +111,8 @@ drm_create_buffer(struct wl_client *client, struct 
wl_resource *resource,
  uint32_t stride, uint32_t format)
 {
 switch (format) {
+case WL_DRM_FORMAT_ABGR2101010:
+case WL_DRM_FORMAT_XBGR2101010:
 case WL_DRM_FORMAT_ARGB2101010:
 case WL_DRM_FORMAT_XRGB2101010:
 case WL_DRM_FORMAT_ARGB:
@@ -215,6 +217,10 @@ bind_drm(struct wl_client *client, void *data, uint32_t 
version, uint32_t id)
wl_resource_post_event(resource, WL_DRM_FORMAT,
   WL_DRM_FORMAT_XRGB2101010);
wl_resource_post_event(resource, WL_DRM_FORMAT,
+  WL_DRM_FORMAT_ABGR2101010);
+   wl_resource_post_event(resource, WL_DRM_FORMAT,
+  WL_DRM_FORMAT_XBGR2101010);
+   wl_resource_post_event(resource, WL_DRM_FORMAT,
   WL_DRM_FORMAT_ARGB);
wl_resource_post_event(resource, WL_DRM_FORMAT,
   WL_DRM_FORMAT_XRGB);
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 2/2] gbm: Add support for 10bpp BGR formats

[Mario Kleiner]

Tested under nouveau-kms with a hacked kmscube to use
GBM_FORMAT_ABGR2101010 successfully, and reject
GBM_FORMAT_XBGR2101010, GBM_FORMAT_ARGB2101010,
and GBM_FORMAT_XRGB2101010 as expected.

Reviewed-and-Tested-by: Mario Kleiner <mario.kleiner...@gmail.com>

On Fri, Mar 9, 2018 at 4:45 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> Series is Tested-by: Ilia Mirkin <imir...@alum.mit.edu>
>
> kmscube and weston both start. The terminal app in weston shows
> correct colors. I got a (weston) crash when trying to run
> egltri_wayland from mesa-demos, but that could be for a million
> different reasons.
>
> On Thu, Mar 8, 2018 at 12:36 PM, Daniel Stone <dani...@collabora.com> wrote:
>> Add support for XBGR2101010 and ABGR2101010 formats.
>>
>> Signed-off-by: Daniel Stone <dani...@collabora.com>
>> ---
>>  src/gbm/backends/dri/gbm_dri.c | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
>> index df20db40218..b3d6ceb15a3 100644
>> --- a/src/gbm/backends/dri/gbm_dri.c
>> +++ b/src/gbm/backends/dri/gbm_dri.c
>> @@ -580,6 +580,14 @@ static const struct gbm_dri_visual 
>> gbm_dri_visuals_table[] = {
>>   GBM_FORMAT_ARGB2101010, __DRI_IMAGE_FORMAT_ARGB2101010,
>>   { 0x3ff0, 0x000ffc00, 0x03ff, 0xc000 },
>> },
>> +   {
>> + GBM_FORMAT_XBGR2101010, __DRI_IMAGE_FORMAT_XBGR2101010,
>> + { 0x03ff, 0x000ffc00, 0x3ff0, 0x },
>> +   },
>> +   {
>> + GBM_FORMAT_ABGR2101010, __DRI_IMAGE_FORMAT_ABGR2101010,
>> + { 0x03ff, 0x000ffc00, 0x3ff0, 0xc000 },
>> +   },
>>  };
>>
>>  /* The two GBM_BO_FORMAT_[XA]RGB formats alias the GBM_FORMAT_*
>> --
>> 2.14.3
>>
>> ___
>> 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] egl/wayland: Add 10bpc BGR configs

[Mario Kleiner]

Tested with a hacked weston (to add xbgr2101010 support) under x11 and
drm backend (with wl_drm and wl_dmabuf). All colors are displaying
correctly, and "glmark2-wayland -d" confirms use of a RGBA 10-10-10-2
config. Also works with DRI_PRIME=1 for renderoffload to a AMD gpu.

It did need some more patches to work though. I'll send out a series
on top of your patches shortly to complete this.

Reviewed-and-Tested-by: Mario Kleiner <mario.kleiner...@gmail.com>

On Fri, Mar 9, 2018 at 7:15 PM, Eric Engestrom
<eric.engest...@imgtec.com> wrote:
> On Thursday, 2018-03-08 17:36:39 +, Daniel Stone wrote:
>> Add support for XBGR2101010 and ABGR2101010.
>>
>> Signed-off-by: Daniel Stone <dani...@collabora.com>
>> Cc: Ilia Mirkin <imir...@alum.mit.edu>
>
> Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>
>
>> ---
>>  src/egl/drivers/dri2/platform_wayland.c | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/src/egl/drivers/dri2/platform_wayland.c 
>> b/src/egl/drivers/dri2/platform_wayland.c
>> index 877f7933b9a..7a32491974e 100644
>> --- a/src/egl/drivers/dri2/platform_wayland.c
>> +++ b/src/egl/drivers/dri2/platform_wayland.c
>> @@ -81,6 +81,18 @@ static const struct dri2_wl_visual {
>>   __DRI_IMAGE_FORMAT_ARGB2101010, 32,
>>   { 0x3ff0, 0x000ffc00, 0x03ff, 0xc000 }
>> },
>> +   {
>> + "XBGR2101010",
>> + WL_DRM_FORMAT_XBGR2101010, WL_SHM_FORMAT_XBGR2101010,
>> + __DRI_IMAGE_FORMAT_XBGR2101010, 32,
>> + { 0x03ff, 0x000ffc00, 0x3ff0, 0x }
>> +   },
>> +   {
>> + "ABGR2101010",
>> + WL_DRM_FORMAT_ABGR2101010, WL_SHM_FORMAT_ABGR2101010,
>> + __DRI_IMAGE_FORMAT_ABGR2101010, 32,
>> + { 0x03ff, 0x000ffc00, 0x3ff0, 0xc000 }
>> +   },
>> {
>>   "XRGB",
>>   WL_DRM_FORMAT_XRGB, WL_SHM_FORMAT_XRGB,
>> --
>> 2.14.3
>>
>> ___
>> 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] nouveau 30bpp / deep color status

[Mario Kleiner]

Cc'ing mesa-dev, which was left out.

On 03/05/2018 01:40 PM, Ilia Mirkin wrote:

On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner
<mario.kleiner...@gmail.com> wrote:

On 02/05/2018 12:50 AM, Ilia Mirkin wrote:


In case anyone's curious about 30bpp framebuffer support, here's the
current status:

Kernel:

Ben and I have switched the code to using a 256-based LUT for Kepler+,
and I've also written a patch to cause the addfb ioctl to use the
proper format. You can pick this up at:

https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
https://patchwork.freedesktop.org/patch/202322/

With these two, you should be able to use "X -depth 30" again on any
G80+ GPU to bring up a screen (as you could in kernel 4.9 and
earlier). However this still has some deficiencies, some of which I've
addressed:

xf86-video-nouveau:

DRI3 was broken, and Xv was broken. Patches available at:

https://github.com/imirkin/xf86-video-nouveau/commits/master

mesa:

The NVIDIA hardware (pre-Kepler) can only do XBGR scanout. Further the
nouveau KMS doesn't add XRGB scanout for Kepler+ (although it could).
Mesa was only enabled for XRGB, so I've piped XBGR through all the
same places:

https://github.com/imirkin/mesa/commits/30bpp



Wrt. mesa, those patches are now in master and i think we have a bit of a
problem under X11+GLX:

https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/dri/dri_screen.c#n108

dri_fill_in_modes() defines MESA_FORMAT_R10G10B10A2_UNORM,
MESA_FORMAT_R10G10B10X2_UNORM at the top inbetween the BGRX/A formats
ignoring the instructions that
"/* The 32-bit RGBA format must not precede the 32-bit BGRA format.
   * Likewise for RGBX and BGRX.  Otherwise, the GLX client and the GLX
   * server may disagree on which format the GLXFBConfig represents,
   * resulting in swapped color channels."

RGBA/X formats should only be exposed
if (dri_loader_get_cap(screen, DRI_LOADER_CAP_RGBA_ORDERING))

and that is only the case for the Android loader.

The GLX code doesn't use the red/green/blueChannelMasks for proper matching
of formats, and the server doesn't even transmit those masks to the client
in the case of GLX. So whatever 10 bit format comes first will win when
building the assignment to GLXFBConfigs.

I looked at the code and how it behaves. In practice Intel gfx works because
it's a classic DRI driver with its own method of building the DRIconfig's,
and it only exposes the BGR101010 formats, so no danger of mixups. AMD's
gallium drivers expose both BGR and RGB ordered 10 bit formats, but due to
the ordering, the matching ends up only assigning the desired BGR formats
that are good for AMD hw, discarding the RGB formats. nouveau works because
it only exposes the desired RGB format for the hw. But with other gallium
drivers for some SoC's or future gallium drivers it is not so clear if the
right thing will happen. E.g., freedreno seems to support both BGR and RGB
10 bit formats as PIPE_BIND_DISPLAY_TARGET afaics, so i don't know if by
luck the right thing would happen?


FWIW freedreno does not presently support 10bpc scanout.



Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs to
DRIconfigs, so we could probably implement dri_loader_get_cap(screen,
DRI_LOADER_CAP_RGBA_ORDERING) == TRUE for the EGL loaders.

But for GLX it is not so easy or quick. I looked if i could make the servers
GLX send proper channelmask attributes and Mesa parsing them, but there
aren't any GLX tags defined for channel masks, and all other tags come from
official GLX extension headers. I'm not sure what the proper procedure for
defining new tags is? Do we have to define a new GLX extension for that and
get it in the Khronos registry and then back into the server/mesa code-base?


Can all of this be solved by a healthy dose of "don't do that"? i.e.
make sure that the DDX only ever exposes one of these at a time? And
also make the mesa driver only expose one as a DISPLAY_TARGET?



Yes, if "don't do that" is consistently possible on all future drivers. 
Under EGL there is matching of channel masks, so only X11+GLX is 
problematic. Not sure if anything special would need to be done for 
XWayland, haven't looked at that at all so far. Or the modesetting ddx, 
which currently assumes xrgb ordering for 10 bit.




The current patches in mesa for XBGR also lack enablement pieces for EGL,
Wayland and X11 compositing, but that's a different problem.


EGL/drm and EGL/wayland should be enabled (look at Daniel Stone's
patches from a short while back, also upstream now). kmscube (with
some patches that are upstream now) and weston both run OK for me. I
think EGL/x11 is iffy though - haven't played with it.

   -ilia



There are some from Daniel which unify the handling of formats inside 
egl, not with any abgr2101010 definitions though. Indeed on master 
compositing doesn't work for depth 30 windows. I have some patches that 
fix this, and some h

[Mesa-dev] [PATCH] i965/screen: Allow drirc to set 'allow_rgb10_configs' again.

[Mario Kleiner]

Since setup of ALLOW_RGB10_CONFIGS was moved to i965's own
brw_config_options.xml, this was hard-coded to false and
could not be overriden by drirc. Add some parsing into
i965's private screen->optionCache to enable drirc again.

Fixes: b391fb26df9f1b ("dri_util: remove ALLOW_RGB10_CONFIGS option (v2)")
Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
Cc: Marek Olšák <marek.ol...@amd.com>
---
 src/mesa/drivers/dri/i965/intel_screen.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 190d8ecb11..9dbda5142e 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -2395,7 +2395,12 @@ __DRIconfig **intelInitScreen2(__DRIscreen *dri_screen)
   return NULL;
}
/* parse information in __driConfigOptions */
-   driParseOptionInfo(>optionCache, brw_config_options.xml);
+   driOptionCache options;
+   memset(, 0, sizeof(options));
+
+   driParseOptionInfo(, brw_config_options.xml);
+   driParseConfigFiles(>optionCache, , dri_screen->myNum, 
"i965");
+   driDestroyOptionCache();
 
screen->driScrnPriv = dri_screen;
dri_screen->driverPrivate = (void *) screen;
-- 
2.13.0.rc1.294.g07d810a77f

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

Re: [Mesa-dev] [PATCH] st/dri: Default ALLOW_RGB10_CONFIGS to false on gallium as well.

[Mario Kleiner]

On 01/17/2018 05:49 AM, Marek Olšák wrote:

On Wed, Jan 17, 2018 at 3:21 AM, Mario Kleiner
<mario.kleiner...@gmail.com> wrote:

On 01/16/2018 11:47 PM, Marek Olšák wrote:


Why?



Because the bug reports i've seen so far seem to be not caused by something
specific to the i965 implementation, but by some other client application or
compositor being incompatible. Therefore i'd expect the same problems in
clients/compositors to happen with gallium drivers.

E.g., the gnome-shell bugs happen on all 10 bit drivers. So it would make
sense for rgb10 to be off by default consistently on all drivers, but with
the ability to switch it on via drirc.


If we re-enable this in the future, current and older gnome shell will
be broken, so is it even useful to disable it?

Marek



I don't know what the right approach is here. It just felt right to make 
the default consistent across Mesa's drivers, regardless if that default 
is on or off, as far as i'm concerned. Without enabled by default 
there's no trigger for projects to fix their code. With it enabled we 
will get probably lots of bug reports from incompatible software that 
won't get fixed quickly. I wouldn't be surprised if most basic Wayland 
compositors apart from Weston would have trouble. Or much stuff that 
runs on new X-Server 1.19.6 or master with all those new 32 bpp 
compositing visuals exposed. I will do some testing on that sometime in 
the coming days.


We could also ship an updated drirc which sets it globally on and is 
easily user editable for debugging/working around stuff, and add app 
specific workarounds for applications we know already to be broken.


We should get that other patch, that you and Tapani already reviewed, 
into master before Mesa 18-rc1 is branched, so one can enable i965 rgb10 
support again via drirc for testing on Intel, also to simplify testing 
via the oibaf or padoka ppa's.


-mario




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

Re: [Mesa-dev] [PATCH] st/dri: Default ALLOW_RGB10_CONFIGS to false on gallium as well.

[Mario Kleiner]

On 01/16/2018 11:47 PM, Marek Olšák wrote:

Why?


Because the bug reports i've seen so far seem to be not caused by 
something specific to the i965 implementation, but by some other client 
application or compositor being incompatible. Therefore i'd expect the 
same problems in clients/compositors to happen with gallium drivers.


E.g., the gnome-shell bugs happen on all 10 bit drivers. So it would 
make sense for rgb10 to be off by default consistently on all drivers, 
but with the ability to switch it on via drirc.


-mario



Marek

On Tue, Jan 16, 2018 at 5:39 AM, Mario Kleiner
<mario.kleiner...@gmail.com> wrote:

For consistency with the i965 default of "off".

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
  src/gallium/auxiliary/pipe-loader/driinfo_gallium.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h 
b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
index 505aae4..446bc06 100644
--- a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
+++ b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
@@ -32,5 +32,5 @@ DRI_CONF_SECTION_END
  DRI_CONF_SECTION_MISCELLANEOUS
 DRI_CONF_ALWAYS_HAVE_DEPTH_BUFFER("false")
 DRI_CONF_GLSL_ZERO_INIT("false")
-   DRI_CONF_ALLOW_RGB10_CONFIGS("true")
+   DRI_CONF_ALLOW_RGB10_CONFIGS("false")
  DRI_CONF_SECTION_END
--
2.7.4

___
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] st/dri: Default ALLOW_RGB10_CONFIGS to false on gallium as well.

[Mario Kleiner]

For consistency with the i965 default of "off".

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/gallium/auxiliary/pipe-loader/driinfo_gallium.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h 
b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
index 505aae4..446bc06 100644
--- a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
+++ b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
@@ -32,5 +32,5 @@ DRI_CONF_SECTION_END
 DRI_CONF_SECTION_MISCELLANEOUS
DRI_CONF_ALWAYS_HAVE_DEPTH_BUFFER("false")
DRI_CONF_GLSL_ZERO_INIT("false")
-   DRI_CONF_ALLOW_RGB10_CONFIGS("true")
+   DRI_CONF_ALLOW_RGB10_CONFIGS("false")
 DRI_CONF_SECTION_END
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] dri_util: remove ALLOW_RGB10_CONFIGS option (v2)

[Mario Kleiner]

On 01/11/2018 09:14 AM, Tapani Pälli wrote:
Yes, but as it broke regular visuals (on some of our testing machines as 
well) we needed a fast fix for this.


While this is an issue, I think the visual corruption has higher 
priority than this. This can be fixed meanwhile or afterwards when 
things work OK. Now it can be toggled true in intel_screen.c when 
debugging/investigating the issue.




That regression in Bug 104536, could you only reproduce it on "Ubuntu 
16.04 or 17.04 respectively, with latest git versions of libdrm, mesa, 
xserver, xlibs, and the drm-tip kernel." as David Weinehall reported in 
private message?


Does it require X-Server from git master?

Because testing here on Intel Ivybridge and Skylake with KUbuntu 16.04.3 
LTS and the distribution-provided X-Server 1.19.3 and the Unity-7 + 
Compiz standard Ubuntu 16.04 GUI, i can't reproduce the visual 
corruption from that screenshot in bug 104536?, neither with the 
intel-ddx nor the modesetting-ddx used by default, neither depth 24 nor 
depth 30.


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

Re: [Mesa-dev] [PATCH] dri_util: remove ALLOW_RGB10_CONFIGS option (v2)

[Mario Kleiner]

On 01/11/2018 02:39 PM, Marek Olšák wrote:



On Jan 11, 2018 7:14 AM, "Mario Kleiner" <mario.kleiner...@gmail.com 
<mailto:mario.kleiner...@gmail.com>> wrote:


On 01/10/2018 07:04 AM, Tapani Pälli wrote:

Hi Marek;

This one works but only if you add

DRI_CONF_ALLOW_RGB10_CONFIGS("false")

to the DRI_CONF_SECTION_MISCELLANEOUS section in intel_screen.
With that change: Reviewed-by: Tapani Pälli
<tapani.pa...@intel.com <mailto:tapani.pa...@intel.com>>


With this patch now committed to master, rgb10 visuals on i965 are
completely dead, as far as my testing goes. rgb10 is always off, and
the 'allow_rgb10_configs' option in drirc gets ignored for
enumeration of visuals/fbconfigs, e.g., in glxinfo.

Before it worked on my machines, defaulted to on, and could be
controlled via drirc.

As far as i can see, setting up >optionCache for i965
happens too late, only at glXCreateContext() time ->
brwCreateContext() -> brw_process_driconf_options().

The old way read the options file as part of driCreateNewScreen2(),
which was called as part of __glXInitialize, e.g., from
glXChooseVisual() -- early enough to affect the
enumeration/selection of visuals.

So i don't know if the old way was the right way, but it did give
the right behavior for i965 whereas the new one doesn't.

Ideas?


I think that's not completely true. I965 loads drirc options for each 
screen and then again for each context, which is weird.


Generally, the screen object isn't allowed to be modified by 
glXCreateContext.


Marek



Ok, the patch just sent out retains the new way of things, and defaults 
i965 to rgb10 off, but parses drirc again, so one can enable it via a




snippet. Tested under Wayland+Weston and X11 XOrg Server 1.19.3 with GLX 
and EGL apps.


-mario



-mario


On 01/09/2018 04:04 PM, Marek Olšák wrote:

From: Marek Olšák <marek.ol...@amd.com
<mailto:marek.ol...@amd.com>>

This is unused because it's for libGL/libEGL, not drivers.

v2: i965 was wrong, because it used dri_util instead of its
own config.
---
   src/mesa/drivers/dri/common/dri_util.c   | 4 
   src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
   2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index d4fba0b..e6a7d23 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -48,24 +48,20 @@
   #include "main/version.h"
   #include "main/debug_output.h"
   #include "main/errors.h"
   #include "main/macros.h"
   const char __dri2ConfigOptions[] =
  DRI_CONF_BEGIN
     DRI_CONF_SECTION_PERFORMANCE
    DRI_CONF_VBLANK_MODE(DRI_CONF_VBLANK_DEF_INTERVAL_1)
     DRI_CONF_SECTION_END
-
-  DRI_CONF_SECTION_MISCELLANEOUS
- DRI_CONF_ALLOW_RGB10_CONFIGS("true")
-  DRI_CONF_SECTION_END
  DRI_CONF_END;
  
/*/

   /** \name Screen handling functions  */
  
/*/

   /*@{*/
   static void
   setupLoaderExtensions(__DRIscreen *psp,
     const __DRIextension **extensions)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 3e016b5..89db821 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -2057,21 +2057,21 @@
intel_screen_make_configs(__DRIscreen *dri_screen)
  __DRIconfig **configs = NULL;
  /* Expose only BGRA ordering if the loader doesn't
support RGBA ordering. */
  unsigned num_formats;
  if (intel_loader_get_cap(dri_screen,
DRI_LOADER_CAP_RGBA_ORDERING))
     num_formats = ARRAY_SIZE(formats);
  else
     num_formats = ARRAY_SIZE(formats) - 2; /* all -
RGBA_ORDERING formats */
  /* Shall we expose 10 bpc formats? */
-   bool allow_rgb10_configs =
driQueryOptionb(_screen->optionCache,
+   bool allow_rgb10_configs =
driQueryOptionb(>optionCache,
    

[Mesa-dev] [PATCH] i965/screen: Allow drirc to set 'allow_rgb10_configs' again.

[Mario Kleiner]

Since setup of ALLOW_RGB10_CONFIGS was moved to i965's own
brw_config_options.xml, this was hard-coded to false and
could not be overriden by drirc. Add some parsing into
i965's private screen->optionCache to enable drirc again.

Fixes: b391fb26df9f1b ("dri_util: remove ALLOW_RGB10_CONFIGS option (v2)")
Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: Marek Olšák <marek.ol...@amd.com>
Cc: Tapani Pälli <tapani.pa...@intel.com>
---
 src/mesa/drivers/dri/i965/intel_screen.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 08032c9..eb4b569 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -2397,7 +2397,12 @@ __DRIconfig **intelInitScreen2(__DRIscreen *dri_screen)
   return NULL;
}
/* parse information in __driConfigOptions */
-   driParseOptionInfo(>optionCache, brw_config_options.xml);
+   driOptionCache options;
+   memset(, 0, sizeof(options));
+
+   driParseOptionInfo(, brw_config_options.xml);
+   driParseConfigFiles(>optionCache, , dri_screen->myNum, 
"i965");
+   driDestroyOptionCache();
 
screen->driScrnPriv = dri_screen;
dri_screen->driverPrivate = (void *) screen;
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] dri_util: remove ALLOW_RGB10_CONFIGS option (v2)

[Mario Kleiner]

On 01/10/2018 07:04 AM, Tapani Pälli wrote:

Hi Marek;

This one works but only if you add

DRI_CONF_ALLOW_RGB10_CONFIGS("false")

to the DRI_CONF_SECTION_MISCELLANEOUS section in intel_screen. With that 
change: Reviewed-by: Tapani Pälli 




With this patch now committed to master, rgb10 visuals on i965 are 
completely dead, as far as my testing goes. rgb10 is always off, and the 
'allow_rgb10_configs' option in drirc gets ignored for enumeration of 
visuals/fbconfigs, e.g., in glxinfo.


Before it worked on my machines, defaulted to on, and could be 
controlled via drirc.


As far as i can see, setting up >optionCache for i965 happens 
too late, only at glXCreateContext() time -> brwCreateContext() -> 
brw_process_driconf_options().


The old way read the options file as part of driCreateNewScreen2(), 
which was called as part of __glXInitialize, e.g., from 
glXChooseVisual() -- early enough to affect the enumeration/selection of 
visuals.


So i don't know if the old way was the right way, but it did give the 
right behavior for i965 whereas the new one doesn't.


Ideas?
-mario



On 01/09/2018 04:04 PM, Marek Olšák wrote:

From: Marek Olšák 

This is unused because it's for libGL/libEGL, not drivers.

v2: i965 was wrong, because it used dri_util instead of its own config.
---
  src/mesa/drivers/dri/common/dri_util.c   | 4 
  src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
  2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/common/dri_util.c 
b/src/mesa/drivers/dri/common/dri_util.c

index d4fba0b..e6a7d23 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -48,24 +48,20 @@
  #include "main/version.h"
  #include "main/debug_output.h"
  #include "main/errors.h"
  #include "main/macros.h"
  const char __dri2ConfigOptions[] =
 DRI_CONF_BEGIN
    DRI_CONF_SECTION_PERFORMANCE
   DRI_CONF_VBLANK_MODE(DRI_CONF_VBLANK_DEF_INTERVAL_1)
    DRI_CONF_SECTION_END
-
-  DRI_CONF_SECTION_MISCELLANEOUS
- DRI_CONF_ALLOW_RGB10_CONFIGS("true")
-  DRI_CONF_SECTION_END
 DRI_CONF_END;
  /*/
  /** \name Screen handling functions  */
  /*/
  /*@{*/
  static void
  setupLoaderExtensions(__DRIscreen *psp,
    const __DRIextension **extensions)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c

index 3e016b5..89db821 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -2057,21 +2057,21 @@ intel_screen_make_configs(__DRIscreen 
*dri_screen)

 __DRIconfig **configs = NULL;
 /* Expose only BGRA ordering if the loader doesn't support RGBA 
ordering. */

 unsigned num_formats;
 if (intel_loader_get_cap(dri_screen, DRI_LOADER_CAP_RGBA_ORDERING))
    num_formats = ARRAY_SIZE(formats);
 else
    num_formats = ARRAY_SIZE(formats) - 2; /* all - RGBA_ORDERING 
formats */

 /* Shall we expose 10 bpc formats? */
-   bool allow_rgb10_configs = driQueryOptionb(_screen->optionCache,
+   bool allow_rgb10_configs = driQueryOptionb(>optionCache,
    "allow_rgb10_configs");
 /* Generate singlesample configs without accumulation buffer. */
 for (unsigned i = 0; i < num_formats; i++) {
    __DRIconfig **new_configs;
    int num_depth_stencil_bits = 2;
    if (!allow_rgb10_configs &&
    (formats[i] == MESA_FORMAT_B10G10R10A2_UNORM ||
 formats[i] == MESA_FORMAT_B10G10R10X2_UNORM))


___
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] 10-bit Mesa/Gallium support

[Mario Kleiner]

On 12/31/2017 05:53 PM, Ilia Mirkin wrote:

On Thu, Nov 23, 2017 at 1:31 PM, Mario Kleiner
<mario.kleiner...@gmail.com> wrote:

On 11/23/2017 06:45 PM, Ilia Mirkin wrote:


On Thu, Nov 23, 2017 at 12:35 PM, Marek Olšák <mar...@gmail.com> wrote:


Hi everybody,

Mario, feel free to push your patches if you haven't yet. (except the
workaround)



Hi,

just started 10 minutes ago with rebasing my current patchset against mesa
master. Will need some adjustments and retesting against i965.

I was also just "sort of done" with a mesa/gallium 10 bit version. I think
i'll submit rev 3 later today or tomorrow and maybe we'll need to sort this
out then, what goes where. I'll compare with Mareks branch...

The current state of my series for AMD here is that radeon-kms + ati-ddx
works nicely under exa (and with a slightly patched weston), but the ati-ddx
also needed some small patches which i have to send out. On amdgpu-kms i
know it works under my patched weston branch.

What is completely missing is glamor support, ergo support for at least
amdgpu-ddx and modesetting-ddx -- and xwayland.


For AMD, I applied Mario's patches (except Wayland - that didn't
apply) and added initial Gallium support:
https://cgit.freedesktop.org/~mareko/mesa/log/?h=10bit

What's the status of Glamor?

Do we have patches for xf86-video-amdgpu? The closed should have
10-bit support, meaning we should have DDX patches already somewhere,
right?



Somewhere there must be some, as the amdgpu-pro driver with the proprietary
libGL supported depth 30 at least in some version i tested earlier this
year?



I'd like to test this out with nouveau as well... do I understand
correctly that I shouldn't need anything special to check if it
basically works? i.e. I apply the patches, start Xorg in bpp=30 mode,
and then if glxgears works then I'm done? Is there a good way that I'm
really in 30bpp mode as far as all the software is concerned? (I don't
have a colorimeter or whatever fancy hw to *really* tell the
difference, although I do have a "deep color" TV.) If used with a
24bpp display, is the hw supposed to dither somehow?x

-ilia



nouveau is quite a bit work to do and not so clear how to proceed.

My current series does do proper xrgb2101010 / argb2101010 rendering under
gallium on both nv50 and nvc0 (Tested under GeForce 9600 for tesla, GTX 970
and 1050 for maxwell and pascal). I used PRIME render offload under both
DRI3/Present and Wayland/Weston with both intel and amd as display gpus, so
i know the drivers work together properly and nouveau-gallium renders
correctly.

The display side for native scanout on Nvidia is somewhat broken atm.:

1. Since Linux 4.10 with the switch of nouveau-kms to atomic modesetting,
using drmAddFB() with depth/bpp 30/32 maps to xrgb2101010 format, but
nouveau-kms doesn't support xrgb2101010, so setting Xorg to depth 30 will
end in a server-abort with modesetting failure. nouveau before Linux 4.10
mapped 30/32 to xbgr2101010 which seems to be supported since nv50. If i
boot with a < 4.10 kernel i get a picture at least on the old GeForce 9600
and GT330M.

If i hack nouveau-ddx to use a xrgb2101010 color channel mask (red in msb's,
blue in lsbs) instead of the correct xbgr2101010 mask, then i can get
nouveau-gallium to render 10 bits, but of course with swapped red and blue
channels. Switching dithering on via xrandr allows to get rendered 10 bit
images to get to a 8 bpc display, as confirmed via colorimeter. I hope a
deep color TV might work without dithering.

According to

https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml

gpu's since kepler gk104 support xrgb2101010 scanout. With a hacked
nouveau-kms i can get the maxwell and pascal cards to accept xrgb2101010,
but the display is beyond weird. So far i couldn't make much sense of the
pixeltrash -- some of it remotely resembles a desktop, but something is
going wrong badly. Also the xbgr2101010 mode doesn't work correct. The same
is true for Wayland+Weston and even if i run Weston with pixman, keeping
Mesa out of the picture. So nouveau-kms needs some work for all modern
nvidia gpu's. Gamma table handling changed quite a bit, so maybe something
is wrong there.

2. We might also need some work for exa on nvc0+, but it's not clear what
problems are caused by kernel side, and what in exa.

3. In principle the clean solution for nouveau would be to upgrade the ddx
to drmAddFB2 ioctl, and use xbgr2101010 scanout to support everything back
to nv50+, but everything we have in X or Wayland is meant for xrgb2101010
not xbgr2101010. And we run into ambiguities of what, e.g., a depth 30
pixmap means in some extensions like glx_texture_form_pixmap. And the GLX
extension generally seems to have unresolved problems with ARGB formats
instead of ABGR formats, which is why Mesa doesn't expose ARGB by default --
only on Android atm.

So on nouveau everything except the gallium bits is quite a bit messy at the
moment, 

[Mesa-dev] [PATCH 17/22] st/dri2: Add format translations for BGR[A/X]1010102 formats.

[Mario Kleiner]

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/gallium/state_trackers/dri/dri2.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index d5ae9cb..f7fd08d 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -55,6 +55,8 @@
 #endif
 
 static const int fourcc_formats[] = {
+   __DRI_IMAGE_FOURCC_ARGB2101010,
+   __DRI_IMAGE_FOURCC_XRGB2101010,
__DRI_IMAGE_FOURCC_ARGB,
__DRI_IMAGE_FOURCC_ABGR,
__DRI_IMAGE_FOURCC_SARGB,
@@ -105,6 +107,14 @@ static int convert_fourcc(int format, int 
*dri_components_p)
   format = __DRI_IMAGE_FORMAT_XBGR;
   dri_components = __DRI_IMAGE_COMPONENTS_RGB;
   break;
+   case __DRI_IMAGE_FOURCC_ARGB2101010:
+  format = __DRI_IMAGE_FORMAT_ARGB2101010;
+  dri_components = __DRI_IMAGE_COMPONENTS_RGBA;
+  break;
+   case __DRI_IMAGE_FOURCC_XRGB2101010:
+  format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  dri_components = __DRI_IMAGE_COMPONENTS_RGB;
+  break;
case __DRI_IMAGE_FOURCC_R8:
   format = __DRI_IMAGE_FORMAT_R8;
   dri_components = __DRI_IMAGE_COMPONENTS_R;
@@ -166,6 +176,12 @@ static int convert_to_fourcc(int format)
case __DRI_IMAGE_FORMAT_XBGR:
   format = __DRI_IMAGE_FOURCC_XBGR;
   break;
+   case __DRI_IMAGE_FORMAT_ARGB2101010:
+  format = __DRI_IMAGE_FOURCC_ARGB2101010;
+  break;
+   case __DRI_IMAGE_FORMAT_XRGB2101010:
+  format = __DRI_IMAGE_FOURCC_XRGB2101010;
+  break;
case __DRI_IMAGE_FORMAT_R8:
   format = __DRI_IMAGE_FOURCC_R8;
   break;
@@ -198,6 +214,12 @@ static enum pipe_format dri2_format_to_pipe_format (int 
format)
case __DRI_IMAGE_FORMAT_ABGR:
   pf = PIPE_FORMAT_RGBA_UNORM;
   break;
+   case __DRI_IMAGE_FORMAT_XRGB2101010:
+  pf = PIPE_FORMAT_B10G10R10X2_UNORM;
+  break;
+   case __DRI_IMAGE_FORMAT_ARGB2101010:
+  pf = PIPE_FORMAT_B10G10R10A2_UNORM;
+  break;
case __DRI_IMAGE_FORMAT_R8:
   pf = PIPE_FORMAT_R8_UNORM;
   break;
@@ -253,6 +275,12 @@ static enum pipe_format fourcc_to_pipe_format(int fourcc)
case __DRI_IMAGE_FOURCC_XBGR:
   pf = PIPE_FORMAT_RGBX_UNORM;
   break;
+   case __DRI_IMAGE_FOURCC_ARGB2101010:
+  pf = PIPE_FORMAT_B10G10R10A2_UNORM;
+  break;
+   case __DRI_IMAGE_FOURCC_XRGB2101010:
+  pf = PIPE_FORMAT_B10G10R10X2_UNORM;
+  break;
 
case __DRI_IMAGE_FOURCC_NV12:
   pf = PIPE_FORMAT_NV12;
-- 
2.7.4

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

[Mesa-dev] [PATCH 21/22] st/dri: Add option to control exposure of 10 bpc color configs.

[Mario Kleiner]

Some clients may not like rgb10 fbconfigs and visuals.
Support driconf option 'allow_rgb10_configs' on gallium
to allow per application enable/disable.

The option defaults to enabled.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/gallium/auxiliary/pipe-loader/driinfo_gallium.h | 1 +
 src/gallium/state_trackers/dri/dri_screen.c | 8 
 2 files changed, 9 insertions(+)

diff --git a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h 
b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
index 003a3d7..505aae4 100644
--- a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
+++ b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
@@ -32,4 +32,5 @@ DRI_CONF_SECTION_END
 DRI_CONF_SECTION_MISCELLANEOUS
DRI_CONF_ALWAYS_HAVE_DEPTH_BUFFER("false")
DRI_CONF_GLSL_ZERO_INIT("false")
+   DRI_CONF_ALLOW_RGB10_CONFIGS("true")
 DRI_CONF_SECTION_END
diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
b/src/gallium/state_trackers/dri/dri_screen.c
index 46ca8fa..adce2ff 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -158,6 +158,7 @@ dri_fill_in_modes(struct dri_screen *screen)
struct pipe_screen *p_screen = screen->base.screen;
boolean pf_z16, pf_x8z24, pf_z24x8, pf_s8z24, pf_z24s8, pf_z32;
boolean mixed_color_depth;
+   boolean allow_rgb10;
 
static const GLenum back_buffer_modes[] = {
   __DRI_ATTRIB_SWAP_NONE, __DRI_ATTRIB_SWAP_UNDEFINED,
@@ -174,6 +175,8 @@ dri_fill_in_modes(struct dri_screen *screen)
   depth_buffer_factor = 1;
}
 
+   allow_rgb10 = driQueryOptionb(>dev->option_cache, 
"allow_rgb10_configs");
+
msaa_samples_max = (screen->st_api->feature_mask & 
ST_API_FEATURE_MS_VISUALS_MASK)
   ? MSAA_VISUAL_MAX_SAMPLES : 1;
 
@@ -233,6 +236,11 @@ dri_fill_in_modes(struct dri_screen *screen)
   unsigned num_msaa_modes = 0; /* includes a single-sample mode */
   uint8_t msaa_modes[MSAA_VISUAL_MAX_SAMPLES];
 
+  if (!allow_rgb10 &&
+  (mesa_formats[format] == MESA_FORMAT_B10G10R10A2_UNORM ||
+   mesa_formats[format] == MESA_FORMAT_B10G10R10X2_UNORM))
+ continue;
+
   if (!p_screen->is_format_supported(p_screen, pipe_formats[format],
  PIPE_TEXTURE_2D, 0,
  PIPE_BIND_RENDER_TARGET))
-- 
2.7.4

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

[Mesa-dev] [PATCH 22/22] mesa: Add GL_UNSIGNED_INT_2_10_10_10_REV OES read type for BGRX1010102.

[Mario Kleiner]

As Marek noted, the GL_RGBA + GL_UNSIGNED_INT_2_10_10_10_REV type
combo is also good for readback of BGRX1010102 framebuffers, not
only for BGRA1010102 framebuffers for use with glReadPixels()
under GLES, so add it for the GL_IMPLEMENTATION_COLOR_READ_TYPE_OES
query.

Successfully tested on gallium r600 driver with a (quickly hacked
for RGBA 10 10 10 0) dEQP testcase
dEQP-EGL.functional.wide_color.window_1010102_colorspace_default.

Suggested-by: Marek Olšák <marek.ol...@amd.com>
Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/mesa/main/framebuffer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index a0de669..e103f31 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -889,7 +889,8 @@ _mesa_get_color_read_type(struct gl_context *ctx,
   if (format == MESA_FORMAT_B5G6R5_UNORM)
  return GL_UNSIGNED_SHORT_5_6_5;
 
-  if (format == MESA_FORMAT_B10G10R10A2_UNORM)
+  if (format == MESA_FORMAT_B10G10R10A2_UNORM ||
+  format == MESA_FORMAT_B10G10R10X2_UNORM)
  return GL_UNSIGNED_INT_2_10_10_10_REV;
 
   switch (data_type) {
-- 
2.7.4

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

[Mesa-dev] [PATCH 20/22] st/dri: Add support for BGR[A/X]1010102 formats.

[Mario Kleiner]

Exposes RGBA 10 10 10 2 and 10 10 10 0 visuals and
fbconfigs for rendering.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/gallium/state_trackers/dri/dri_screen.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
b/src/gallium/state_trackers/dri/dri_screen.c
index 1ca5116..46ca8fa 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -108,6 +108,8 @@ static const __DRIconfig **
 dri_fill_in_modes(struct dri_screen *screen)
 {
static const mesa_format mesa_formats[] = {
+  MESA_FORMAT_B10G10R10A2_UNORM,
+  MESA_FORMAT_B10G10R10X2_UNORM,
   MESA_FORMAT_B8G8R8A8_UNORM,
   MESA_FORMAT_B8G8R8X8_UNORM,
   MESA_FORMAT_B8G8R8A8_SRGB,
@@ -136,6 +138,8 @@ dri_fill_in_modes(struct dri_screen *screen)
   MESA_FORMAT_R8G8B8X8_UNORM,
};
static const enum pipe_format pipe_formats[] = {
+  PIPE_FORMAT_B10G10R10A2_UNORM,
+  PIPE_FORMAT_B10G10R10X2_UNORM,
   PIPE_FORMAT_BGRA_UNORM,
   PIPE_FORMAT_BGRX_UNORM,
   PIPE_FORMAT_BGRA_SRGB,
@@ -221,7 +225,7 @@ dri_fill_in_modes(struct dri_screen *screen)
if (dri_loader_get_cap(screen, DRI_LOADER_CAP_RGBA_ORDERING))
   num_formats = ARRAY_SIZE(mesa_formats);
else
-  num_formats = ARRAY_SIZE(mesa_formats) - 2;
+  num_formats = ARRAY_SIZE(mesa_formats) - 2; /* all - RGBA_ORDERING 
formats */
 
/* Add configs. */
for (format = 0; format < num_formats; format++) {
@@ -289,6 +293,15 @@ dri_fill_st_visual(struct st_visual *stvis, struct 
dri_screen *screen,
 
/* Deduce the color format. */
switch (mode->redMask) {
+   case 0x3FF0:
+  if (mode->alphaMask) {
+ assert(mode->alphaMask == 0xC000);
+ stvis->color_format = PIPE_FORMAT_B10G10R10A2_UNORM;
+  } else {
+ stvis->color_format = PIPE_FORMAT_B10G10R10X2_UNORM;
+  }
+  break;
+
case 0x00FF:
   if (mode->alphaMask) {
  assert(mode->alphaMask == 0xFF00);
-- 
2.7.4

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

[Mesa-dev] [PATCH 16/22] st/mesa: Handle BGR[A/X]1010102 formats.

[Mario Kleiner]

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/mesa/state_tracker/st_cb_fbo.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
b/src/mesa/state_tracker/st_cb_fbo.c
index e2303b4..a982f87 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -286,6 +286,12 @@ st_new_renderbuffer_fb(enum pipe_format format, int 
samples, boolean sw)
strb->software = sw;
 
switch (format) {
+   case PIPE_FORMAT_B10G10R10A2_UNORM:
+  strb->Base.InternalFormat = GL_RGB10_A2;
+  break;
+   case PIPE_FORMAT_B10G10R10X2_UNORM:
+  strb->Base.InternalFormat = GL_RGB10;
+  break;
case PIPE_FORMAT_R8G8B8A8_UNORM:
case PIPE_FORMAT_B8G8R8A8_UNORM:
case PIPE_FORMAT_A8R8G8B8_UNORM:
-- 
2.7.4

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

[Mesa-dev] [PATCH 19/22] st/dri: Support texture_from_pixmap for BGR[A/X]1010102 formats.

[Mario Kleiner]

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/gallium/state_trackers/dri/dri_drawable.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/state_trackers/dri/dri_drawable.c 
b/src/gallium/state_trackers/dri/dri_drawable.c
index 92ce9d2..a5999be 100644
--- a/src/gallium/state_trackers/dri/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/dri_drawable.c
@@ -260,6 +260,9 @@ dri_set_tex_buffer2(__DRIcontext *pDRICtx, GLint target,
   if (format == __DRI_TEXTURE_FORMAT_RGB)  {
  /* only need to cover the formats recognized by dri_fill_st_visual */
  switch (internal_format) {
+ case PIPE_FORMAT_B10G10R10A2_UNORM:
+internal_format = PIPE_FORMAT_B10G10R10X2_UNORM;
+break;
  case PIPE_FORMAT_BGRA_UNORM:
 internal_format = PIPE_FORMAT_BGRX_UNORM;
 break;
-- 
2.7.4

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

[Mesa-dev] [PATCH 13/22] egl/wayland: Add Wayland drm support for RGB10 winsys buffers.

[Mario Kleiner]

Successfully tested under Weston 3.0.
Photometer confirms 10 rgb bits from rendering to display.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/egl/drivers/dri2/platform_wayland.c   | 37 ---
 src/egl/wayland/wayland-drm/wayland-drm.c |  6 +
 2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 02b32f9..3633c83 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -61,6 +61,8 @@ enum wl_drm_format_flags {
HAS_ARGB = 1,
HAS_XRGB = 2,
HAS_RGB565 = 4,
+   HAS_ARGB2101010 = 8,
+   HAS_XRGB2101010 = 16,
 };
 
 static int
@@ -148,10 +150,14 @@ dri2_wl_create_window_surface(_EGLDriver *drv, 
_EGLDisplay *disp,
if (dri2_dpy->wl_dmabuf || dri2_dpy->wl_drm) {
   if (conf->RedSize == 5)
  dri2_surf->format = WL_DRM_FORMAT_RGB565;
-  else if (conf->AlphaSize == 0)
+  else if (conf->RedSize == 8 && conf->AlphaSize == 0)
  dri2_surf->format = WL_DRM_FORMAT_XRGB;
-  else
+  else if (conf->RedSize == 8)
  dri2_surf->format = WL_DRM_FORMAT_ARGB;
+  else if (conf->RedSize == 10 && conf->AlphaSize == 0)
+ dri2_surf->format = WL_DRM_FORMAT_XRGB2101010;
+  else if (conf->RedSize == 10)
+ dri2_surf->format = WL_DRM_FORMAT_ARGB2101010;
} else {
   assert(dri2_dpy->wl_shm);
   if (conf->RedSize == 5)
@@ -340,11 +346,18 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
uint64_t *modifiers;
int num_modifiers;
 
-   /* currently supports three WL DRM formats,
+   /* currently supports five WL DRM formats,
+* WL_DRM_FORMAT_ARGB2101010, WL_DRM_FORMAT_XRGB2101010,
 * WL_DRM_FORMAT_ARGB, WL_DRM_FORMAT_XRGB,
 * and WL_DRM_FORMAT_RGB565
 */
switch (dri2_surf->format) {
+   case WL_DRM_FORMAT_ARGB2101010:
+  dri_image_format = __DRI_IMAGE_FORMAT_ARGB2101010;
+  break;
+   case WL_DRM_FORMAT_XRGB2101010:
+  dri_image_format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  break;
case WL_DRM_FORMAT_ARGB:
   dri_image_format = __DRI_IMAGE_FORMAT_ARGB;
   modifiers = u_vector_tail(_dpy->wl_modifiers.argb);
@@ -581,6 +594,8 @@ dri2_wl_get_buffers(__DRIdrawable * driDrawable,
unsigned int bpp;
 
switch (dri2_surf->format) {
+   case WL_DRM_FORMAT_ARGB2101010:
+   case WL_DRM_FORMAT_XRGB2101010:
case WL_DRM_FORMAT_ARGB:
case WL_DRM_FORMAT_XRGB:
   bpp = 32;
@@ -972,6 +987,14 @@ dri2_wl_create_wayland_buffer_from_image(_EGLDriver *drv,
 
dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_FORMAT, );
switch (format) {
+   case __DRI_IMAGE_FORMAT_ARGB2101010:
+  if (!(dri2_dpy->formats & HAS_ARGB2101010))
+ goto bad_format;
+  break;
+   case __DRI_IMAGE_FORMAT_XRGB2101010:
+  if (!(dri2_dpy->formats & HAS_XRGB2101010))
+ goto bad_format;
+  break;
case __DRI_IMAGE_FORMAT_ARGB:
   if (!(dri2_dpy->formats & HAS_ARGB))
  goto bad_format;
@@ -1059,6 +1082,12 @@ drm_handle_format(void *data, struct wl_drm *drm, 
uint32_t format)
struct dri2_egl_display *dri2_dpy = data;
 
switch (format) {
+   case WL_DRM_FORMAT_ARGB2101010:
+  dri2_dpy->formats |= HAS_ARGB2101010;
+  break;
+   case WL_DRM_FORMAT_XRGB2101010:
+  dri2_dpy->formats |= HAS_XRGB2101010;
+  break;
case WL_DRM_FORMAT_ARGB:
   dri2_dpy->formats |= HAS_ARGB;
   break;
@@ -1227,6 +1256,8 @@ dri2_wl_add_configs_for_visuals(_EGLDriver *drv, 
_EGLDisplay *disp)
   int has_format;
   unsigned int rgba_masks[4];
} visuals[] = {
+  { "XRGB2101010", HAS_XRGB2101010, { 0x3ff0, 0xffc00, 0x3ff, 0 } },
+  { "ARGB2101010", HAS_ARGB2101010, { 0x3ff0, 0xffc00, 0x3ff, 
0xc000 } },
   { "XRGB", HAS_XRGB, { 0xff, 0xff00, 0x00ff, 0xff00 } },
   { "ARGB", HAS_ARGB, { 0xff, 0xff00, 0x00ff, 0 } },
   { "RGB565",   HAS_RGB565,   { 0x00f800, 0x07e0, 0x001f, 0 } },
diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c 
b/src/egl/wayland/wayland-drm/wayland-drm.c
index 81f6f528..3c6696d 100644
--- a/src/egl/wayland/wayland-drm/wayland-drm.c
+++ b/src/egl/wayland/wayland-drm/wayland-drm.c
@@ -111,6 +111,8 @@ drm_create_buffer(struct wl_client *client, struct 
wl_resource *resource,
  uint32_t stride, uint32_t format)
 {
 switch (format) {
+case WL_DRM_FORMAT_ARGB2101010:
+case WL_DRM_FORMAT_XRGB2101010:
 case WL_DRM_FORMAT_ARGB:
 case WL_DRM_FORMAT_XRGB:
 case WL_DRM_FORMAT_YUYV:
@@ -209,6 +211,10 @@ bind_drm(struct wl_client *client, v

[Mesa-dev] [PATCH 18/22] st/dri2: Add buffer handling for BGR[A/X]1010102 formats.

[Mario Kleiner]

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/gallium/state_trackers/dri/dri2.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index f7fd08d..e3b9377 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -398,10 +398,14 @@ dri2_drawable_get_buffers(struct dri_drawable *drawable,
* may occur as the stvis->color_format.
*/
   switch(format) {
+  case PIPE_FORMAT_B10G10R10A2_UNORM:
   case PIPE_FORMAT_BGRA_UNORM:
   case PIPE_FORMAT_RGBA_UNORM:
 depth = 32;
 break;
+  case PIPE_FORMAT_B10G10R10X2_UNORM:
+ depth = 30;
+ break;
   case PIPE_FORMAT_BGRX_UNORM:
   case PIPE_FORMAT_RGBX_UNORM:
 depth = 24;
@@ -485,6 +489,12 @@ dri_image_drawable_get_buffers(struct dri_drawable 
*drawable,
   case PIPE_FORMAT_RGBA_UNORM:
  image_format = __DRI_IMAGE_FORMAT_ABGR;
  break;
+  case PIPE_FORMAT_B10G10R10X2_UNORM:
+ image_format = __DRI_IMAGE_FORMAT_XRGB2101010;
+ break;
+  case PIPE_FORMAT_B10G10R10A2_UNORM:
+ image_format = __DRI_IMAGE_FORMAT_ARGB2101010;
+ break;
   default:
  image_format = __DRI_IMAGE_FORMAT_NONE;
  break;
@@ -531,6 +541,9 @@ dri2_allocate_buffer(__DRIscreen *sPriv,
   case 32:
  pf = PIPE_FORMAT_BGRA_UNORM;
  break;
+  case 30:
+ pf = PIPE_FORMAT_B10G10R10X2_UNORM;
+ break;
   case 24:
  pf = PIPE_FORMAT_BGRX_UNORM;
  break;
-- 
2.7.4

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

[Mesa-dev] [PATCH 15/22] egl/wayland: Add Wayland shm swrast support for RGB10 winsys buffers.

[Mario Kleiner]

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/egl/drivers/dri2/platform_wayland.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 7451027..4a0b8c2 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -162,10 +162,14 @@ dri2_wl_create_window_surface(_EGLDriver *drv, 
_EGLDisplay *disp,
   assert(dri2_dpy->wl_shm);
   if (conf->RedSize == 5)
  dri2_surf->format = WL_SHM_FORMAT_RGB565;
-  else if (conf->AlphaSize == 0)
+  else if (conf->RedSize == 8 && conf->AlphaSize == 0)
  dri2_surf->format = WL_SHM_FORMAT_XRGB;
-  else
+  else if (conf->RedSize == 8)
  dri2_surf->format = WL_SHM_FORMAT_ARGB;
+  else if (conf->RedSize == 10 && conf->AlphaSize == 0)
+ dri2_surf->format = WL_SHM_FORMAT_XRGB2101010;
+  else if (conf->RedSize == 10)
+ dri2_surf->format = WL_SHM_FORMAT_ARGB2101010;
}
 
dri2_surf->wl_queue = wl_display_create_queue(dri2_dpy->wl_dpy);
@@ -1469,7 +1473,7 @@ dri2_wl_swrast_get_stride_for_format(int format, int w)
 {
if (format == WL_SHM_FORMAT_RGB565)
   return 2 * w;
-   else /* ARGB || XRGB */
+   else /* ARGB || XRGB || ARGB2101010 || XRGB2101010 */
   return 4 * w;
 }
 
@@ -1894,6 +1898,12 @@ shm_handle_format(void *data, struct wl_shm *shm, 
uint32_t format)
struct dri2_egl_display *dri2_dpy = data;
 
switch (format) {
+   case WL_SHM_FORMAT_ARGB2101010:
+  dri2_dpy->formats |= HAS_ARGB2101010;
+  break;
+   case WL_SHM_FORMAT_XRGB2101010:
+  dri2_dpy->formats |= HAS_XRGB2101010;
+  break;
case WL_SHM_FORMAT_ARGB:
   dri2_dpy->formats |= HAS_ARGB;
   break;
-- 
2.7.4

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

[Mesa-dev] [PATCH 14/22] egl/wayland: Add Wayland dmabuf support for RGB10 winsys buffers. (v2)

[Mario Kleiner]

Successfully tested under Weston 3.0.
Photometer confirms 10 rgb bits from rendering to display.

v2: Rebased onto master for dri2_teardown_wayland().

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/egl/drivers/dri2/egl_dri2.h |  2 ++
 src/egl/drivers/dri2/platform_wayland.c | 18 +-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index ef375b6..cc76c73 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -212,6 +212,8 @@ struct dri2_egl_display
struct wl_event_queue*wl_queue;
struct zwp_linux_dmabuf_v1 *wl_dmabuf;
struct {
+  struct u_vectorxrgb2101010;
+  struct u_vectorargb2101010;
   struct u_vectorxrgb;
   struct u_vectorargb;
   struct u_vectorrgb565;
diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 3633c83..7451027 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -354,9 +354,13 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
switch (dri2_surf->format) {
case WL_DRM_FORMAT_ARGB2101010:
   dri_image_format = __DRI_IMAGE_FORMAT_ARGB2101010;
+  modifiers = u_vector_tail(_dpy->wl_modifiers.argb2101010);
+  num_modifiers = u_vector_length(_dpy->wl_modifiers.argb2101010);
   break;
case WL_DRM_FORMAT_XRGB2101010:
   dri_image_format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  modifiers = u_vector_tail(_dpy->wl_modifiers.xrgb2101010);
+  num_modifiers = u_vector_length(_dpy->wl_modifiers.xrgb2101010);
   break;
case WL_DRM_FORMAT_ARGB:
   dri_image_format = __DRI_IMAGE_FORMAT_ARGB;
@@ -1143,6 +1147,14 @@ dmabuf_handle_modifier(void *data, struct 
zwp_linux_dmabuf_v1 *dmabuf,
   return;
 
switch (format) {
+   case WL_DRM_FORMAT_ARGB2101010:
+  mod = u_vector_add(_dpy->wl_modifiers.argb2101010);
+  dri2_dpy->formats |= HAS_ARGB2101010;
+  break;
+   case WL_DRM_FORMAT_XRGB2101010:
+  mod = u_vector_add(_dpy->wl_modifiers.xrgb2101010);
+  dri2_dpy->formats |= HAS_XRGB2101010;
+  break;
case WL_DRM_FORMAT_ARGB:
   mod = u_vector_add(_dpy->wl_modifiers.argb);
   dri2_dpy->formats |= HAS_ARGB;
@@ -1314,7 +1326,9 @@ dri2_initialize_wayland_drm(_EGLDriver *drv, _EGLDisplay 
*disp)
   dri2_dpy->wl_dpy = disp->PlatformDisplay;
}
 
-   if (!u_vector_init(_dpy->wl_modifiers.xrgb, sizeof(uint64_t), 32) 
||
+   if (!u_vector_init(_dpy->wl_modifiers.xrgb2101010, sizeof(uint64_t), 
32) ||
+   !u_vector_init(_dpy->wl_modifiers.argb2101010, sizeof(uint64_t), 
32) ||
+   !u_vector_init(_dpy->wl_modifiers.xrgb, sizeof(uint64_t), 32) 
||
!u_vector_init(_dpy->wl_modifiers.argb, sizeof(uint64_t), 32) 
||
!u_vector_init(_dpy->wl_modifiers.rgb565, sizeof(uint64_t), 32)) {
   goto cleanup;
@@ -2055,6 +2069,8 @@ dri2_teardown_wayland(struct dri2_egl_display *dri2_dpy)
   wl_event_queue_destroy(dri2_dpy->wl_queue);
if (dri2_dpy->wl_dpy_wrapper)
   wl_proxy_wrapper_destroy(dri2_dpy->wl_dpy_wrapper);
+   u_vector_finish(_dpy->wl_modifiers.argb2101010);
+   u_vector_finish(_dpy->wl_modifiers.xrgb2101010);
u_vector_finish(_dpy->wl_modifiers.argb);
u_vector_finish(_dpy->wl_modifiers.xrgb);
u_vector_finish(_dpy->wl_modifiers.rgb565);
-- 
2.7.4

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

[Mesa-dev] [PATCH 10/22] egl/x11: Match depth 30 RGB visuals to 32-bit RGBA EGLConfigs.

[Mario Kleiner]

Similar to the matching of 24 bit RGB visuals to 32-bit
RGBA EGLConfigs, so X11 compositors won't alpha-blend any
config with a destination alpha buffer during compositing.

Additionally this fixes failure to select ARGB2101010
configs via eglChooseConfig() with EGL_ALPHA_BITS 2 on
a depth 30 X-Screen. The X-Server doesn't provide any
visuals of depth 32 for ARGB2101010 configs, it only
provides depth 30 visuals. Therefore if we'd only match
ARGB2101010 configs to depth 32 RGBA visuals, we would
not ever get a visual for such a config.

This was apparent in piglit tests for egl configs, which
are fixed by this commit.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/egl/drivers/dri2/platform_x11.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index 8ede590b..d22b83f 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -782,13 +782,14 @@ dri2_x11_add_configs_for_visuals(struct dri2_egl_display 
*dri2_dpy,
   config_count++;
 
 /* Allow a 24-bit RGB visual to match a 32-bit RGBA EGLConfig.
+ * Ditto for 30-bit RGB visuals to match a 32-bit RGBA EGLConfig.
  * Otherwise it will only match a 32-bit RGBA visual.  On a
  * composited window manager on X11, this will make all of the
  * EGLConfigs with destination alpha get blended by the
  * compositor.  This is probably not what the application
  * wants... especially on drivers that only have 32-bit RGBA
  * EGLConfigs! */
-if (d.data->depth == 24) {
+if (d.data->depth == 24 || d.data->depth == 30) {
rgba_masks[3] =
   ~(rgba_masks[0] | rgba_masks[1] | rgba_masks[2]);
dri2_conf = dri2_add_config(disp, config, config_count + 1,
-- 
2.7.4

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

[Mesa-dev] [PATCH 09/22] mesa: Add GL_RGBA + GL_UNSIGNED_INT_2_10_10_10_REV for OES read type.

[Mario Kleiner]

This format + type combo is good for BGRA1010102 framebuffers
for use with glReadPixels() under GLES, so add it for the
GL_IMPLEMENTATION_COLOR_READ_TYPE_OES query.

Allows successful testing of 10 bpc / depth 30 rendering with dEQP test
case dEQP-EGL.functional.wide_color.window_1010102_colorspace_default.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/mesa/main/framebuffer.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index b17d7cb..a0de669 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -889,6 +889,9 @@ _mesa_get_color_read_type(struct gl_context *ctx,
   if (format == MESA_FORMAT_B5G6R5_UNORM)
  return GL_UNSIGNED_SHORT_5_6_5;
 
+  if (format == MESA_FORMAT_B10G10R10A2_UNORM)
+ return GL_UNSIGNED_INT_2_10_10_10_REV;
+
   switch (data_type) {
   case GL_SIGNED_NORMALIZED:
  return GL_BYTE;
-- 
2.7.4

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

[Mesa-dev] [PATCH 08/22] i965/screen: Honor 'allow_rgb10_configs' option. (v2)

[Mario Kleiner]

Allows to prevent exposing RGB10 configs and visuals to
clients.

v2: Rename expose_rgb10_configs to allow_rgb10_configs,
as suggested by Emil.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
---
 src/mesa/drivers/dri/i965/intel_screen.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 668440a..2ce73f4 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -2114,11 +2114,20 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
else
   num_formats = ARRAY_SIZE(formats) - 2; /* all - RGBA_ORDERING formats */
 
+   /* Shall we expose 10 bpc formats? */
+   bool allow_rgb10_configs = driQueryOptionb(_screen->optionCache,
+  "allow_rgb10_configs");
+
/* Generate singlesample configs without accumulation buffer. */
for (unsigned i = 0; i < num_formats; i++) {
   __DRIconfig **new_configs;
   int num_depth_stencil_bits = 2;
 
+  if (!allow_rgb10_configs &&
+  (formats[i] == MESA_FORMAT_B10G10R10A2_UNORM ||
+   formats[i] == MESA_FORMAT_B10G10R10X2_UNORM))
+ continue;
+
   /* Starting with DRI2 protocol version 1.1 we can request a depth/stencil
* buffer that has a different number of bits per pixel than the color
* buffer, gen >= 6 supports this.
@@ -2155,6 +2164,11 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
for (unsigned i = 0; i < num_formats; i++) {
   __DRIconfig **new_configs;
 
+  if (!allow_rgb10_configs &&
+  (formats[i] == MESA_FORMAT_B10G10R10A2_UNORM ||
+  formats[i] == MESA_FORMAT_B10G10R10X2_UNORM))
+ continue;
+
   if (formats[i] == MESA_FORMAT_B5G6R5_UNORM) {
  depth_bits[0] = 16;
  stencil_bits[0] = 0;
@@ -2188,6 +2202,11 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
   if (devinfo->gen < 6)
  break;
 
+  if (!allow_rgb10_configs &&
+  (formats[i] == MESA_FORMAT_B10G10R10A2_UNORM ||
+  formats[i] == MESA_FORMAT_B10G10R10X2_UNORM))
+ continue;
+
   __DRIconfig **new_configs;
   const int num_depth_stencil_bits = 2;
   int num_msaa_modes = 0;
-- 
2.7.4

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

[Mesa-dev] [PATCH 12/22] egl/x11: Handle depth 30 drawables for EGL_KHR_image_pixmap.

[Mario Kleiner]

Enables eglCreateImageKHR() with target set to
EGL_NATIVE_PIXMAP_KHR to handle color depth 30
X11 drawables.

Note that in theory the drawable depth 32 case in the
current implementation is ambiguous: A depth 32 drawable
could be of format ARGB or ARGB2101010, therefore an
assignment of __DRI_IMAGE_FORMAT_ARGB for a pixmap of
ARGB2101010 format would be wrong. In practice however, the
X-Server (as of v1.19) does not provide any depth 32 visuals
for ARGB2101010 EGL/GLX configs. Those are associated with
depth 30 visuals without an alpha channel instead. Therefore
the switch-case depth 32 branch is only executed for ARGB
pixmaps and we get away with this.

Tested with KDE Plasma 5 under X11, DRI2 and DRI3/Present,
selecting EGL + OpenGL compositing and different fbconfigs
with/without 2 bit alpha channel. glxinfo confirms use of
depth 30 visuals for ARGB2101010 only.

Suggested-by: Eric Engestrom <eric.engest...@imgtec.com>
Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/egl/drivers/dri2/platform_x11.c  | 3 +++
 src/egl/drivers/dri2/platform_x11_dri3.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index 4750872..8b701d5 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -1049,6 +1049,9 @@ dri2_create_image_khr_pixmap(_EGLDisplay *disp, 
_EGLContext *ctx,
case 24:
   format = __DRI_IMAGE_FORMAT_XRGB;
   break;
+   case 30:
+  format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  break;
case 32:
   format = __DRI_IMAGE_FORMAT_ARGB;
   break;
diff --git a/src/egl/drivers/dri2/platform_x11_dri3.c 
b/src/egl/drivers/dri2/platform_x11_dri3.c
index eadd371..6e40eaa 100644
--- a/src/egl/drivers/dri2/platform_x11_dri3.c
+++ b/src/egl/drivers/dri2/platform_x11_dri3.c
@@ -269,6 +269,9 @@ dri3_create_image_khr_pixmap(_EGLDisplay *disp, _EGLContext 
*ctx,
case 24:
   format = __DRI_IMAGE_FORMAT_XRGB;
   break;
+   case 30:
+  format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  break;
case 32:
   format = __DRI_IMAGE_FORMAT_ARGB;
   break;
-- 
2.7.4

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

[Mesa-dev] [PATCH 11/22] egl/x11: Handle depth 30 drawables under software rasterizer.

[Mario Kleiner]

For fixing eglCreateWindowSurface() under swrast, as tested
with LIBGL_ALWAYS_SOFTWARE=1.

Suggested-by: Eric Engestrom <eric.engest...@imgtec.com>
Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/egl/drivers/dri2/platform_x11.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index d22b83f..4750872 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -75,6 +75,7 @@ swrastCreateDrawable(struct dri2_egl_display * dri2_dpy,
xcb_create_gc(dri2_dpy->conn, dri2_surf->swapgc, dri2_surf->drawable, mask, 
valgc);
switch (dri2_surf->depth) {
   case 32:
+  case 30:
   case 24:
  dri2_surf->bytes_per_pixel = 4;
  break;
-- 
2.7.4

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

[Mesa-dev] [PATCH 05/22] i965/screen: Add XRGB2101010 and ARGB2101010 support for DRI3.

[Mario Kleiner]

Allow DRI3/Present buffer sharing for 10 bpc buffers.
Otherwise composited desktops under DRI3 will only display
black client areas for redirected windows.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
---
 src/mesa/drivers/dri/i965/intel_screen.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 50346de..4748987 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -182,6 +182,12 @@ static const struct __DRI2flushExtensionRec 
intelFlushExtension = {
 };
 
 static const struct intel_image_format intel_image_formats[] = {
+   { __DRI_IMAGE_FOURCC_ARGB2101010, __DRI_IMAGE_COMPONENTS_RGBA, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB2101010, 4 } } },
+
+   { __DRI_IMAGE_FOURCC_XRGB2101010, __DRI_IMAGE_COMPONENTS_RGB, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB2101010, 4 } } },
+
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 07/22] dri/common: Add option to allow exposure of 10 bpc color configs. (v2)

[Mario Kleiner]

Some clients may not like RGB10X2 and RGB10A2 fbconfigs and
visuals. Add a new driconf option 'allow_rgb10_configs' to
allow per application enable/disable.

The option defaults to enabled.

v2: Rename expose_rgb10_configs to allow_rgb10_configs,
as suggested by Emil. Add comment to option parsing,
to make sure it stays before the ->InitScreen().

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/mesa/drivers/dri/common/dri_util.c | 12 
 src/util/xmlpool/t_options.h   |  5 +
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/common/dri_util.c 
b/src/mesa/drivers/dri/common/dri_util.c
index d504751..d4fba0b 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -55,6 +55,10 @@ const char __dri2ConfigOptions[] =
   DRI_CONF_SECTION_PERFORMANCE
  DRI_CONF_VBLANK_MODE(DRI_CONF_VBLANK_DEF_INTERVAL_1)
   DRI_CONF_SECTION_END
+
+  DRI_CONF_SECTION_MISCELLANEOUS
+ DRI_CONF_ALLOW_RGB10_CONFIGS("true")
+  DRI_CONF_SECTION_END
DRI_CONF_END;
 
 /*/
@@ -144,6 +148,10 @@ driCreateNewScreen2(int scrn, int fd,
 psp->fd = fd;
 psp->myNum = scrn;
 
+/* Option parsing before ->InitScreen(), as some options apply there. */
+driParseOptionInfo(>optionInfo, __dri2ConfigOptions);
+driParseConfigFiles(>optionCache, >optionInfo, psp->myNum, 
"dri2");
+
 *driver_configs = psp->driver->InitScreen(psp);
 if (*driver_configs == NULL) {
free(psp);
@@ -179,10 +187,6 @@ driCreateNewScreen2(int scrn, int fd,
 if (psp->max_gl_es2_version >= 30)
psp->api_mask |= (1 << __DRI_API_GLES3);
 
-driParseOptionInfo(>optionInfo, __dri2ConfigOptions);
-driParseConfigFiles(>optionCache, >optionInfo, psp->myNum, 
"dri2");
-
-
 return psp;
 }
 
diff --git a/src/util/xmlpool/t_options.h b/src/util/xmlpool/t_options.h
index bd55308..5f377c9 100644
--- a/src/util/xmlpool/t_options.h
+++ b/src/util/xmlpool/t_options.h
@@ -379,6 +379,11 @@ DRI_CONF_OPT_BEGIN_B(glsl_zero_init, def) \
 DRI_CONF_DESC(en,gettext("Force uninitialized variables to default to 
zero")) \
 DRI_CONF_OPT_END
 
+#define DRI_CONF_ALLOW_RGB10_CONFIGS(def) \
+DRI_CONF_OPT_BEGIN_B(allow_rgb10_configs, def) \
+DRI_CONF_DESC(en,gettext("Allow exposure of visuals and fbconfigs with rgb10a2 
formats")) \
+DRI_CONF_OPT_END
+
 /**
  * \brief Initialization configuration options
  */
-- 
2.7.4

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

[Mesa-dev] [PATCH 02/22] i965: Support accelerated blit for depth 30 formats. (v2)

[Mario Kleiner]

Extend intel_miptree_blit() to handle at least
ARGB2101010 -> XRGB2101010, ARGB2101010 -> ARGB2101010,
and XRGB2101010 -> XRGB2101010 via the BLT engine,
but not XRGB2101010 -> ARGB2101010 yet.

This works as tested under Compiz, KDE-5, Gnome-Shell.

v2: Restrict BLT fast path to exclude XRGB2101010 -> ARGB2101010,
as intel_miptree_set_alpha_to_one() isn't ready to set 2 bit
alpha channels to 1.0 yet. However, couldn't find a test case
where this specific blit would be needed, so maybe not much
of a point to improve here.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
---
 src/mesa/drivers/dri/i965/intel_blit.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_blit.c 
b/src/mesa/drivers/dri/i965/intel_blit.c
index 5f25bfa..46945b2 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
@@ -170,6 +170,19 @@ intel_miptree_blit_compatible_formats(mesa_format src, 
mesa_format dst)
   return (dst == MESA_FORMAT_R8G8B8A8_UNORM ||
   dst == MESA_FORMAT_R8G8B8X8_UNORM);
 
+   /* We can also discard alpha when going from A2->X2 for 2 bit alpha,
+* however we can't fill the alpha channel with two 1 bits when going
+* from X2->A2, because intel_miptree_set_alpha_to_one() is not yet
+* ready for this / can only handle 8 bit alpha.
+*/
+   if (src == MESA_FORMAT_B10G10R10A2_UNORM)
+  return (dst == MESA_FORMAT_B10G10R10A2_UNORM ||
+  dst == MESA_FORMAT_B10G10R10X2_UNORM);
+
+   if (src == MESA_FORMAT_R10G10B10A2_UNORM)
+  return (dst == MESA_FORMAT_R10G10B10A2_UNORM ||
+  dst == MESA_FORMAT_R10G10B10X2_UNORM);
+
return false;
 }
 
@@ -322,7 +335,8 @@ intel_miptree_blit(struct brw_context *brw,
/* The blitter doesn't support doing any format conversions.  We do also
 * support blitting ARGB to XRGB (trivial, the values dropped into
 * the X channel don't matter), and XRGB to ARGB by setting the A
-* channel to 1.0 at the end.
+* channel to 1.0 at the end. Also trivially ARGB2101010 to XRGB2101010,
+* but not XRGB2101010 to ARGB2101010 yet.
 */
if (!intel_miptree_blit_compatible_formats(src_format, dst_format)) {
   perf_debug("%s: Can't use hardware blitter from %s to %s, "
@@ -789,6 +803,10 @@ intel_miptree_set_alpha_to_one(struct brw_context *brw,
DBG("%s dst:buf(%p)/%d %d,%d sz:%dx%d\n",
__func__, mt->bo, pitch, x, y, width, height);
 
+   /* Note: Currently only handles 8 bit alpha channel. Extension to < 8 Bit
+* alpha channel would be likely possible via ROP code 0xfa instead of 0xf0
+* and writing a suitable bit-mask instead of 0x.
+*/
BR13 = br13_for_cpp(cpp) | 0xf0 << 16;
CMD = XY_COLOR_BLT_CMD;
CMD |= XY_BLT_WRITE_ALPHA;
-- 
2.7.4

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

[Mesa-dev] [PATCH 01/22] i965: Support xrgb/argb2101010 formats for glx_texture_from_pixmap.

[Mario Kleiner]

Makes compositing under X11/GLX work.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
---
 src/mesa/drivers/dri/i965/intel_tex_image.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c 
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index 37c8e24..2ee3658 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -464,11 +464,19 @@ intelSetTexBuffer2(__DRIcontext *pDRICtx, GLint target,
if (rb->mt->cpp == 4) {
   if (texture_format == __DRI_TEXTURE_FORMAT_RGB) {
  internal_format = GL_RGB;
- texFormat = MESA_FORMAT_B8G8R8X8_UNORM;
+ if (rb->mt->format == MESA_FORMAT_B10G10R10X2_UNORM ||
+ rb->mt->format == MESA_FORMAT_B10G10R10A2_UNORM)
+texFormat = MESA_FORMAT_B10G10R10X2_UNORM;
+ else
+texFormat = MESA_FORMAT_B8G8R8X8_UNORM;
   }
   else {
  internal_format = GL_RGBA;
- texFormat = MESA_FORMAT_B8G8R8A8_UNORM;
+ if (rb->mt->format == MESA_FORMAT_B10G10R10X2_UNORM ||
+ rb->mt->format == MESA_FORMAT_B10G10R10A2_UNORM)
+texFormat = MESA_FORMAT_B10G10R10A2_UNORM;
+ else
+texFormat = MESA_FORMAT_B8G8R8A8_UNORM;
   }
} else if (rb->mt->cpp == 2) {
   internal_format = GL_RGB;
-- 
2.7.4

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

[Mesa-dev] [PATCH 03/22] dri: Add 10 bpc formats as available formats. (v2)

[Mario Kleiner]

Used to support ARGB2101010 and XRGB2101010
winsys framebuffers / drawables, but added
other 10 bpc fourcc's as well for consistency
with definitions in wayland_drm.h, gbm.h, and
drm_fourcc.h.

v2: Align new defines with tabs instead of spaces, for
consistency with remainder of that block of definitions,
as suggested by Tapani.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 include/GL/internal/dri_interface.h | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index b479473..0fdabc7 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1261,7 +1261,15 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_FOURCC_XRGB0x34325258
 #define __DRI_IMAGE_FOURCC_ABGR0x34324241
 #define __DRI_IMAGE_FOURCC_XBGR0x34324258
-#define __DRI_IMAGE_FOURCC_SARGB0x83324258
+#define __DRI_IMAGE_FOURCC_SARGB   0x83324258
+#define __DRI_IMAGE_FOURCC_ARGB2101010 0x30335241
+#define __DRI_IMAGE_FOURCC_XRGB2101010 0x30335258
+#define __DRI_IMAGE_FOURCC_ABGR2101010 0x30334241
+#define __DRI_IMAGE_FOURCC_XBGR2101010 0x30334258
+#define __DRI_IMAGE_FOURCC_RGBA1010102 0x30334152
+#define __DRI_IMAGE_FOURCC_RGBX1010102 0x30335852
+#define __DRI_IMAGE_FOURCC_BGRA1010102 0x30334142
+#define __DRI_IMAGE_FOURCC_BGRX1010102 0x30335842
 #define __DRI_IMAGE_FOURCC_YUV410  0x39565559
 #define __DRI_IMAGE_FOURCC_YUV411  0x31315559
 #define __DRI_IMAGE_FOURCC_YUV420  0x32315559
-- 
2.7.4

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

[Mesa-dev] [PATCH 04/22] loader/dri3: Add XRGB2101010 and ARGB2101010 support.

[Mario Kleiner]

To allow DRI3/Present buffer sharing for 10 bpc buffers.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
Reviewed-by: Marek Olšák <marek.ol...@amd.com>
---
 src/loader/loader_dri3_helper.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 7e6b8b2..cc890bc 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -1018,6 +1018,8 @@ image_format_to_fourcc(int format)
case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
case __DRI_IMAGE_FORMAT_ABGR: return __DRI_IMAGE_FOURCC_ABGR;
case __DRI_IMAGE_FORMAT_XBGR: return __DRI_IMAGE_FOURCC_XBGR;
+   case __DRI_IMAGE_FORMAT_XRGB2101010: return __DRI_IMAGE_FOURCC_XRGB2101010;
+   case __DRI_IMAGE_FORMAT_ARGB2101010: return __DRI_IMAGE_FOURCC_ARGB2101010;
}
return 0;
 }
-- 
2.7.4

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

[Mesa-dev] Mesa 30 bit color depth patches, rev 4.

[Mario Kleiner]

This is mostly the same as the last series rev 3, with the following
changes:

1. Rebased onto current master, some trivial merge conflict resolved.

2. R-b's of Tapani and Marek tacked onto all patches. Only the new
   patch 22/22 is new and unreviewed.

3. Following Tapani's suggestion i moved old patch 1 to patch 6, so
   the enable for i965 30 bit formats is done after the basic dri and
   i965 bits are in place. This is more consistent with flipping the
   on-switch on gallium.

4. Added patch 22/22, so OES read type queries for glReadPixels also
   handle B10G10R10X2, not only B10G10R10A2, following Marek's advice.
   I've tested this by quickly hacking up the
   dEQP-EGL.functional.wide_color.window_1010102_colorspace_default
   test to ask for zero alpha bits, verifying via apitrace it gets
   a X2R10G10B10 format and that the precision test fails in the
   expected way, ie. with a constant alpha == 3 ( ~ 1.0f) returned
   from a fb that doesn't have an alpha channel when reading via
   glReadPixels(GL_RGBA, GL_UNSIGNED_INT_10_10_10_2_REV).

5. Finally i've dropped the nouveau patch which added a hacky
   B10G10R10X2 pixel format for visuals, which isn't actually
   supported by the driver or NVidia hardware.

   This means that depth 30 display on NVidia hardware won't work
   atm., but that needs more work on nouveau-ddx and nouveau-kms
   anyway to get it working properly.

   Prime renderoffload from a Intel or AMD display gpu to a NVidia
   gpu works, as tested on Wayland+Weston and X11, so there's some
   use to the current nouveau gallium support for depth 30.

So this one should be probably good to push after checking patch
22/22.

Thanks,
-mario

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

[Mesa-dev] [PATCH 06/22] i965/screen: Add basic support for rendering 10 bpc/depth 30 framebuffers. (v3)

[Mario Kleiner]

Expose formats which are supported at least back to Gen 5 Ironlake,
possibly further. Allow creation of 10 bpc winsys buffers for drawables.

glxinfo now lists new RGBA 10 10 10 2/0 formats.

v2: Move the BGRA/BGRX1010102 formats before the RGBA/RGBX
32 bit formats, as the code comments require. Thanks Emil!
Update num_formats from 3 to 5, to keep the special Android
handling intact.

v3: Use num_formats = ARRAY_SIZE(formats) - 2 as suggested by Tapani,
to only exclude the last 2 Android formats, add Tapani's r-b.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
---
 src/mesa/drivers/dri/i965/intel_screen.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 4748987..668440a 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1653,7 +1653,13 @@ intelCreateBuffer(__DRIscreen *dri_screen,
   fb->Visual.samples = num_samples;
}
 
-   if (mesaVis->redBits == 5) {
+   if (mesaVis->redBits == 10 && mesaVis->alphaBits > 0) {
+  rgbFormat = mesaVis->redMask == 0x3ff0 ? 
MESA_FORMAT_B10G10R10A2_UNORM
+ : 
MESA_FORMAT_R10G10B10A2_UNORM;
+   } else if (mesaVis->redBits == 10) {
+  rgbFormat = mesaVis->redMask == 0x3ff0 ? 
MESA_FORMAT_B10G10R10X2_UNORM
+ : 
MESA_FORMAT_R10G10B10X2_UNORM;
+   } else if (mesaVis->redBits == 5) {
   rgbFormat = mesaVis->redMask == 0x1f ? MESA_FORMAT_R5G6B5_UNORM
: MESA_FORMAT_B5G6R5_UNORM;
} else if (mesaVis->sRGBCapable) {
@@ -2063,6 +2069,10 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
 
   MESA_FORMAT_B8G8R8A8_SRGB,
 
+  /* For 10 bpc, 30 bit depth framebuffers. */
+  MESA_FORMAT_B10G10R10A2_UNORM,
+  MESA_FORMAT_B10G10R10X2_UNORM,
+
   /* The 32-bit RGBA format must not precede the 32-bit BGRA format.
* Likewise for RGBX and BGRX.  Otherwise, the GLX client and the GLX
* server may disagree on which format the GLXFBConfig represents,
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 22/22] st/dri: Add option to control exposure of 10 bpc color configs.

[Mario Kleiner]

Hi,

about to push out a revision 4 of the series, which has all the r-b's of 
Tapani and Marek tacked on, rebased onto current master, and remaining 
suggestions by Tapani and Marek implemented and tested. That one should 
be totally ready to push if you are happy with it.


Just one last test to do...
-mario

On 12/13/2017 05:27 PM, Marek Olšák wrote:

Mario, can we push these patches?

Marek

On Wed, Nov 29, 2017 at 5:21 AM, Mario Kleiner
<mario.kleiner...@gmail.com> wrote:

Some clients may not like rgb10 fbconfigs and visuals.
Support driconf option 'allow_rgb10_configs' on gallium
to allow per application enable/disable.h

The option defaults to enabled.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
  src/gallium/auxiliary/pipe-loader/driinfo_gallium.h | 1 +
  src/gallium/state_trackers/dri/dri_screen.c | 8 
  2 files changed, 9 insertions(+)

diff --git a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h 
b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
index d2d2c9d..db0d633 100644
--- a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
+++ b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
@@ -31,4 +31,5 @@ DRI_CONF_SECTION_END
  DRI_CONF_SECTION_MISCELLANEOUS
 DRI_CONF_ALWAYS_HAVE_DEPTH_BUFFER("false")
 DRI_CONF_GLSL_ZERO_INIT("false")
+   DRI_CONF_ALLOW_RGB10_CONFIGS("true")
  DRI_CONF_SECTION_END
diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
b/src/gallium/state_trackers/dri/dri_screen.c
index 04afe71..d307b4f 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -156,6 +156,7 @@ dri_fill_in_modes(struct dri_screen *screen)
 struct pipe_screen *p_screen = screen->base.screen;
 boolean pf_z16, pf_x8z24, pf_z24x8, pf_s8z24, pf_z24s8, pf_z32;
 boolean mixed_color_depth;
+   boolean allow_rgb10;

 static const GLenum back_buffer_modes[] = {
__DRI_ATTRIB_SWAP_NONE, __DRI_ATTRIB_SWAP_UNDEFINED,
@@ -172,6 +173,8 @@ dri_fill_in_modes(struct dri_screen *screen)
depth_buffer_factor = 1;
 }

+   allow_rgb10 = driQueryOptionb(>dev->option_cache, 
"allow_rgb10_configs");
+
 msaa_samples_max = (screen->st_api->feature_mask & 
ST_API_FEATURE_MS_VISUALS_MASK)
? MSAA_VISUAL_MAX_SAMPLES : 1;

@@ -231,6 +234,11 @@ dri_fill_in_modes(struct dri_screen *screen)
unsigned num_msaa_modes = 0; /* includes a single-sample mode */
uint8_t msaa_modes[MSAA_VISUAL_MAX_SAMPLES];

+  if (!allow_rgb10 &&
+  (mesa_formats[format] == MESA_FORMAT_B10G10R10A2_UNORM ||
+   mesa_formats[format] == MESA_FORMAT_B10G10R10X2_UNORM))
+ continue;
+
if (!p_screen->is_format_supported(p_screen, pipe_formats[format],
   PIPE_TEXTURE_2D, 0,
   PIPE_BIND_RENDER_TARGET))
--
2.7.4

___
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 22/22] st/dri: Add option to control exposure of 10 bpc color configs.

[Mario Kleiner]

On 12/13/2017 05:27 PM, Marek Olšák wrote:

Mario, can we push these patches?

Marek



Sorry for the late response and thanks for the reviews! Was a bit sick 
the last days, so couldn't think or do anything about the recent 
comments so far.


I think all patches have a r-b by you and/or Tapani, except the nouveau 
patch 20/22 on which Ilia commented. Not sure about that one. If we 
leave it out then stuff breaks on nouveau. If we leave it in, then as 
far as i understand Ilia's comments, we have a slight violation of spec 
atm. - If a app asks for a framebuffer without alpha channel 
(xrgb2101010), but then enables blending with DST_ALPHA it would 
potentially get random 2 x-bit trash instead of a well defined 1.0 
DST_ALPHA. Otoh. it would be legal but a bit non-sensical for an app to 
ask for no alpha channel, but then choose blend functions that only make 
sense with an alpha channel?


The third option would be to replace that patch with one that disables 
the rgb10 support for visuals on nouveau completely until we have a 
solution for properly emulating xrgb201010 on nouveau to cover such 
corner cases?


-mario



On Wed, Nov 29, 2017 at 5:21 AM, Mario Kleiner
<mario.kleiner...@gmail.com> wrote:

Some clients may not like rgb10 fbconfigs and visuals.
Support driconf option 'allow_rgb10_configs' on gallium
to allow per application enable/disable.

The option defaults to enabled.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
  src/gallium/auxiliary/pipe-loader/driinfo_gallium.h | 1 +
  src/gallium/state_trackers/dri/dri_screen.c | 8 
  2 files changed, 9 insertions(+)

diff --git a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h 
b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
index d2d2c9d..db0d633 100644
--- a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
+++ b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
@@ -31,4 +31,5 @@ DRI_CONF_SECTION_END
  DRI_CONF_SECTION_MISCELLANEOUS
 DRI_CONF_ALWAYS_HAVE_DEPTH_BUFFER("false")
 DRI_CONF_GLSL_ZERO_INIT("false")
+   DRI_CONF_ALLOW_RGB10_CONFIGS("true")
  DRI_CONF_SECTION_END
diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
b/src/gallium/state_trackers/dri/dri_screen.c
index 04afe71..d307b4f 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -156,6 +156,7 @@ dri_fill_in_modes(struct dri_screen *screen)
 struct pipe_screen *p_screen = screen->base.screen;
 boolean pf_z16, pf_x8z24, pf_z24x8, pf_s8z24, pf_z24s8, pf_z32;
 boolean mixed_color_depth;
+   boolean allow_rgb10;

 static const GLenum back_buffer_modes[] = {
__DRI_ATTRIB_SWAP_NONE, __DRI_ATTRIB_SWAP_UNDEFINED,
@@ -172,6 +173,8 @@ dri_fill_in_modes(struct dri_screen *screen)
depth_buffer_factor = 1;
 }

+   allow_rgb10 = driQueryOptionb(>dev->option_cache, 
"allow_rgb10_configs");
+
 msaa_samples_max = (screen->st_api->feature_mask & 
ST_API_FEATURE_MS_VISUALS_MASK)
? MSAA_VISUAL_MAX_SAMPLES : 1;

@@ -231,6 +234,11 @@ dri_fill_in_modes(struct dri_screen *screen)
unsigned num_msaa_modes = 0; /* includes a single-sample mode */
uint8_t msaa_modes[MSAA_VISUAL_MAX_SAMPLES];

+  if (!allow_rgb10 &&
+  (mesa_formats[format] == MESA_FORMAT_B10G10R10A2_UNORM ||
+   mesa_formats[format] == MESA_FORMAT_B10G10R10X2_UNORM))
+ continue;
+
if (!p_screen->is_format_supported(p_screen, pipe_formats[format],
   PIPE_TEXTURE_2D, 0,
   PIPE_BIND_RENDER_TARGET))
--
2.7.4

___
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 20/22] nv50, nvc0: Support BGRX1010102 format for visuals.

[Mario Kleiner]

On 11/29/2017 04:38 PM, Ilia Mirkin wrote:

Why is this required? Can't you just use the BGR10_A2 format directly?



If i don't define this PIPE_FORMAT_B10G10R10X2_UNORM as "TD" = 
displayable, then it doesn't get exposed by the state tracker as a 
visual/fbconfig with RGBA = 10 10 10 0 under nouveau.


Wayland's Weston doesn't like that at all and gives a screen with pixel 
trash instead of a proper desktop, probably because it falls back to a 
BGRA1010102 format with alpha channel, that might indeed be zero.


On X11, all redirected/composited rendering only gives a black window 
client area, e.g., glxgears ends up as a black rectangle.


With the patch i get proper Weston display, and proper composited X11. 
"Proper" within the limitations imposed by my hacks + tbd work on the 
ddx and kms driver.



The problem with exposing these sorts of formats is that blending with
DST_ALPHA would be incorrect -- it should get read in as 1.0, but will
end up with bogus values.


Hm. My own application uses DST_ALPHA and ONE_MINUS_DST_ALPHA blending 
on the window system backbuffer in some demos and it seems to work fine 
on nouveau in depth 30 from what i can see. Not sure if this is due to 
the way my demos handle this though and there might be other cases that 
misbehave like you describe.


Unfortunately nv50/g80_defs.xml.h doesn't define a BGR10 surface format 
without alpha channel.


-mario



Cheers,

   -ilia

On Tue, Nov 28, 2017 at 11:21 PM, Mario Kleiner
<mario.kleiner...@gmail.com> wrote:

Add it as displayable/scanout capable, so it can be
exposed as valid visual/fbconfig.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
  src/gallium/drivers/nouveau/nv50/nv50_formats.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_formats.c 
b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
index 706c34f..f2f9a4f 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_formats.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
@@ -154,6 +154,7 @@ const struct nv50_format 
nv50_format_table[PIPE_FORMAT_COUNT] =

 C4(A, R10G10B10A2_UNORM, RGB10_A2_UNORM, R, G, B, A, UNORM, A2B10G10R10, 
IB),
 C4(A, B10G10R10A2_UNORM, BGR10_A2_UNORM, B, G, R, A, UNORM, A2B10G10R10, 
TD),
+   F3(A, B10G10R10X2_UNORM, BGR10_A2_UNORM, B, G, R, xx, UNORM, A2B10G10R10, 
TD),
 C4(A, R10G10B10A2_SNORM, NONE, R, G, B, A, SNORM, A2B10G10R10, T),
 C4(A, B10G10R10A2_SNORM, NONE, B, G, R, A, SNORM, A2B10G10R10, T),
 C4(A, R10G10B10A2_UINT, RGB10_A2_UINT, R, G, B, A, UINT, A2B10G10R10, TR),
--
2.7.4

___
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 19/22] st/dri: Support texture_from_pixmap for BGR[A/X]1010102 formats.

[Mario Kleiner]

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/gallium/state_trackers/dri/dri_drawable.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/state_trackers/dri/dri_drawable.c 
b/src/gallium/state_trackers/dri/dri_drawable.c
index 92ce9d2..a5999be 100644
--- a/src/gallium/state_trackers/dri/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/dri_drawable.c
@@ -260,6 +260,9 @@ dri_set_tex_buffer2(__DRIcontext *pDRICtx, GLint target,
   if (format == __DRI_TEXTURE_FORMAT_RGB)  {
  /* only need to cover the formats recognized by dri_fill_st_visual */
  switch (internal_format) {
+ case PIPE_FORMAT_B10G10R10A2_UNORM:
+internal_format = PIPE_FORMAT_B10G10R10X2_UNORM;
+break;
  case PIPE_FORMAT_BGRA_UNORM:
 internal_format = PIPE_FORMAT_BGRX_UNORM;
 break;
-- 
2.7.4

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

[Mesa-dev] [PATCH 17/22] st/dri2: Add format translations for BGR[A/X]1010102 formats.

[Mario Kleiner]

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/gallium/state_trackers/dri/dri2.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index a70f37f..b8333f6 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -55,6 +55,8 @@
 #endif
 
 static const int fourcc_formats[] = {
+   __DRI_IMAGE_FOURCC_ARGB2101010,
+   __DRI_IMAGE_FOURCC_XRGB2101010,
__DRI_IMAGE_FOURCC_ARGB,
__DRI_IMAGE_FOURCC_ABGR,
__DRI_IMAGE_FOURCC_SARGB,
@@ -105,6 +107,14 @@ static int convert_fourcc(int format, int 
*dri_components_p)
   format = __DRI_IMAGE_FORMAT_XBGR;
   dri_components = __DRI_IMAGE_COMPONENTS_RGB;
   break;
+   case __DRI_IMAGE_FOURCC_ARGB2101010:
+  format = __DRI_IMAGE_FORMAT_ARGB2101010;
+  dri_components = __DRI_IMAGE_COMPONENTS_RGBA;
+  break;
+   case __DRI_IMAGE_FOURCC_XRGB2101010:
+  format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  dri_components = __DRI_IMAGE_COMPONENTS_RGB;
+  break;
case __DRI_IMAGE_FOURCC_R8:
   format = __DRI_IMAGE_FORMAT_R8;
   dri_components = __DRI_IMAGE_COMPONENTS_R;
@@ -166,6 +176,12 @@ static int convert_to_fourcc(int format)
case __DRI_IMAGE_FORMAT_XBGR:
   format = __DRI_IMAGE_FOURCC_XBGR;
   break;
+   case __DRI_IMAGE_FORMAT_ARGB2101010:
+  format = __DRI_IMAGE_FOURCC_ARGB2101010;
+  break;
+   case __DRI_IMAGE_FORMAT_XRGB2101010:
+  format = __DRI_IMAGE_FOURCC_XRGB2101010;
+  break;
case __DRI_IMAGE_FORMAT_R8:
   format = __DRI_IMAGE_FOURCC_R8;
   break;
@@ -198,6 +214,12 @@ static enum pipe_format dri2_format_to_pipe_format (int 
format)
case __DRI_IMAGE_FORMAT_ABGR:
   pf = PIPE_FORMAT_RGBA_UNORM;
   break;
+   case __DRI_IMAGE_FORMAT_XRGB2101010:
+  pf = PIPE_FORMAT_B10G10R10X2_UNORM;
+  break;
+   case __DRI_IMAGE_FORMAT_ARGB2101010:
+  pf = PIPE_FORMAT_B10G10R10A2_UNORM;
+  break;
case __DRI_IMAGE_FORMAT_R8:
   pf = PIPE_FORMAT_R8_UNORM;
   break;
@@ -253,6 +275,12 @@ static enum pipe_format fourcc_to_pipe_format(int fourcc)
case __DRI_IMAGE_FOURCC_XBGR:
   pf = PIPE_FORMAT_RGBX_UNORM;
   break;
+   case __DRI_IMAGE_FOURCC_ARGB2101010:
+  pf = PIPE_FORMAT_B10G10R10A2_UNORM;
+  break;
+   case __DRI_IMAGE_FOURCC_XRGB2101010:
+  pf = PIPE_FORMAT_B10G10R10X2_UNORM;
+  break;
 
case __DRI_IMAGE_FOURCC_NV12:
   pf = PIPE_FORMAT_NV12;
-- 
2.7.4

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

[Mesa-dev] [PATCH 09/22] mesa: Add GL_RGBA + GL_UNSIGNED_INT_2_10_10_10_REV for OES read type.

[Mario Kleiner]

This format + type combo is good for BGRA1010102 framebuffers
for use with glReadPixels() under GLES, so add it for the
GL_IMPLEMENTATION_COLOR_READ_TYPE_OES query.

Allows successful testing of 10 bpc / depth 30 rendering with dEQP test
case dEQP-EGL.functional.wide_color.window_1010102_colorspace_default.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/mesa/main/framebuffer.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index b17d7cb..a0de669 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -889,6 +889,9 @@ _mesa_get_color_read_type(struct gl_context *ctx,
   if (format == MESA_FORMAT_B5G6R5_UNORM)
  return GL_UNSIGNED_SHORT_5_6_5;
 
+  if (format == MESA_FORMAT_B10G10R10A2_UNORM)
+ return GL_UNSIGNED_INT_2_10_10_10_REV;
+
   switch (data_type) {
   case GL_SIGNED_NORMALIZED:
  return GL_BYTE;
-- 
2.7.4

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

[Mesa-dev] [PATCH 14/22] egl/wayland: Add Wayland dmabuf support for RGB10 winsys buffers. (v2)

[Mario Kleiner]

Successfully tested under Weston 3.0.
Photometer confirms 10 rgb bits from rendering to display.

v2: Rebased onto master for dri2_teardown_wayland().

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/egl/drivers/dri2/egl_dri2.h |  2 ++
 src/egl/drivers/dri2/platform_wayland.c | 18 +-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index ef375b6..cc76c73 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -212,6 +212,8 @@ struct dri2_egl_display
struct wl_event_queue*wl_queue;
struct zwp_linux_dmabuf_v1 *wl_dmabuf;
struct {
+  struct u_vectorxrgb2101010;
+  struct u_vectorargb2101010;
   struct u_vectorxrgb;
   struct u_vectorargb;
   struct u_vectorrgb565;
diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 3633c83..7451027 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -354,9 +354,13 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
switch (dri2_surf->format) {
case WL_DRM_FORMAT_ARGB2101010:
   dri_image_format = __DRI_IMAGE_FORMAT_ARGB2101010;
+  modifiers = u_vector_tail(_dpy->wl_modifiers.argb2101010);
+  num_modifiers = u_vector_length(_dpy->wl_modifiers.argb2101010);
   break;
case WL_DRM_FORMAT_XRGB2101010:
   dri_image_format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  modifiers = u_vector_tail(_dpy->wl_modifiers.xrgb2101010);
+  num_modifiers = u_vector_length(_dpy->wl_modifiers.xrgb2101010);
   break;
case WL_DRM_FORMAT_ARGB:
   dri_image_format = __DRI_IMAGE_FORMAT_ARGB;
@@ -1143,6 +1147,14 @@ dmabuf_handle_modifier(void *data, struct 
zwp_linux_dmabuf_v1 *dmabuf,
   return;
 
switch (format) {
+   case WL_DRM_FORMAT_ARGB2101010:
+  mod = u_vector_add(_dpy->wl_modifiers.argb2101010);
+  dri2_dpy->formats |= HAS_ARGB2101010;
+  break;
+   case WL_DRM_FORMAT_XRGB2101010:
+  mod = u_vector_add(_dpy->wl_modifiers.xrgb2101010);
+  dri2_dpy->formats |= HAS_XRGB2101010;
+  break;
case WL_DRM_FORMAT_ARGB:
   mod = u_vector_add(_dpy->wl_modifiers.argb);
   dri2_dpy->formats |= HAS_ARGB;
@@ -1314,7 +1326,9 @@ dri2_initialize_wayland_drm(_EGLDriver *drv, _EGLDisplay 
*disp)
   dri2_dpy->wl_dpy = disp->PlatformDisplay;
}
 
-   if (!u_vector_init(_dpy->wl_modifiers.xrgb, sizeof(uint64_t), 32) 
||
+   if (!u_vector_init(_dpy->wl_modifiers.xrgb2101010, sizeof(uint64_t), 
32) ||
+   !u_vector_init(_dpy->wl_modifiers.argb2101010, sizeof(uint64_t), 
32) ||
+   !u_vector_init(_dpy->wl_modifiers.xrgb, sizeof(uint64_t), 32) 
||
!u_vector_init(_dpy->wl_modifiers.argb, sizeof(uint64_t), 32) 
||
!u_vector_init(_dpy->wl_modifiers.rgb565, sizeof(uint64_t), 32)) {
   goto cleanup;
@@ -2055,6 +2069,8 @@ dri2_teardown_wayland(struct dri2_egl_display *dri2_dpy)
   wl_event_queue_destroy(dri2_dpy->wl_queue);
if (dri2_dpy->wl_dpy_wrapper)
   wl_proxy_wrapper_destroy(dri2_dpy->wl_dpy_wrapper);
+   u_vector_finish(_dpy->wl_modifiers.argb2101010);
+   u_vector_finish(_dpy->wl_modifiers.xrgb2101010);
u_vector_finish(_dpy->wl_modifiers.argb);
u_vector_finish(_dpy->wl_modifiers.xrgb);
u_vector_finish(_dpy->wl_modifiers.rgb565);
-- 
2.7.4

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

[Mesa-dev] [PATCH 16/22] st/mesa: Handle BGR[A/X]1010102 formats.

[Mario Kleiner]

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/mesa/state_tracker/st_cb_fbo.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
b/src/mesa/state_tracker/st_cb_fbo.c
index e2303b4..a982f87 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -286,6 +286,12 @@ st_new_renderbuffer_fb(enum pipe_format format, int 
samples, boolean sw)
strb->software = sw;
 
switch (format) {
+   case PIPE_FORMAT_B10G10R10A2_UNORM:
+  strb->Base.InternalFormat = GL_RGB10_A2;
+  break;
+   case PIPE_FORMAT_B10G10R10X2_UNORM:
+  strb->Base.InternalFormat = GL_RGB10;
+  break;
case PIPE_FORMAT_R8G8B8A8_UNORM:
case PIPE_FORMAT_B8G8R8A8_UNORM:
case PIPE_FORMAT_A8R8G8B8_UNORM:
-- 
2.7.4

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

[Mesa-dev] [PATCH 20/22] nv50, nvc0: Support BGRX1010102 format for visuals.

[Mario Kleiner]

Add it as displayable/scanout capable, so it can be
exposed as valid visual/fbconfig.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/gallium/drivers/nouveau/nv50/nv50_formats.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_formats.c 
b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
index 706c34f..f2f9a4f 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_formats.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
@@ -154,6 +154,7 @@ const struct nv50_format 
nv50_format_table[PIPE_FORMAT_COUNT] =
 
C4(A, R10G10B10A2_UNORM, RGB10_A2_UNORM, R, G, B, A, UNORM, A2B10G10R10, 
IB),
C4(A, B10G10R10A2_UNORM, BGR10_A2_UNORM, B, G, R, A, UNORM, A2B10G10R10, 
TD),
+   F3(A, B10G10R10X2_UNORM, BGR10_A2_UNORM, B, G, R, xx, UNORM, A2B10G10R10, 
TD),
C4(A, R10G10B10A2_SNORM, NONE, R, G, B, A, SNORM, A2B10G10R10, T),
C4(A, B10G10R10A2_SNORM, NONE, B, G, R, A, SNORM, A2B10G10R10, T),
C4(A, R10G10B10A2_UINT, RGB10_A2_UINT, R, G, B, A, UINT, A2B10G10R10, TR),
-- 
2.7.4

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

[Mesa-dev] [PATCH 12/22] egl/x11: Handle depth 30 drawables for EGL_KHR_image_pixmap.

[Mario Kleiner]

Enables eglCreateImageKHR() with target set to
EGL_NATIVE_PIXMAP_KHR to handle color depth 30
X11 drawables.

Note that in theory the drawable depth 32 case in the
current implementation is ambiguous: A depth 32 drawable
could be of format ARGB or ARGB2101010, therefore an
assignment of __DRI_IMAGE_FORMAT_ARGB for a pixmap of
ARGB2101010 format would be wrong. In practice however, the
X-Server (as of v1.19) does not provide any depth 32 visuals
for ARGB2101010 EGL/GLX configs. Those are associated with
depth 30 visuals without an alpha channel instead. Therefore
the switch-case depth 32 branch is only executed for ARGB
pixmaps and we get away with this.

Tested with KDE Plasma 5 under X11, DRI2 and DRI3/Present,
selecting EGL + OpenGL compositing and different fbconfigs
with/without 2 bit alpha channel. glxinfo confirms use of
depth 30 visuals for ARGB2101010 only.

Suggested-by: Eric Engestrom <eric.engest...@imgtec.com>
Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/egl/drivers/dri2/platform_x11.c  | 3 +++
 src/egl/drivers/dri2/platform_x11_dri3.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index 8e48376..61c842d 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -1050,6 +1050,9 @@ dri2_create_image_khr_pixmap(_EGLDisplay *disp, 
_EGLContext *ctx,
case 24:
   format = __DRI_IMAGE_FORMAT_XRGB;
   break;
+   case 30:
+  format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  break;
case 32:
   format = __DRI_IMAGE_FORMAT_ARGB;
   break;
diff --git a/src/egl/drivers/dri2/platform_x11_dri3.c 
b/src/egl/drivers/dri2/platform_x11_dri3.c
index eadd371..6e40eaa 100644
--- a/src/egl/drivers/dri2/platform_x11_dri3.c
+++ b/src/egl/drivers/dri2/platform_x11_dri3.c
@@ -269,6 +269,9 @@ dri3_create_image_khr_pixmap(_EGLDisplay *disp, _EGLContext 
*ctx,
case 24:
   format = __DRI_IMAGE_FORMAT_XRGB;
   break;
+   case 30:
+  format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  break;
case 32:
   format = __DRI_IMAGE_FORMAT_ARGB;
   break;
-- 
2.7.4

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

[Mesa-dev] [PATCH 21/22] st/dri: Add support for BGR[A/X]1010102 formats.

[Mario Kleiner]

Exposes RGBA 10 10 10 2 and 10 10 10 0 visuals and
fbconfigs for rendering.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/gallium/state_trackers/dri/dri_screen.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
b/src/gallium/state_trackers/dri/dri_screen.c
index 91f50fe..04afe71 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -106,6 +106,8 @@ static const __DRIconfig **
 dri_fill_in_modes(struct dri_screen *screen)
 {
static const mesa_format mesa_formats[] = {
+  MESA_FORMAT_B10G10R10A2_UNORM,
+  MESA_FORMAT_B10G10R10X2_UNORM,
   MESA_FORMAT_B8G8R8A8_UNORM,
   MESA_FORMAT_B8G8R8X8_UNORM,
   MESA_FORMAT_B8G8R8A8_SRGB,
@@ -134,6 +136,8 @@ dri_fill_in_modes(struct dri_screen *screen)
   MESA_FORMAT_R8G8B8X8_UNORM,
};
static const enum pipe_format pipe_formats[] = {
+  PIPE_FORMAT_B10G10R10A2_UNORM,
+  PIPE_FORMAT_B10G10R10X2_UNORM,
   PIPE_FORMAT_BGRA_UNORM,
   PIPE_FORMAT_BGRX_UNORM,
   PIPE_FORMAT_BGRA_SRGB,
@@ -219,7 +223,7 @@ dri_fill_in_modes(struct dri_screen *screen)
if (dri_loader_get_cap(screen, DRI_LOADER_CAP_RGBA_ORDERING))
   num_formats = ARRAY_SIZE(mesa_formats);
else
-  num_formats = 5;
+  num_formats = ARRAY_SIZE(mesa_formats) - 2; /* all - RGBA_ORDERING 
formats */
 
/* Add configs. */
for (format = 0; format < num_formats; format++) {
@@ -287,6 +291,15 @@ dri_fill_st_visual(struct st_visual *stvis, struct 
dri_screen *screen,
 
/* Deduce the color format. */
switch (mode->redMask) {
+   case 0x3FF0:
+  if (mode->alphaMask) {
+ assert(mode->alphaMask == 0xC000);
+ stvis->color_format = PIPE_FORMAT_B10G10R10A2_UNORM;
+  } else {
+ stvis->color_format = PIPE_FORMAT_B10G10R10X2_UNORM;
+  }
+  break;
+
case 0x00FF:
   if (mode->alphaMask) {
  assert(mode->alphaMask == 0xFF00);
-- 
2.7.4

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

[Mesa-dev] [PATCH 11/22] egl/x11: Handle depth 30 drawables under software rasterizer.

[Mario Kleiner]

For fixing eglCreateWindowSurface() under swrast, as tested
with LIBGL_ALWAYS_SOFTWARE=1.

Suggested-by: Eric Engestrom <eric.engest...@imgtec.com>
Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/egl/drivers/dri2/platform_x11.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index 81b1c80..8e48376 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -75,6 +75,7 @@ swrastCreateDrawable(struct dri2_egl_display * dri2_dpy,
xcb_create_gc(dri2_dpy->conn, dri2_surf->swapgc, dri2_surf->drawable, mask, 
valgc);
switch (dri2_surf->depth) {
   case 32:
+  case 30:
   case 24:
  dri2_surf->bytes_per_pixel = 4;
  break;
-- 
2.7.4

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

[Mesa-dev] [PATCH 15/22] egl/wayland: Add Wayland shm swrast support for RGB10 winsys buffers.

[Mario Kleiner]

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/egl/drivers/dri2/platform_wayland.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 7451027..4a0b8c2 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -162,10 +162,14 @@ dri2_wl_create_window_surface(_EGLDriver *drv, 
_EGLDisplay *disp,
   assert(dri2_dpy->wl_shm);
   if (conf->RedSize == 5)
  dri2_surf->format = WL_SHM_FORMAT_RGB565;
-  else if (conf->AlphaSize == 0)
+  else if (conf->RedSize == 8 && conf->AlphaSize == 0)
  dri2_surf->format = WL_SHM_FORMAT_XRGB;
-  else
+  else if (conf->RedSize == 8)
  dri2_surf->format = WL_SHM_FORMAT_ARGB;
+  else if (conf->RedSize == 10 && conf->AlphaSize == 0)
+ dri2_surf->format = WL_SHM_FORMAT_XRGB2101010;
+  else if (conf->RedSize == 10)
+ dri2_surf->format = WL_SHM_FORMAT_ARGB2101010;
}
 
dri2_surf->wl_queue = wl_display_create_queue(dri2_dpy->wl_dpy);
@@ -1469,7 +1473,7 @@ dri2_wl_swrast_get_stride_for_format(int format, int w)
 {
if (format == WL_SHM_FORMAT_RGB565)
   return 2 * w;
-   else /* ARGB || XRGB */
+   else /* ARGB || XRGB || ARGB2101010 || XRGB2101010 */
   return 4 * w;
 }
 
@@ -1894,6 +1898,12 @@ shm_handle_format(void *data, struct wl_shm *shm, 
uint32_t format)
struct dri2_egl_display *dri2_dpy = data;
 
switch (format) {
+   case WL_SHM_FORMAT_ARGB2101010:
+  dri2_dpy->formats |= HAS_ARGB2101010;
+  break;
+   case WL_SHM_FORMAT_XRGB2101010:
+  dri2_dpy->formats |= HAS_XRGB2101010;
+  break;
case WL_SHM_FORMAT_ARGB:
   dri2_dpy->formats |= HAS_ARGB;
   break;
-- 
2.7.4

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

[Mesa-dev] [PATCH 22/22] st/dri: Add option to control exposure of 10 bpc color configs.

[Mario Kleiner]

Some clients may not like rgb10 fbconfigs and visuals.
Support driconf option 'allow_rgb10_configs' on gallium
to allow per application enable/disable.

The option defaults to enabled.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/gallium/auxiliary/pipe-loader/driinfo_gallium.h | 1 +
 src/gallium/state_trackers/dri/dri_screen.c | 8 
 2 files changed, 9 insertions(+)

diff --git a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h 
b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
index d2d2c9d..db0d633 100644
--- a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
+++ b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
@@ -31,4 +31,5 @@ DRI_CONF_SECTION_END
 DRI_CONF_SECTION_MISCELLANEOUS
DRI_CONF_ALWAYS_HAVE_DEPTH_BUFFER("false")
DRI_CONF_GLSL_ZERO_INIT("false")
+   DRI_CONF_ALLOW_RGB10_CONFIGS("true")
 DRI_CONF_SECTION_END
diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
b/src/gallium/state_trackers/dri/dri_screen.c
index 04afe71..d307b4f 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -156,6 +156,7 @@ dri_fill_in_modes(struct dri_screen *screen)
struct pipe_screen *p_screen = screen->base.screen;
boolean pf_z16, pf_x8z24, pf_z24x8, pf_s8z24, pf_z24s8, pf_z32;
boolean mixed_color_depth;
+   boolean allow_rgb10;
 
static const GLenum back_buffer_modes[] = {
   __DRI_ATTRIB_SWAP_NONE, __DRI_ATTRIB_SWAP_UNDEFINED,
@@ -172,6 +173,8 @@ dri_fill_in_modes(struct dri_screen *screen)
   depth_buffer_factor = 1;
}
 
+   allow_rgb10 = driQueryOptionb(>dev->option_cache, 
"allow_rgb10_configs");
+
msaa_samples_max = (screen->st_api->feature_mask & 
ST_API_FEATURE_MS_VISUALS_MASK)
   ? MSAA_VISUAL_MAX_SAMPLES : 1;
 
@@ -231,6 +234,11 @@ dri_fill_in_modes(struct dri_screen *screen)
   unsigned num_msaa_modes = 0; /* includes a single-sample mode */
   uint8_t msaa_modes[MSAA_VISUAL_MAX_SAMPLES];
 
+  if (!allow_rgb10 &&
+  (mesa_formats[format] == MESA_FORMAT_B10G10R10A2_UNORM ||
+   mesa_formats[format] == MESA_FORMAT_B10G10R10X2_UNORM))
+ continue;
+
   if (!p_screen->is_format_supported(p_screen, pipe_formats[format],
  PIPE_TEXTURE_2D, 0,
  PIPE_BIND_RENDER_TARGET))
-- 
2.7.4

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

[Mesa-dev] [PATCH 18/22] st/dri2: Add buffer handling for BGR[A/X]1010102 formats.

[Mario Kleiner]

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/gallium/state_trackers/dri/dri2.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index b8333f6..04c153a 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -398,10 +398,14 @@ dri2_drawable_get_buffers(struct dri_drawable *drawable,
* may occur as the stvis->color_format.
*/
   switch(format) {
+  case PIPE_FORMAT_B10G10R10A2_UNORM:
   case PIPE_FORMAT_BGRA_UNORM:
   case PIPE_FORMAT_RGBA_UNORM:
 depth = 32;
 break;
+  case PIPE_FORMAT_B10G10R10X2_UNORM:
+ depth = 30;
+ break;
   case PIPE_FORMAT_BGRX_UNORM:
   case PIPE_FORMAT_RGBX_UNORM:
 depth = 24;
@@ -485,6 +489,12 @@ dri_image_drawable_get_buffers(struct dri_drawable 
*drawable,
   case PIPE_FORMAT_RGBA_UNORM:
  image_format = __DRI_IMAGE_FORMAT_ABGR;
  break;
+  case PIPE_FORMAT_B10G10R10X2_UNORM:
+ image_format = __DRI_IMAGE_FORMAT_XRGB2101010;
+ break;
+  case PIPE_FORMAT_B10G10R10A2_UNORM:
+ image_format = __DRI_IMAGE_FORMAT_ARGB2101010;
+ break;
   default:
  image_format = __DRI_IMAGE_FORMAT_NONE;
  break;
@@ -531,6 +541,9 @@ dri2_allocate_buffer(__DRIscreen *sPriv,
   case 32:
  pf = PIPE_FORMAT_BGRA_UNORM;
  break;
+  case 30:
+ pf = PIPE_FORMAT_B10G10R10X2_UNORM;
+ break;
   case 24:
  pf = PIPE_FORMAT_BGRX_UNORM;
  break;
-- 
2.7.4

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

[Mesa-dev] [PATCH 05/22] loader/dri3: Add XRGB2101010 and ARGB2101010 support.

[Mario Kleiner]

To allow DRI3/Present buffer sharing for 10 bpc buffers.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>
---
 src/loader/loader_dri3_helper.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 7e6b8b2..cc890bc 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -1018,6 +1018,8 @@ image_format_to_fourcc(int format)
case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
case __DRI_IMAGE_FORMAT_ABGR: return __DRI_IMAGE_FOURCC_ABGR;
case __DRI_IMAGE_FORMAT_XBGR: return __DRI_IMAGE_FOURCC_XBGR;
+   case __DRI_IMAGE_FORMAT_XRGB2101010: return __DRI_IMAGE_FOURCC_XRGB2101010;
+   case __DRI_IMAGE_FORMAT_ARGB2101010: return __DRI_IMAGE_FOURCC_ARGB2101010;
}
return 0;
 }
-- 
2.7.4

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

[Mesa-dev] [PATCH 08/22] i965/screen: Honor 'allow_rgb10_configs' option. (v2)

[Mario Kleiner]

Allows to prevent exposing RGB10 configs and visuals to
clients.

v2: Rename expose_rgb10_configs to allow_rgb10_configs,
as suggested by Emil.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/mesa/drivers/dri/i965/intel_screen.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 455a13c..f6853a8 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -2092,11 +2092,20 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
else
   num_formats = ARRAY_SIZE(formats) - 2; /* all - RGBA_ORDERING formats */
 
+   /* Shall we expose 10 bpc formats? */
+   bool allow_rgb10_configs = driQueryOptionb(_screen->optionCache,
+  "allow_rgb10_configs");
+
/* Generate singlesample configs without accumulation buffer. */
for (unsigned i = 0; i < num_formats; i++) {
   __DRIconfig **new_configs;
   int num_depth_stencil_bits = 2;
 
+  if (!allow_rgb10_configs &&
+  (formats[i] == MESA_FORMAT_B10G10R10A2_UNORM ||
+   formats[i] == MESA_FORMAT_B10G10R10X2_UNORM))
+ continue;
+
   /* Starting with DRI2 protocol version 1.1 we can request a depth/stencil
* buffer that has a different number of bits per pixel than the color
* buffer, gen >= 6 supports this.
@@ -2133,6 +2142,11 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
for (unsigned i = 0; i < num_formats; i++) {
   __DRIconfig **new_configs;
 
+  if (!allow_rgb10_configs &&
+  (formats[i] == MESA_FORMAT_B10G10R10A2_UNORM ||
+  formats[i] == MESA_FORMAT_B10G10R10X2_UNORM))
+ continue;
+
   if (formats[i] == MESA_FORMAT_B5G6R5_UNORM) {
  depth_bits[0] = 16;
  stencil_bits[0] = 0;
@@ -2166,6 +2180,11 @@ intel_screen_make_configs(__DRIscreen *dri_screen)
   if (devinfo->gen < 6)
  break;
 
+  if (!allow_rgb10_configs &&
+  (formats[i] == MESA_FORMAT_B10G10R10A2_UNORM ||
+  formats[i] == MESA_FORMAT_B10G10R10X2_UNORM))
+ continue;
+
   __DRIconfig **new_configs;
   const int num_depth_stencil_bits = 2;
   int num_msaa_modes = 0;
-- 
2.7.4

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

[Mesa-dev] [PATCH 13/22] egl/wayland: Add Wayland drm support for RGB10 winsys buffers.

[Mario Kleiner]

Successfully tested under Weston 3.0.
Photometer confirms 10 rgb bits from rendering to display.

Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
---
 src/egl/drivers/dri2/platform_wayland.c   | 37 ---
 src/egl/wayland/wayland-drm/wayland-drm.c |  6 +
 2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 02b32f9..3633c83 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -61,6 +61,8 @@ enum wl_drm_format_flags {
HAS_ARGB = 1,
HAS_XRGB = 2,
HAS_RGB565 = 4,
+   HAS_ARGB2101010 = 8,
+   HAS_XRGB2101010 = 16,
 };
 
 static int
@@ -148,10 +150,14 @@ dri2_wl_create_window_surface(_EGLDriver *drv, 
_EGLDisplay *disp,
if (dri2_dpy->wl_dmabuf || dri2_dpy->wl_drm) {
   if (conf->RedSize == 5)
  dri2_surf->format = WL_DRM_FORMAT_RGB565;
-  else if (conf->AlphaSize == 0)
+  else if (conf->RedSize == 8 && conf->AlphaSize == 0)
  dri2_surf->format = WL_DRM_FORMAT_XRGB;
-  else
+  else if (conf->RedSize == 8)
  dri2_surf->format = WL_DRM_FORMAT_ARGB;
+  else if (conf->RedSize == 10 && conf->AlphaSize == 0)
+ dri2_surf->format = WL_DRM_FORMAT_XRGB2101010;
+  else if (conf->RedSize == 10)
+ dri2_surf->format = WL_DRM_FORMAT_ARGB2101010;
} else {
   assert(dri2_dpy->wl_shm);
   if (conf->RedSize == 5)
@@ -340,11 +346,18 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
uint64_t *modifiers;
int num_modifiers;
 
-   /* currently supports three WL DRM formats,
+   /* currently supports five WL DRM formats,
+* WL_DRM_FORMAT_ARGB2101010, WL_DRM_FORMAT_XRGB2101010,
 * WL_DRM_FORMAT_ARGB, WL_DRM_FORMAT_XRGB,
 * and WL_DRM_FORMAT_RGB565
 */
switch (dri2_surf->format) {
+   case WL_DRM_FORMAT_ARGB2101010:
+  dri_image_format = __DRI_IMAGE_FORMAT_ARGB2101010;
+  break;
+   case WL_DRM_FORMAT_XRGB2101010:
+  dri_image_format = __DRI_IMAGE_FORMAT_XRGB2101010;
+  break;
case WL_DRM_FORMAT_ARGB:
   dri_image_format = __DRI_IMAGE_FORMAT_ARGB;
   modifiers = u_vector_tail(_dpy->wl_modifiers.argb);
@@ -581,6 +594,8 @@ dri2_wl_get_buffers(__DRIdrawable * driDrawable,
unsigned int bpp;
 
switch (dri2_surf->format) {
+   case WL_DRM_FORMAT_ARGB2101010:
+   case WL_DRM_FORMAT_XRGB2101010:
case WL_DRM_FORMAT_ARGB:
case WL_DRM_FORMAT_XRGB:
   bpp = 32;
@@ -972,6 +987,14 @@ dri2_wl_create_wayland_buffer_from_image(_EGLDriver *drv,
 
dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_FORMAT, );
switch (format) {
+   case __DRI_IMAGE_FORMAT_ARGB2101010:
+  if (!(dri2_dpy->formats & HAS_ARGB2101010))
+ goto bad_format;
+  break;
+   case __DRI_IMAGE_FORMAT_XRGB2101010:
+  if (!(dri2_dpy->formats & HAS_XRGB2101010))
+ goto bad_format;
+  break;
case __DRI_IMAGE_FORMAT_ARGB:
   if (!(dri2_dpy->formats & HAS_ARGB))
  goto bad_format;
@@ -1059,6 +1082,12 @@ drm_handle_format(void *data, struct wl_drm *drm, 
uint32_t format)
struct dri2_egl_display *dri2_dpy = data;
 
switch (format) {
+   case WL_DRM_FORMAT_ARGB2101010:
+  dri2_dpy->formats |= HAS_ARGB2101010;
+  break;
+   case WL_DRM_FORMAT_XRGB2101010:
+  dri2_dpy->formats |= HAS_XRGB2101010;
+  break;
case WL_DRM_FORMAT_ARGB:
   dri2_dpy->formats |= HAS_ARGB;
   break;
@@ -1227,6 +1256,8 @@ dri2_wl_add_configs_for_visuals(_EGLDriver *drv, 
_EGLDisplay *disp)
   int has_format;
   unsigned int rgba_masks[4];
} visuals[] = {
+  { "XRGB2101010", HAS_XRGB2101010, { 0x3ff0, 0xffc00, 0x3ff, 0 } },
+  { "ARGB2101010", HAS_ARGB2101010, { 0x3ff0, 0xffc00, 0x3ff, 
0xc000 } },
   { "XRGB", HAS_XRGB, { 0xff, 0xff00, 0x00ff, 0xff00 } },
   { "ARGB", HAS_ARGB, { 0xff, 0xff00, 0x00ff, 0 } },
   { "RGB565",   HAS_RGB565,   { 0x00f800, 0x07e0, 0x001f, 0 } },
diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c 
b/src/egl/wayland/wayland-drm/wayland-drm.c
index 81f6f528..3c6696d 100644
--- a/src/egl/wayland/wayland-drm/wayland-drm.c
+++ b/src/egl/wayland/wayland-drm/wayland-drm.c
@@ -111,6 +111,8 @@ drm_create_buffer(struct wl_client *client, struct 
wl_resource *resource,
  uint32_t stride, uint32_t format)
 {
 switch (format) {
+case WL_DRM_FORMAT_ARGB2101010:
+case WL_DRM_FORMAT_XRGB2101010:
 case WL_DRM_FORMAT_ARGB:
 case WL_DRM_FORMAT_XRGB:
 case WL_DRM_FORMAT_YUYV:
@@ -209,6 +211,10 @@ bind_drm(struct wl_client *client, void *data, uint32_t 
version, uint32_t id)
 
wl_resource