AMD has announced 'Radeon-Rays' an open source ray tracing SDK using Vulkan

UWP isnt compatible with Vulkan nor any program with opengl above 1.0
that means that vulkan apps cant run on xbox, hololens and whatever else microsoft put on the market.

currently lose the xbox market would do more harm to the pockets of the developers than losing mac/linux.

The XBOX is locked hardware with a restricted set of APIs. You would get better performance on XBOX by using the lowest level APIs rather than UWP.

Windows 10 is a general purpose computer OS, not locked to hardware. Both the CPU and GPU can be accessed through non-Microsoft APIs, even from within UWP programs; Vulkan APIs and drivers are supplied by the hardware manufacturers, not Microsoft.

I would not expect game makers to switch to UPW from XBOX low-level APIs, as it would reduce performance. If they want their game to support UWP on Windows 10, they will probably make the minimum changes necessary to existing DirectX code.

If they want to support additional platforms, they might do so by writing a Vulkan implementation, which could also be made to run on Windows 10 UWP. Whether that is a good idea or not depends on the game.

"Windows 10 is a general purpose computer OS, not locked to hardware. Both the CPU and GPU can be accessed through non-Microsoft APIs, even from within UWP programs; Vulkan APIs and drivers are supplied by the hardware manufacturers, not Microsoft."

i think that UWP is a sub set of apis, sandboxed and with some libraries.

it help to ensure either compatibility (you will not try to acess any hardware feature that is x86 exclusive), security (sandboxed)
subset (it wont support vulkan because it dont allow direct gpu acess to sendo vk commands)
but with some libraries to save developers time/money convincing then to use it and to make some effects without too much cpu/gpu usage.

example, you can use nvidia hair works to make hair, instead of coding it your self, it will save you time/money, at the cost of this single feature only working on nvidia hardware.
and since they know their hardare better than anyone else, they can optimize this feature better than you could if you try to do it by your self.
maybe they even have an asic on their gpu on part of it is only acessible if you use their api, so you cant compete in performance with ther oficial api.

i think that is what ms is trying to do here, but i'm not sure, i didnt read the documentation.

also i dont think xbox has even drivers to run vulkan or will ever have.

"Windows 10 is a general purpose computer OS, not locked to hardware. Both the CPU and GPU can be accessed through non-Microsoft APIs, even from within UWP programs; Vulkan APIs and drivers are supplied by the hardware manufacturers, not Microsoft."

i think that UWP is a sub set of apis, sandboxed and with some libraries.

it help to ensure either compatibility (you will not try to acess any hardware feature that is x86 exclusive), security (sandboxed)
subset (it wont support vulkan because it dont allow direct gpu acess to sendo vk commands)
but with some libraries to save developers time/money convincing then to use it and to make some effects without too much cpu/gpu usage.

example, you can use nvidia hair works to make hair, instead of coding it your self, it will save you time/money, at the cost of this single feature only working on nvidia hardware.
and since they know their hardare better than anyone else, they can optimize this feature better than you could if you try to do it by your self.
maybe they even have an asic on their gpu on part of it is only acessible if you use their api, so you cant compete in performance with ther oficial api.

i think that is what ms is trying to do here, but i'm not sure, i didnt read the documentation.

also i dont think xbox has even drivers to run vulkan or will ever have.

Yes, UWP is a subset - a very large subset - of the existing windows APIs. Most of the dropped APIs are to do with screen presentation in some way. The sandbox is limited in scope; while it does prevent a UWP application from invoking a device IOCTL directly, UWP has the "Device Access API" that a hardware manufacturer can use to provide a UWP application with access to their device.

If a GPU manufacturer wanted to provide a custom graphics API ( like Vulkan ) they would write a UWP device app ( which has special permissions ) and the graphics API would be implemented against this device access app as a static library to be bound into any client UWP app ( UWP apps can't bind libraries dynamically other than the windows libraries ).

What the performance would be like is anyone's guess, probably poor, since the entire idea of UWP is of questionable value to anyone but Microsoft; but it doesn't mean you can provide alternative graphics APIs if you really want to.

XBox, as I mentioned before, is a different case altogether.

If a GPU manufacturer wanted to provide a custom graphics API ( like Vulkan ) they would write a UWP device app ( which has special permissions ) and the graphics API would be implemented against this device access app as a static library to be bound into any client UWP app ( UWP apps can't bind libraries dynamically other than the windows libraries ).

There's no whitelisting or enforced driver signing by Microsoft? I'd be very surprised. UWP is all about control after all. They want to be Apple so hard it hurts.

If a GPU manufacturer wanted to provide a custom graphics API ( like Vulkan ) they would write a UWP device app ( which has special permissions ) and the graphics API would be implemented against this device access app as a static library to be bound into any client UWP app ( UWP apps can't bind libraries dynamically other than the windows libraries ).

There's no whitelisting or enforced driver signing by Microsoft? I'd be very surprised. UWP is all about control after all. They want to be Apple so hard it hurts.

True, they do want control, but if a device manufacturer submits a UWP device app to allow direct hardware use they would risk regulatory scrutiny if they refuse to sign it. Usually they use commercial pressure with big companies.

Best not to use UWP at all. Neither the architecture nor the market seem compelling to me.

Best not to use UWP at all. Neither the architecture nor the market seem compelling to me.

we can avoid UWP all as we want, but how to convince developers to not use it?

Best not to use UWP at all. Neither the architecture nor the market seem compelling to me.

we can avoid UWP all as we want, but how to convince developers to not use it?

Actually, I meant that comment from a developer perspective. The UWP development model is inferior to the Win32/64 model for desktop and laptop computers, where Microsoft are still reasonably strong. The whole point of UWP is to provide an equivalent to the iOS development model for tablets and phones, but that is a market in which Microsoft is almost invisible.

I'm not sure that Microsoft have yet realised that they are no longer important enough to enforce market adoption in all segments. It is quite possible that UWP will go the same way as Silverlight and countless other "innovative" technologies that were introduced more for Microsoft's benefit than for users or developers.

Best not to use UWP at all. Neither the architecture nor the market seem compelling to me.

we can avoid UWP all as we want, but how to convince developers to not use it?

Actually, I meant that comment from a developer perspective. The UWP development model is inferior to the Win32/64 model for desktop and laptop computers, where Microsoft are still reasonably strong. The whole point of UWP is to provide an equivalent to the iOS development model for tablets and phones, but that is a market in which Microsoft is almost invisible.

I'm not sure that Microsoft have yet realised that they are no longer important enough to enforce market adoption in all segments. It is quite possible that UWP will go the same way as Silverlight and countless other "innovative" technologies that were introduced more for Microsoft's benefit than for users or developers.

I certainly hope so. From your lips to the tech gods' ears, old bean.

Best not to use UWP at all. Neither the architecture nor the market seem compelling to me.

we can avoid UWP all as we want, but how to convince developers to not use it?

Actually, I meant that comment from a developer perspective. The UWP development model is inferior to the Win32/64 model for desktop and laptop computers, where Microsoft are still reasonably strong. The whole point of UWP is to provide an equivalent to the iOS development model for tablets and phones, but that is a market in which Microsoft is almost invisible.

UWP also works on xbox

Best not to use UWP at all. Neither the architecture nor the market seem compelling to me.

we can avoid UWP all as we want, but how to convince developers to not use it?

Actually, I meant that comment from a developer perspective. The UWP development model is inferior to the Win32/64 model for desktop and laptop computers, where Microsoft are still reasonably strong. The whole point of UWP is to provide an equivalent to the iOS development model for tablets and phones, but that is a market in which Microsoft is almost invisible.

UWP also works on xbox

That's true. But XBox is a games console, and also has a better development model than UWP for developing games; I am not clear why one would want to develop anything much else for an XBox.

I understand the logic of UWP for Microsoft; they can market a single development environment and pretend it makes development everywhere easier. But I really don't think it does, any more that the Java slogan of "write once, run everywhere" was ever true. The range of devices for which UWP is proposed comprise quite different sets of capabilities; if a UWP app in the Microsoft store runs on all platforms, a developer would feel obliged to write and test additional code to handle them all, even if they make no sense.

I am not suggesting that UWP is of no value to any anyone, or that no developers will find it helpful. There are probably classes of utility applications that can find common ground on multiple Windows 10 platforms, and if you want to link together multiple Microsoft-only web and Windows 10 services, you can probably benefit from UWP.

However, if you are a platform neutral developer, UWP makes sharing code between platforms far more difficult, which may be to Microsoft's benefit, but is certainly not helpful to the developer.


Last edited by etonbears on 29 April 2018 at 8:35 pm UTC