RE: [EXTERNAL] Re: Zink MR signoff tags

[Jesse Natalie]

Jumping on the bandwagon, I'm going to adopt this for Microsoft-owned code as 
well (src/gallium/d3d12, src/microsoft/*).

-Jesse

-Original Message-
From: mesa-dev  On Behalf Of Gert Wollny
Sent: Friday, October 7, 2022 2:37 AM
To: erik.faye-lund ; Alyssa Rosenzweig 
; Mike Blumenkrantz 
Cc: ML mesa-dev 
Subject: [EXTERNAL] Re: Zink MR signoff tags

On Wed, 2022-10-05 at 17:21 +0200, Erik Faye-Lund wrote:
> On Wed, 2022-10-05 at 08:20 -0400, Alyssa Rosenzweig wrote:
> > + for not requiring rb/ab tags ...
> 
> I think it's time to think about making this change all over Mesa as 
> well. We're deeply in bed with GitLab by now, so I don't think there's 
> a realistic chance that this isn't going to just be duplicate info any 
> time soon...

Agreed, I'll certainly do this for r600 from now on. 

- Gert

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 
> <mailto:riverpr...@hotmail.com>. Learn why this is important 
> <https://aka.ms/LearnAboutSenderIdentification>
> 
>   
> 
> 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 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> 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
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> 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
> 

RE: Xbox Series S/X UWP

[Jesse Natalie]

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

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: [Mesa-dev] Viability of Mesa 21.0.2 with Windows 10 ARM - Snapdragon/Adreno

[Jesse Natalie]

Like I said previously, most titles you'll find on Windows are not going to be 
OpenGL titles, and as such there's nothing to be gained for those titles by 
trying to leverage Mesa3D or the compatibility pack.

If you do have an app that uses OpenGL or OpenCL, I personally don't think 
there's going to be much value trying to build this code from source, for three 
reasons:

  1.  Unlike Linux, Windows includes in an inbox version of OpenGL32.dll. 
There's not a simple way to override such a thing. There is an ICD mechanism, 
but trying to use it involves some nonstandard steps (it's not just "ninja 
install" like it could be on Linux).
  2.  The compatibility pack is pretty up-to-date. As it's still early-in-life, 
we're currently updating it frequently, picking up the latest master branch 
with bugfixes (and new bugs), rather than keeping long-lived branches with 
back-ported targeted fixes only.
  3.  There's no additional functionality to be gained by building it yourself. 
There's nothing in the current distribution mechanism to disable any available 
functionality.

That said, currently if you're on a retail version of Win10, the compat pack 
that you'll have only works with Photoshop (to avoid potentially breaking other 
apps). If you're on an insider build, however, then it'll work for any app that 
you have. Feel free to let us know if you find OpenGL or OpenCL apps that don't 
work with it.

There's also https://github.com/pal1000/mesa-dist-win, which provides pre-built 
versions of Mesa3D code (or a framework making it easier to build) for Windows, 
if you do decide you want your own things.

-Jesse

From: Will Gaines 
Sent: Sunday, April 18, 2021 6:25 PM
To: mesa-dev@lists.freedesktop.org; Jesse Natalie 
Subject: [EXTERNAL] Re: Viability of Mesa 21.0.2 with Windows 10 ARM - 
Snapdragon/Adreno

Hi Jesse, first I want to thank you for providing the most cogent and clear 
assessment of the problem because all the information I've found to date is 
piecemeal and I'm the first to admit I am not a professional or have extensive 
experience with these issues. I am approaching it from being a casual lifelong 
PC gaming hobbyist so the learning curve has been steeped.

To the third point first, WL3 was just an example. The first two points are the 
bulk of what I am trying to figure out.

1) Is it worth attempting to install/compile the full Mesa3D build on the 
system specifications detailed compared to what is already available via the 
OpenCL and OpenGL Compatibility Pack (I have this along with the preview Adreno 
680 GPU driver)? Not necessarily specific to a title like WL3, but would I at 
least have more options to tweak graphics settings?

2) If the former point is affirmative and there could be more potential in an 
independent installation of Mesa3D, is there anything to consider outside the 
standard Windows installation guide given the ARM architecture to set it up? I 
guess what I'm getting at is that if I can experiment more with a separate 
install than the pack, I want to know if I can just follow the basic 
instructions or need to approach it differently like with WSL.

I very much appreciate you bearing with me particularly as I am not coming at 
this from someone with experience and practice but just a side project to see 
if I can do more with what I have. Any additional information is greatly 
appreciated; thank you again.
Will



From: Jesse Natalie mailto:jenat...@microsoft.com>>
Sent: Sunday, April 18, 2021 8:06:00 PM
To: Will Gaines mailto:uatu2...@outlook.com>>; 
mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org> 
mailto:mesa-dev@lists.freedesktop.org>>
Subject: RE: Viability of Mesa 21.0.2 with Windows 10 ARM - Snapdragon/Adreno


Hi,



I think there's a bit of a misconception here.



First, Microsoft has recently been engaging with Mesa3D to build the OpenCL(tm) 
and OpenGL(r) Compatibility 
Pack<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fp%2Fopencl-and-opengl-compatibility-pack%2F9nqpsl29bfff%3Factivetab%3Dpivot%3Aoverviewtab&data=04%7C01%7Cjenatali%40microsoft.com%7C70fdfce463bf4e211ed608d902d1e5e5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637543923527528454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OfnwSJRBQ0P8AoMWgdQ%2Bze12UHvn0Fi1zzzo%2FxftQiA%3D&reserved=0>.
 This provides some level of x86, x64, arm32, and arm64 support for OpenGL (and 
OpenCL) on Windows devices with no native drivers for these APIs (e.g. the 
Samsung Galaxy Book S).



Second, in any given application process, the host code executing on the CPU 
all needs to be the same architecture. So, if you're running an x86 game, you'd 
also need to be running an x86 graphics dri

Re: [Mesa-dev] Viability of Mesa 21.0.2 with Windows 10 ARM - Snapdragon/Adreno

[Jesse Natalie]

Hi,

I think there's a bit of a misconception here.

First, Microsoft has recently been engaging with Mesa3D to build the OpenCL(tm) 
and OpenGL(r) Compatibility 
Pack.
 This provides some level of x86, x64, arm32, and arm64 support for OpenGL (and 
OpenCL) on Windows devices with no native drivers for these APIs (e.g. the 
Samsung Galaxy Book S).

Second, in any given application process, the host code executing on the CPU 
all needs to be the same architecture. So, if you're running an x86 game, you'd 
also need to be running an x86 graphics driver, all of which need to be 
emulated. There's some exceptions to this rule, where we've enabled some 
high-frequency code to be specially-compiled to the native platform instruction 
set (called CHPE [Compiled Hybrid Portable Executable] for x86, or ARM64EC for 
x64). If you're running a DirectX game, both the D3D runtime and driver 
should've been built this way, but the application code would still need to be 
translated at runtime. The compatibility pack mentioned above doesn't yet have 
CHPE/ARM64EC builds, but we're looking into it.

Third, I doubt Wasteland 3 is an OpenGL game. 
PCGamingWiki indicates it's 
D3D11. Mesa3D currently only has API implementations for OpenGL, Vulkan, and 
D3D9, and on Windows, the only drivers available are software (swrast/llvmpipe) 
for GL/VK or layered (zink/d3d12) for GL.

-Jesse

From: mesa-dev  On Behalf Of Will Gaines
Sent: Sunday, April 18, 2021 5:51 PM
To: mesa-dev@lists.freedesktop.org
Subject: [EXTERNAL] [Mesa-dev] Viability of Mesa 21.0.2 with Windows 10 ARM - 
Snapdragon/Adreno

Hello and greetings; please indulge me as I'll probably come across as an 
idiot, but I can't seem to get a straight answer regarding what I've been 
trying to do. I sincerely hope someone will be able to lay out clearly if I'm 
on a fool's errand which is fine because I can stop wasting my time.

Briefly, I picked up a Samsung Galaxy Book S with the Snapdragon 8cx/Adreno 680 
build running Windows 10 on ARM. Based on everything I've understood, while the 
hardware isn't terrible, the architecture and MS struggling with 64-bit x86 
emulation is what could be holding it back from being a serviceable machine for 
some gaming. I didn't really get on this until I hopped on Windows Insider and 
went to the 21359 build in the Dev Channel. I've gotten stable runs of games 
like Wasteland 3 on low settings but feel like there's either a solution or 
someone has looked and found it a dead-end to get better performance.

Long story short, I think Mesa3D might work but I've combed through documents 
and logs regarding compatibility with Windows 10 ARM and an Adreno GPU. The 
latest release suggests it's possible, but before I put any more time into it I 
wanted to know if anyone had experience along these lines: can the dev build 
features support everything needed to set up and has there been any roadblocks? 
Thanks for hearing me out, I appreciate it.


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

[Mesa-dev] Non-ELF-TLS (BSD/Haiku) Performance

[Jesse Natalie]

Hi all,

While debugging an issue impacting OpenGLOn12 support for the Dolphin emulator 
on Windows (https://gitlab.freedesktop.org/mesa/mesa/-/issues/4050), I 
discovered a bug in Mesa's non-ELF-TLS path. I've got a merge request which 
will fix it (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9222), 
but I wanted to get input from maintainers for non-Windows platforms that it 
would also impact. From the root meson.build, it looks like this is BSD 
(FreeBSD/OpenBSD) and Haiku.

The bug is:
#define GET_DISPATCH() \
 (likely(_glapi_Dispatch) ? _glapi_Dispatch : _glapi_get_dispatch())

#define GET_CURRENT_CONTEXT(C)  struct gl_context *C = (struct gl_context *) \
 (likely(_glapi_Context) ? _glapi_Context : _glapi_get_context())

The idea is that as an optimization, if the app is single-threaded, a global is 
used instead thread-local data. Once the app uses a second thread, that global 
is nulled out and we fall back to using thread-local data for the 
dispatch/context storage.

However if the app calls anything which attempts to look up the current 
dispatch/context before entering this multi-threaded mode, it can get the wrong 
value, and this can result in hard-to-track-down bugs (like a thread that 
should issue no-op commands actually affecting another thread). In 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7280, Erik fixed the 
getter functions to correctly handle a thread which isn't using GL in the 
single-threaded mode, and return NULL or a dummy dispatch, but these macros 
still have the same exact bug. As a side note, I don't understand why the 
macros and functions both had the same short-circuit logic...

So here's the tradeoff: a correctness fix which should almost never be needed 
but causes hard-to-debug problems when it is needed, vs a minor performance 
impact (getting the current thread ID) for single-threaded GL applications, 
only on BSD/Haiku platforms - since I also plan to take Windows off of this 
path. I think this is the right change to make, but I'd love to get an ack from 
folks who care about Mesa on these platforms.

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

Re: [Mesa-dev] [EXTERNAL] Cross-compile from Linux to Windows

[Jesse Natalie]

What version of Mesa are you trying to build? Assuming you're using a version 
newer than 19.3 (with this change 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/986), the default 
LLVM discovery should be to use CMake. That means it looks for an installed 
LLVM in the CMake search dirs.

If you don't have 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4555, you will also 
need to explicitly request a static version of LLVM (-Dshared-llvm=false).

-Jesse

-Original Message-
From: Federico Dossena  
Sent: Monday, November 9, 2020 7:34 AM
To: Jesse Natalie ; mesa-dev@lists.freedesktop.org
Subject: Re: [EXTERNAL] [Mesa-dev] Cross-compile from Linux to Windows

Thank you for your reply.

That's where I got stuck on Windows, I can't get it to find LLVM.

I built LLVM without problems for both x86 and x86_64 in 2 separate folders, 
but when I try to build mesa, even with --cmake-prefix-path, it doesn't find 
it, it always say "Neither a subproject directory nor a llvm.wrap file was 
found".

I tried moving my LLVM files in the subprojects/llvm folder and that didn't fix 
it, I don't know what to do.

Any suggestion?

On 2020-11-09 16:06, Jesse Natalie wrote:
> Have you tried using Meson on Windows, instead of cross-compiling? If you run 
> it from a Visual Studio command prompt, it should just work out of the box, 
> at least for x86. I believe you'll need to use a cross file for amd64, but 
> the only thing you'd need to specify is the host architecture.
>
> Though I guess if you're building LLVMPipe you'll need to point it to LLVM. 
> In my experience, adding "--cmake-prefix-path" to the Meson command line 
> should work well.
>
> -Jesse
>
> -Original Message-
> From: mesa-dev  On Behalf Of 
> Federico Dossena
> Sent: Saturday, November 7, 2020 4:14 AM
> To: mesa-dev@lists.freedesktop.org
> Subject: [EXTERNAL] [Mesa-dev] Cross-compile from Linux to Windows
>
> I'm sorry to bother you in the dev list but it seems to be the only one with 
> activity so it seems like the best place to ask.
>
> I maintain some Mesa builds for Windows. These are builds of libgl-gdi with 
> llvmpipe, for both x86 and x86_64; in other words, they're opengl32.dll files 
> that users can drop into their game/application to have software rendering 
> for OpenGL as a workaround for broken drivers or as a fallback for older 
> systems.
> I've always used scons on Windows and msvc as a compiler to make these 
> builds, but now that scons is being deprecated I've been trying to use meson 
> and ninja to cross-compile from Linux (amd64) to Windows (both x86 and 
> x86_64) without much success. I can get regular Linux builds without issues 
> though.
>
> I tried reading the Mesa documentation on cross-compiling but it's very 
> minimal and it's partially obsolete so I thought it would be best to ask you 
> directly: how do I make these builds? Explain like I'm 5, basically.
>
> Thanks,
>
> Federico
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=04%7C01%7Cj
> enatali%40microsoft.com%7Cb5f74e617d8f41709c6008d884c52096%7C72f988bf8
> 6f141af91ab2d7cd011db47%7C1%7C1%7C637405330339535954%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000&sdata=Bff7tju87yGZyyCuqmOB%2BFaKPkBphxCEmLNw2X8E%2FFg%3
> D&reserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [EXTERNAL] Cross-compile from Linux to Windows

[Jesse Natalie]

Have you tried using Meson on Windows, instead of cross-compiling? If you run 
it from a Visual Studio command prompt, it should just work out of the box, at 
least for x86. I believe you'll need to use a cross file for amd64, but the 
only thing you'd need to specify is the host architecture.

Though I guess if you're building LLVMPipe you'll need to point it to LLVM. In 
my experience, adding "--cmake-prefix-path" to the Meson command line should 
work well.

-Jesse

-Original Message-
From: mesa-dev  On Behalf Of Federico 
Dossena
Sent: Saturday, November 7, 2020 4:14 AM
To: mesa-dev@lists.freedesktop.org
Subject: [EXTERNAL] [Mesa-dev] Cross-compile from Linux to Windows

I'm sorry to bother you in the dev list but it seems to be the only one with 
activity so it seems like the best place to ask.

I maintain some Mesa builds for Windows. These are builds of libgl-gdi with 
llvmpipe, for both x86 and x86_64; in other words, they're opengl32.dll files 
that users can drop into their game/application to have software rendering for 
OpenGL as a workaround for broken drivers or as a fallback for older systems.
I've always used scons on Windows and msvc as a compiler to make these builds, 
but now that scons is being deprecated I've been trying to use meson and ninja 
to cross-compile from Linux (amd64) to Windows (both x86 and x86_64) without 
much success. I can get regular Linux builds without issues though.

I tried reading the Mesa documentation on cross-compiling but it's very minimal 
and it's partially obsolete so I thought it would be best to ask you directly: 
how do I make these builds? Explain like I'm 5, basically.

Thanks,

Federico

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=04%7C01%7Cjenatali%40microsoft.com%7C7ed90f213a9a4204b25108d8848e0ef1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637405092966689938%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=A%2BvRfw0Y4C4NufTtNWOwo4COLOOJAw%2F3H9rttkk5jA4%3D&reserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev