Mesa Vulkan Branch Published For Intel Linux Support

[bridgman]

You stated that the Vulkan driver was written from scratch and that the code would have been released sooner or later: it means that you are developing an open driver behind the curtains.

I don't remember saying that the driver was written from scratch - can you check that ? The Vulkan driver draws from a lot of existing closed source code but over time we plan to turn it into an open driver.

[timofonic]

I'm sure many of my questions aren't going to be replied, some of the methods are going to be a variable combination of:


- Derivation "ask our lawyers" lame excuse.

- Derivation of the IP excuse.

- Circular argumentation or any other non substance replies.

- Ignoring this and let it die.

- Logical fallacies.



I have nothing to lose:


- I'm not a developer.

- I'm just a poor and crazy Linux user.

- I'm not afraid of losing contracts or job opportunities, I'm not interesting for all the big corps.

- I have zero incomes and struggling with very serious personal issues, so I don't care at all about this in comparison and just look at this because being an obsessed computer hobbyist.

I don't remember saying that the driver was written from scratch - can you check that ? The Vulkan driver draws from a lot of existing closed source code but over time we plan to turn it into an open driver.

Huh ? Other than initial IP review for the header files, we are developing the FOSS driver in public open repos. What we're talking about here is the hybrid driver, where all the new bits are closed source.

I'm assuming your question is not "why do you fear developing the closed source driver in a public open repo ?"

I would love to know it in certain way, but by asking it in a different way by the following questions:

- Why do AMD, Intel, Nvidia, Imagination Technology, Qualcomm and others fear developing their drivers in fully FOSS way and using a public open repo?

- Why there's need to use binary blobs? What do they have to hide? Don't they want to make Vulkan a revolution and become OPEN?

- Why there is need to make "hybrid" and "closed" drivers? Why not making an Open Source driver for all platforms and adopt Gallium3D or an evolved version of it if required?

- Do you all the big ones have something to hide?

- Are you all the involved parties involved in Vulkan interested on making it to succeed? Aren't there secret reasons to be on the Microsoft oligopoly side to make it always to WIN?

Actually, the driver we shipped was written from scratch - it doesn't use any of the LunarG prototype code. You're right that it's only for Linux, though. Having a small focused team that had the freedom to design the best driver they thought possible, without worrying about other OSes or APIs definitely sped up the efforts.

That said...AMD deserves our thanks. They had a huge hand in making Vulkan happen (and that's understating it!). Vulkan gives free software systems an answer to DirectX 12 and similar proprietary systems, which is a huge gift. I definitely wish them the best with their efforts.

Sorry, but I really see Vulkan has the same problem of OpenGL and DirectX: Both are developed by a closed group. Despite one is in theory bigger than other, the reality is that hardware manufacturers are part of the DirectX umbrella too.

How can an API developed in a closed source way over a consortium (a walled garden, after all) be real answer to DirectX 12+?

- The development was unknown until AMD donated their Mantle API: No real development happened before, lots of time got wasted in bureaucracy.
- What about Open Source project? There wasn't involvement on the design of the API by FOSS projects.
- If Vulkan aims to be an OPEN API: Why the development isn't managed by a non-profit foundation? What about making a faster development pace with faster releases? What about making it even an ISO standard in the way of OpenDocument?
- Why there's need to follow the toxic Intellectual Property policies and why not make ALL DRIVERS as Open Source from day 0? Those only favor the biggest corporations and make the market dominated by oligopolies. Oh wait...


To me, Vulkan seems to chage nothing. Here's my ideas, please provide a really solid counter-argumentation t that if some of you can.

- Another corporate marketing effort to give a fake feeling of competition.
- No real change: The future will be dominated by console makers and Microsoft still controlling both the market and consumer GPU evolution. Microsoft is still going to be the real overlord of 3D graphics.
- Maybe Facebook with Occulus will do a bit of countermeasure if their future platform succeeds, but they need a really flexible replacement to gamepads with realistic feedback to make VR something usable.

Does the mesa code already work for Android?

That's very interesting and a question quite forgotten to reply. Google, Imagination Technologies, NVIDIA and others would hate to be forced to reply it in a really sincere way

[haagch]

Back to the intel vulkan driver.
Some gen7 commits:
https://cgit.freedesktop.org/mesa/me...1fecdf5c1c0452
https://cgit.freedesktop.org/mesa/me...697b5b0152fe29
https://cgit.freedesktop.org/mesa/me...8c156a2bcf920a
Finally some (public) life sign for work on older intel gpus!

The driver is still broken for gen7, but one change I noticed is that LunarG's tri and cube examples don't hang the GPU anymore
Probably because one comments in one of the commit says: + /* Even if no fragments are ever dispatched, the hardware hangs if we
+ * don't at least set the maximum number of threads.
+ */

Instead this happens:

$ ./cube
Cannot find a compatible Vulkan installable client driver (ICD).

Please look at the Getting Started guide for additional information.

[bridgman]

...I would love to know it in certain way, but by asking it in a different way by the following questions:

- Why do AMD, Intel, Nvidia, Imagination Technology, Qualcomm and others fear developing their drivers in fully FOSS way and using a public open repo?

We are developing most of the stack in a fully FOSS way and using a public open repo today. There are two main exceptions:

Where possible, we write code for new chips in parallel with hardware development, so driver work might start long before HW launch. In that case we keep the code internal until we get fairly close to launch date.

Some new drivers (eg Vulkan) are developed using big chunks of code from existing closed-source drivers. That sort of propagates the closed-sourcedness for a while but it also allows us to develop drivers more quickly than we could otherwise.

- Why there's need to use binary blobs? What do they have to hide? Don't they want to make Vulkan a revolution and become OPEN?

In general the binary blobs are hiding internal details of other OSes (ie not Linux), which are there because code is shared across multiple OSes. When drivers are written for Linux only they can generally be open from day one.

Other reasons include keeping features specific to high end products limited to only those products, eg workstation vs gaming SKUs.

- Why there is need to make "hybrid" and "closed" drivers? Why not making an Open Source driver for all platforms and adopt Gallium3D or an evolved version of it if required?

Mostly answered above - if we are sharing code across multiple OSes the resulting drivers tend to have to stay closed, since we don't have rights to expose internal details of those other OSes. The "hybrid" stack includes some code-shared-across-OSes drivers, while the "open" stack contains only Linux-specific drivers which can be fully open.

- Do you all the big ones have something to hide?

Absolutely. As an example, our DX12 drivers include alien technology from a spaceship that crashed in New Mexico

- Are you all the involved parties involved in Vulkan interested on making it to succeed? Aren't there secret reasons to be on the Microsoft oligopoly side to make it always to WIN?

As far as I know we are all working hard to make Vulkan succeed, but part of that involves making good drivers available on more than just Linux. That leads to code sharing across OSes (some open, some proprietary) which for reasons described above leads to the drivers being closed source at least at the start.

[bridgman]

timofonic, I replied in some detail but the response got caught up in the auto-moderation queue. That excuse was not in your list.

BTW you asked why FOSS project developers were not included in the creation of the Vulkan API. As far as I know there are mesa developers involved with Khronos, both indirectly through companies and directly.

[haagch]

Ooh, I just tried compiling SaschaWillem's examples again and only the shadowmapping example needs to be removed from CMakeLists.txt line 86 because it doesn't work, then it compiles, so the build system was definitely improved.

All the examples actually run on Ivy Bridge now.
The tessellation shader examples basically show an empty window, kinda expected when tessellation is not supported yet.

Mostly textures are not working correctly. Here is what anvil renders:


The funny thing is, here is what LunarG's ilo driver renders (Yes, it can be compiled and actually works):


So even though LunarG's driver is for an early version of the specification and not Vulkan 1.0 compliant, currently it can do a bit more than anvil when it comes to rendering simple stuff correctly in Ivy Bridge. (Edit: Except of course most of these examples don't actually run on LunarG's driver. Examples fail in various ways, mostly "Assertion `formatProperties.optimalTilingFeatures & VK_FORMAT_FEATURE_BLIT_DST_BIT' failed.", but also "***Unsupported functionality: storage class" and "error: insufficient contiguous locations available for vertex shader input `inUV' -65536 0 8".

But to be fair, running stuff with anvil, it always prints "WARNING: Ivy Bridge Vulkan support is incomplete"
Then there's a lot of stuff like
gen7_pipeline.c:235: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREAT E_INFO
anv_meta_blit.c:809: FINISHME: respect VkFilter
And sometimes there's stuff like
WARNING: Unsupported SPIR-V Capability
So, obviously unfinished, but still, partly working already.

[Kano]

@bridgman

You know that Intel publishes code before product lauch? You can find Broxton and Kaby Lake in kernel, mesa, vaapi...

[bridgman]

You know that Intel publishes code before product lauch? You can find Broxton and Kaby Lake in kernel, mesa, vaapi...

Yep, we do the same for our APUs as well. Kaveri gfx driver code was out ~6 months before launch... Carrizo was closer to launch but that was because of the radeon/amdgpu transition not because of policy.

With dGPUs the code stays internal until we get fairly close to launch at the moment but I think we have a solution for that now.