Originally posted by airlied
View Post
Announcement
Collapse
No announcement yet.
Microsoft Announces Direct3D 12 For Linux / WSL2
Collapse
X
-
Originally posted by wagaf View PostHowever I guess it's a blessing for Wine/Linux gaming.Originally posted by L_A_G View PostWho in their right mind would write a DX12 front end for a Linux application, causing it to be stuck in WSL, or move an application with a DX12 front end onto Linux without re-writing that front end and cursing it to the same fate?
Then again this is probably just there to make it easier to port Linux applications onto Windows as more of a step-by-step process rather than all in one big go. Alternatively it's also going to make it easier to port Windows applications with DX12 front ends onto Linux as a more step-by-step process.Originally posted by bezirg View PostSo what is there to benefit for us the (native) Linux users? Can we use this library to develop native-linux d3d apps? Or is this only going to work for wsl2-linux-in-vm users ?
I don't see how it'd be beneficial to Wine/Linux gaming, since you'd be running Windows as the host OS anyway, there's little point to run games via WSL, but perhaps it might be useful to wine or similar devs.
It also appears to be for better supporting CUDA projects that are better supported via Linux then Windows or macOS, often the case with Docker containers and machine learning iirc, nvidia has docker containers that can access the host GPU for CUDA accel offloading, but I believe it's only decent on Linux, there were limitations or other problems(at least for quite some time, haven't kept up to date) attempting to do such on Windows and even macOS. You can do the development locally on the OS without containers, but that can be painful to setup depending on the project, especially when you want to use third-party projects or are starting out, containers make that a much nicer experience.
That should also allow for more adoption of Windows instances in Azure over Linux presumably. They offer linux instances with Azure, but I assume they survey users for why they choose linux over windows instances on the Azure service and seek to minimize those reasons as much as possible.
Originally posted by Terrablit View PostI'm more interested on whether this could be used for virtualization purposes, like if we could use this as a target for stuff like Virgil to get free D3D support in VMs.
Probably a lot of thankless reversing. As long as we can expose Vulkan functionality to VM guests, the rest will be relatively simple.
The lib exposes the API on linux, but is otherwise not likely offering anything else of benefit that the dll wouldn't on Windows? I thought most of the work was more to do with the calls to graphic drivers / translation, but this would just be sort of like virgl wouldn't it? Just forwarding DX12 API calls to the Windows GPU drivers DX12 API to handle.
There is an effort/plan to have a vulkan equivalent of virgl in future afaik, then if you need DX#, can probably use the existing efforts to map that to vulkan?
Originally posted by Scellow View Postpeople move to linux because:
- win10 is giant slow and bloated piece of crap
- win10 is a spyware
- NTFS is slow
Linux has some really nice filesystems that I'd rather use for such, but the ownership thing causes frustration, even on the same system when dealing with docker/VMs that don't share the same UID/GID (in docker containers you often use third-party ones and don't really want to modify each time, VMs if using a certain fs bridge can work around it and no longer as bad as it once was with KVM via virtio-fs afaik?).
I wouldn't mind using Win10 sometimes, it does seem to be getting to a point that it may provide an acceptable or even better experience(for running certain software at least). Although it's definitely slow still. Ran pretty poorly on a 2019Q3 released budget laptop (Comet Lake i3 2/4 cores/threads, 4GB RAM, 128GB NVMe SSD), CPU was often at 50% from some MS background optimization processes for .NET running, fans came on more often even with low power / battery life focused power options. I think around 2GB RAM was used up as well without doing anything on fresh boot.
​​​​​​​Originally posted by Scellow View PostThey all moved to macOS because APIs are nicer, they got a better statically AOT compiled language (Swift), there is a real App Store, and everything is butter smooth and efficient
macOS wasn't enjoyable to use for me, it looked pretty and did well for casual user stuff, but got in the way for any power user activity when I wanted to stray from the default experience you were expected to be content with. Asking community how to do things often resulted in they didn't know or I could solve it by paying money for functionality that were either free or even provided by default on Windows or Linux.
macOS isn't that nice API wise if you want to use Vulkan or OpenGL/OpenCL, the latter two are deprecated and vulkan isn't supported unless you use third-party lib. They have some grudge with nvidia which means tough shit if you want to stay up to date and use CUDA for any real GPU compute work, and that's what some proprietary software relies on. Bigger companies like Adobe adopt to Metal APIs to retain their marketshare on the platform, but I doubt they'd bother if they had any other option. The history macOS has with such behaviour is a red flag for why you'd want to adopt/trust Apple, unless you like supporting their vendor lock-in APIs supporting the platform exclusively or enduring the added cost for maintaining a platform specific API in addition to whatever else you support for other platforms. That may contradict with my statement about CUDA, but if you do any GPU compute work, it's still fairly dominant making it difficult to use alternatives unless you're writing the software entirely.
macOS is butter smooth with animations, but I've experienced times where it goes to shit becoming a snail (10 sec+ delays for mouse/keyboard input response), bouncing icons on the dock or spinning beachball busy cursor remained butter smooth 60FPS during that, but it took well over 10 minutes to restore the system and save my work. I've generally not had a positive experience with macOS.
​​​​​​​Originally posted by Scellow View PostSame for linux, everything there is smooth
Comment
-
Just going through that linked mailing list, here's a quote of Dave Airlie for you EEE folk to sink your teeth into :P
I also have another concern from a legal standpoint I'd rather not review the ioctl part of this. I'd probably request under DRI developers abstain as well.
This is a Windows kernel API being smashed into a Linux driver. I don't want to be tainted by knowledge of an API that I've no idea of the legal status of derived works. (it this all covered patent wise under OIN?)
I don't want to ever be accused of designing a Linux kernel API with illgotten D3DKMT knowledge, I feel tainting myself with knowledge of a properietary API might cause derived work issues.
- Likes 2
Comment
-
Originally posted by M1kkko View PostEmbrace - Extend - Extinquish
Are we now at part 2?
- Likes 1
Comment
-
Originally posted by pracedru View PostThere is also the possibility that this will be:
Embrace
Extend
Consume
MS could be moving Windows from NT Kernel to Linux Kernel.
There certainly would be a lot of money to be saved for having to maintain the nt kernel.
Comment
-
Originally posted by tildearrow View Post
Gallium-TwelveWith this we avoid remapping the outputs of the fixed function shaders and averts the assert in output mapping. Move the lowering passes from finalize_nir to compile_nir like suggested by...
it might be nearer than I thought
Comment
-
Originally posted by TemplarGR View PostThere is no fear. Microsoft does NOT OWN the Linux kernel. But they can use it with their walled garden userland if they so choose. There is nothing wrong with that. As long as they contribute back to the kernel, i see no reason for people to be upset. It is not like Windows 10 is opensource...
Anything not Microsoft is either a threat to Microsoft or a new Market to conquer for Microsoft, they will try to get rid of Linux via first making a compatibility layer, then ensuring that Linux software works better with MS' compatibility layer than Linux, then they will find a way to make the software requiring the Linux layer dependent on functionality available on the Windows side but Linux in appearance.
Microsoft can't be trusted, they're like the proverbial scorpion.
- Likes 4
Comment
-
Comment