Re: Xbox Series S/X UWP

[James Jones]

On 6/6/22 09:22, Jesse Natalie wrote:
(Hopefully this goes through and not to spam like last time I tried to 
respond…)


No, neither of these would currently work with UWP.

The primary reason is that neither Khronos API has extensions to 
initialize the winsys on top of the UWP core window infrastructure. In 
theory, you could initialize Dozen for offscreen rendering and then 
explicitly marshal the contents out – that would probably work actually. 
There’s 2 more gotchas there though:


 1. The ICD loaders (OpenGL32.dll, Vulkan-1.dll) are not available in
the UWP environment. You could explicitly use the non-ICD version of
GL (i.e. Mesa’s OpenGL32.dll from the libgl-gdi target), include the
open-source Vulkan ICD loader, or use the ICD version of either
(OpenGLOn12.dll/libgallium_wgl.dll for GL – I plan to delete the
former at some point and just use the latter at some point;
vulkan_dzn.dll for VK).
 2. There’s not currently extensions for D3D12 interop either spec’d or
implemented.


What do you mean by not spec'd? Vulkan and OpenGL both have standard 
(KHR and EXT respectively) D3D12 interop extensions, in addition to 
Vulkan<->GL, Vulkan<->D3D11-and-lower.


Thanks,
-James

There’s one more problem for GL that I don’t think is problematic for 
VK, which is that it uses APIs that are banned from the UWP environment, 
specifically around inserting window hooks for Win32 framebuffer 
lifetime management. So you’d probably have to build a custom version 
that has all of that stuff stripped out to get it to be shippable in a UWP.


We (Microsoft) don’t really have plans to add this kind of stuff, at 
least not in the near future, but I’d be open to accepting contributions 
that enable this.


-Jesse

*From:* mesa-dev  *On Behalf Of 
*Daniel Price

*Sent:* Monday, June 6, 2022 5:41 AM
*To:* mesa-dev@lists.freedesktop.org
*Subject:* [EXTERNAL] Xbox Series S/X UWP



You don't often get email from riverpr...@hotmail.com 
. Learn why this is important 





Hi, I was wandering if these two layers would work with UWP on Xbox 
Series Console or if not will there be plans to add support?


https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14766 



https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14881 



Many Thanks

Dan

RE: [EXTERNAL] Re: Xbox Series S/X UWP

[Jesse Natalie]

Oh, maybe I just missed them - last time I looked I thought there were only 
D3D11 and D3D9. Guess I've got extensions I should go implement then.

-Jesse

-Original Message-
From: mesa-dev  On Behalf Of James Jones
Sent: Monday, June 13, 2022 9:54 AM
To: Jesse Natalie ; Daniel Price 
; mesa-dev@lists.freedesktop.org
Subject: [EXTERNAL] Re: Xbox Series S/X UWP

On 6/6/22 09:22, Jesse Natalie wrote:
> (Hopefully this goes through and not to spam like last time I tried to
> respond...)
> 
> No, neither of these would currently work with UWP.
> 
> The primary reason is that neither Khronos API has extensions to 
> initialize the winsys on top of the UWP core window infrastructure. In 
> theory, you could initialize Dozen for offscreen rendering and then 
> explicitly marshal the contents out - that would probably work actually.
> There's 2 more gotchas there though:
> 
>  1. The ICD loaders (OpenGL32.dll, Vulkan-1.dll) are not available in
> the UWP environment. You could explicitly use the non-ICD version of
> GL (i.e. Mesa's OpenGL32.dll from the libgl-gdi target), include the
> open-source Vulkan ICD loader, or use the ICD version of either
> (OpenGLOn12.dll/libgallium_wgl.dll for GL - I plan to delete the
> former at some point and just use the latter at some point;
> vulkan_dzn.dll for VK).
>  2. There's not currently extensions for D3D12 interop either spec'd or
> implemented.

What do you mean by not spec'd? Vulkan and OpenGL both have standard (KHR and 
EXT respectively) D3D12 interop extensions, in addition to Vulkan<->GL, 
Vulkan<->D3D11-and-lower.

Thanks,
-James

> There's one more problem for GL that I don't think is problematic for 
> VK, which is that it uses APIs that are banned from the UWP 
> environment, specifically around inserting window hooks for Win32 
> framebuffer lifetime management. So you'd probably have to build a 
> custom version that has all of that stuff stripped out to get it to be 
> shippable in a UWP.
> 
> We (Microsoft) don't really have plans to add this kind of stuff, at 
> least not in the near future, but I'd be open to accepting 
> contributions that enable this.
> 
> -Jesse
> 
> *From:* mesa-dev  *On Behalf 
> Of *Daniel Price
> *Sent:* Monday, June 6, 2022 5:41 AM
> *To:* mesa-dev@lists.freedesktop.org
> *Subject:* [EXTERNAL] Xbox Series S/X UWP
> 
>   
> 
> You don't often get email from riverpr...@hotmail.com 
> . Learn why this is important 
> 
> 
>   
> 
> Hi, I was wandering if these two layers would work with UWP on Xbox 
> Series Console or if not will there be plans to add support?
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> ab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F14766&data
> =05%7C01%7Cjenatali%40microsoft.com%7C85b835c198b54432b3a008da4d5d5189
> %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637907360449519794%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FvUVP0f9We8D0Pug6mMDamDMWV2M
> IgLTo6e6uyAFg1A%3D&reserved=0 
>  lab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F14766&dat
> a=05%7C01%7Cjenatali%40microsoft.com%7C85b835c198b54432b3a008da4d5d518
> 9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637907360449519794%7CUn
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FvUVP0f9We8D0Pug6mMDamDMWV2
> MIgLTo6e6uyAFg1A%3D&reserved=0>
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> ab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F14881&data
> =05%7C01%7Cjenatali%40microsoft.com%7C85b835c198b54432b3a008da4d5d5189
> %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637907360449519794%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=50%2F8fKmfdP6rqpBwQZzcR7IY6p
> SriPTrn0L95QVuf4I%3D&reserved=0
>  lab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F14881&dat
> a=05%7C01%7Cjenatali%40microsoft.com%7C85b835c198b54432b3a008da4d5d518
> 9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637907360449519794%7CUn
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=50%2F8fKmfdP6rqpBwQZzcR7IY6
> pSriPTrn0L95QVuf4I%3D&reserved=0>
> 
> Many Thanks
> 
> Dan
> 

Controlling how meson handles dependency()

[Jeremy Sequoia]

Hey folks,

I wanted to spend some time to get out an updated version of XQuartz to users 
to address some bugs in the previous release, and I'm hitting a build time 
issue I'm hoping folks here can help with.

TL;DR: I want to figure out how to specify how to link zlib because meson is 
detecting it incorrectly.

I'm using mesa 21.3 right now (since that is that I had in the previous 
release) and meson 0.62.1.

It looks like we detect zlib via:

dep_zlib = dependency('zlib', version : '>= 1.2.3',
 fallback : ['zlib', 'zlib_dep'],
 required : get_option('zlib'))

It looks like dependency() is implemented (in part) using cmake, which is 
giving me an undesired result when using cmake 3.22.4.  Specifically, it gives 
me a path specific to zlib that is present inside the SDK that was used to 
build cmake, not the SDK that I'm using to build mesa.  This difference in SDK 
is important because cmake is built with the current macOS SDK (which contains 
arm64 + x86_64 support), but I need to also build mesa for i386 (using an older 
macOS 10.13 SDK).  With cmake present, dependency() is returning the path to 
libz.tbd in my current SDK which is missing the i386 slice, leading to link 
failures.

If I uninstall cmake, meson detects how to compile/link correctly (ie: just use 
'-lz') with a compile test:
   {"name": "zlib", "version": "1.2.11", "compile_args": [], "link_args": 
["-lz"]}

So, I have a few questions:
  1 - Is there a way to override these entries on the meson command line?
  2 - Is there a way to tell dependency() to prefer compile test over cmake?
  3 - Is the incorrect detection here something that is probably a bug in 
mesa's use of meson, meson itself, or cmake? (ie: where do you suggest I go to 
investigate this next step)

I have a workaround for now (uninstalling cmake during the mesa build), but I'd 
certainly like to make this more reliable for others.

Thanks,
Jeremy