Announcement
Collapse
No announcement yet.
Mesa Vulkan Branch Published For Intel Linux Support
Collapse
X
-
Originally posted by lucas_ View Post
- Likes 1
Comment
-
Originally posted by lucas_ View Post
Anyway, as the mesa post says, the intel team spent more or less two years for their driver development, so it was not so easy to do. Considering the radical change done by AMD for their entire linux stack, it is well explained (at least to me) why there were not ready for the first day.
Comment
-
Originally posted by boffo View Post
So what happened the LunarG driver?
Tools to aid in Vulkan development. Contribute to LunarG/VulkanTools development by creating an account on GitHub.
Maybe the only interesting thing about it anymore is
This directory provides support for the Intel Haswell, Ivy Bridge and Sandy Bridge GPUs
and intel's driver says The driver currently supports Sky Lake all the way back to Ivy Bridge.
- Likes 1
Comment
-
Originally posted by Pecisk View Post
It was used as prototype/test bed for ideas to be fleshed out. That was it's goal. LunarG also used it to develop SDK, while this driver got rewritten from scratch under Intel supervision.
clueless question here. is this of any use to other vendor OSS drivers? i can figure they would need to replace SPIR-V->NIR with SPIR-V->something_else, but what about the rest?
still, 36k is amazingly small.
Comment
-
Oh yay, more non-OpenGL crap forced under the "OpenGL library" codebase/release schedule. Tell me again why we limit entire drivers to the release schedule of just the OpenGL library part of it? We could just as easily code-share without doing it that way, so that's not the reason.
Comment
-
Originally posted by lucas_ View Post
intel is working with red hat and ubuntu devs and since mir vulkan is not ready yet who cares? only morons like you
Comment
-
Originally posted by justmy2cents View Post
clueless question here. is this of any use to other vendor OSS drivers? i can figure they would need to replace SPIR-V->NIR with SPIR-V->something_else, but what about the rest?
still, 36k is amazingly small.
Originally posted by Daktyl198 View PostOh yay, more non-OpenGL crap forced under the "OpenGL library" codebase/release schedule. Tell me again why we limit entire drivers to the release schedule of just the OpenGL library part of it? We could just as easily code-share without doing it that way, so that's not the reason.
- Likes 1
Comment
-
Originally posted by zanny View PostAnd then you hear about how open the standard is and how cross platform it is going to be. Linux on the Nvidia and Intel side are looking to be just as good / bad as the Windows side, but then AMD drops the ball with no driver, and only promises a GCN 1.1+ driver... eventually.
- Likes 2
Comment
-
Originally posted by agd5f View Post
How did AMD "drop the ball"? No one from AMD said there would be Linux support on launch day nor that it would be GCN 1.1+ only. Moreover, there are very few vk apps available today so it's not like there are a tons of apps just waiting for drivers, plus it's hard to write drivers without applications to test. In general all of the GPU vendors work pretty closely with the application ISVs so lack of a public driver on launch day for specific platform/hw combinations is not exactly the end of the world. Next, there are hw limitations on pre-GCN hw that make vk support sub-optimal. Obviously it could be done, but it doesn't provide much of an advantage over current APIs. Even if all the hw vendors produced drivers for all platforms for all hw that could potentially support vk on day one, it wouldn't magically make tons of vk apps appear instantly. There are still a lot of DX10/GL3 cards out there. Why do lots of ISVs target target GL4/DX11? By your logic, all apps should still target GL3/DX10 or even GL2/DX9. Finally, windows is still where most of the market is at least in the short term, so that's obviously where most of the focus is.
- Likes 1
Comment
Comment