Direct3D and Visual Studio deprecation

[Nicolas Capens]

Hi all,

We've been focusing on SwiftShader's Vulkan implementation for a while now. It passes Khronos' Vulkan 1.1 conformance tests, and with ANGLE's OpenGL ES to Vulkan translation we're close to OpenGL ES 3.1 certification. Because it offers more features and better conformance than our legacy OpenGL ES 3.0 implementation, we're in the process of transitioning the SwiftShader project itself to become Vulkan-only.

As part of that, legacy Direct3D 8/9 support will also be removed from the master branch. You can still build it from the legacy-d3d9 branch though. If and when Direct3D 9/10/11 support is needed, we can look into integrating the dxvk translation layer.

We'll also be removing the custom Visual Studio solution, in favor of CMake files. Note the latter can be used to generate a Visual Studio solution, or it can be loaded directly by Visual Studio 2019.

In conclusion, nothing will be lost forever, and I hope you're as excited about our new direction as we are! Please continue to file bugs and feature requests at https://g.co/swiftshaderbugs

Cheers,

Nicolas Capens - SwiftShader lead

[Dane Springmeyer]

Hi Nicolas,

Thanks for the details on the future of Swiftshader. The vulcan work is exciting and I hope that the application I use swiftshader with will eventually support vulcan. But for now I'm depending on swiftshader's OpenGL EGL and GLESv2 interfaces.

In other words, I build with `-DSWIFTSHADER_BUILD_EGL=YES -DSWIFTSHADER_BUILD_GLESv2=YES`.

In the move toward vulkan only, will those interfaces remain or will they be removed? If they will be removed, do you have a sense of when?

Thanks,

Dane

--
You received this message because you are subscribed to the Google Groups "swiftshader" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swiftshader...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/swiftshader/CAK2XvFm3p4nBQpi99rcBD8%3DVUgS7nkmdWQB0Ti62oRUWjGNpdg%40mail.gmail.com.

--

 

Dane Springmeyer Engineering Manager, Core Tech +1 360 298 1580  l mapbox.com

[Nicolas Capens]

Hi Dane,

The GLESv2/EGL code will be removed from the main branch, but just like for the removal of Direct3D 9/8 support, we'll create a branch which will still contain that code.

We're currently in the process of ensuring that ANGLE + the Vulkan implementation can replace the legacy GLES implementation, both in terms of conformance and performance. That will likely take a few more months, but even once we're fully confident in it, we'll roll it out to our internal clients (mainly Chrome) very cautiously. So we'll keep the legacy GLES code readily available in case we have to revert back to it, probably for a couple of Chrome release cycles.

We can create the branch much sooner than that, so people can switch to that and not have any interruption when we remove things from the master branch.

Cheers,

Nicolas

To view this discussion on the web visit https://groups.google.com/d/msgid/swiftshader/CAHvVg0-Oy-5Kt59txcE96YV-3uySMme8i72O1qWKC8o6A1c%2BbQ%40mail.gmail.com.

[Dane Springmeyer]

Thanks for the extra detail Nicolas. If we have patches or improvements to the legacy GLES implementation in the next 3-6 months, would you be able to review and potentially apply to the legacy-d3d9 branch? It's okay if you don't have a maintenance plan for the branch, but curious if you have thoughts. One thing we are working on currently is trying to track down the source, in swiftshader, for some non-deterministic pixel shifting happening with the placement of textures. If we can find a fix for it, then it would be ideal to have you all review and apply to the legacy-d3d9 branch.

Dane

To view this discussion on the web visit https://groups.google.com/d/msgid/swiftshader/CAK2XvFk7CjNN54AEOEMLpVc-txy8xzZOw%3DXPyhKXbaKHNS2uTA%40mail.gmail.com.

[Nicolas Capens]

Yes, to avoid various forks of the legacy GLES implementation having their own local patches, I think it makes sense to review and accept patches on this branch, as long as it doesn't become a significant burden. We do want people to switch to ANGLE + SwiftShader Vulkan (aka "SwANGLE") at their earliest convenience. We hope to make that solution a little easier to build once its integration into Chrome is complete.

Regarding the non-deterministic sampling, I believe we fixed that issue on the Vulkan side several months ago. It was caused by using vector registers with 16-bit components to store 8-bit color components in the upper part, but the lower 8-bit was left uninitialized. When used in filtering, the lower part affects rounding when we extract the upper part again. Anyway, in short, moving most of the code from src/Pipeline/SamplerCore.cpp to src/Shader/SamplerCore.cpp is likely to address it.