
Vulkan in Open Source [pdf] - 1ace
https://fosdem.org/2016/schedule/event/vulkan_graphics/attachments/slides/1007/export/events/attachments/vulkan_graphics/slides/1007/vulkan_fosdem_2016.pdf
======
pjmlp
More Vulkan slides how everything is going to be great without real
content[0], whereas Metal and DX 12 are already here.

Not only as drivers, but also documents, books, tools and graphical debuggers.

I hope this doesn't turn out into another Longs Peak.

[0] Yes, I know it is Mantle inspired and I have those PDFs.

~~~
ginko
Proprietary APIs can't be a replacement to an open industry standard.

~~~
angersock
I'm pretty sure that DirectX is a living, breathing counterexample to that
claim.

~~~
shmerl
And how exactly can you use it on Linux or any other non MS system? It's an
example of the disgusting practice of using development tools for lock-in.

~~~
ntakasaki
Or it can be a very nice object based API instead of a state based API that
made sense in 1992 as the slide deck said and certainly didn't make any sense
in 2008 when the industry group Khronos sided with the commercial CAD industry
to screw over Linux consumer gaming because there was no money in it. How was
that DirectX's fault again?

I am guess you're not a game developer and your post is yet another case of
[1].

I am a game dev and here are some links that show to non game devs why DirectX
is more popular:

[http://programmers.stackexchange.com/questions/60544/why-
do-...](http://programmers.stackexchange.com/questions/60544/why-do-game-
developers-prefer-windows/88055#88055)

[https://news.ycombinator.com/item?id=2711231](https://news.ycombinator.com/item?id=2711231)

[http://www.tomshardware.com/reviews/opengl-
directx,2019.html](http://www.tomshardware.com/reviews/opengl-
directx,2019.html)

[1] [http://arstechnica.com/information-
technology/2009/07/linus-...](http://arstechnica.com/information-
technology/2009/07/linus-torvalds-microsoft-hatred-is-a-disease/)

~~~
shmerl
_> Or it can be a very nice object based API instead of a state based API_

That's exactly what Vulkan is. So where is MS voicing their support?

 _> I am a game dev_

So did you ask MS why they didn't join Vulkan working group?

And I'm not sure what was your point in those links about OpenGL. We are
talking about Vulkan.

~~~
ntakasaki
Perhaps because design by a committee of peers usually results in a
fragmentation and compatibility nightmare like this:

Edit: The below blog redirects HN referrers to a funny image macro, copy paste
the link instead.

[https://www.jwz.org/blog/2012/06/i-have-ported-
xscreensaver-...](https://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-
to-the-iphone/)

The delayed spec hasn't even been released yet and Nvidia is already making
Vulkan extensions on its own.

[https://developer.nvidia.com/engaging-voyage-
vulkan](https://developer.nvidia.com/engaging-voyage-vulkan)

~~~
shmerl
_> Perhaps because design by a committee of peers usually results in a
fragmentation and compatibility nightmare like this_

It can. Or it can result in spec which helps everyone instead of just MS
alone. Depends on how it's done. Vulkan is done from scratch, and so far I see
no signs of them making mistakes of OpenGL. I guess we'll see more once it's
released. Either way, what's the alternative? There is none, unless of course
you work for MS and envision them controlling everything.

~~~
ntakasaki
>Or it can result in spec which helps everyone instead of just MS alone.

Just MS alone? DirectX helps hundreds of millions of gamers, a whole bunch of
game and application developers and companies.

That's like saying improvements to the Linux kernel help only the Linux
kernel.

>Vulkan is done from scratch, and so far I see no signs of them making
mistakes of OpenGL

Huh, how do you see that? The spec is developed behind closed doors by
corporate folks each with their own interests. Even the W3C holds open
discussions with specs.

A real alternative would be for the FOSS/Linux dev community to create and
implement a standard properly.

~~~
shmerl
_> Just MS alone?_

Yes. How can you use DirectX on non MS platforms? If MS wanted to help someone
besides themselves, you could answer that question in a satisfactory fashion.
But of course, they don't care about it, they only care about lock-in. Trying
to pretend that lock-in serves anyone besides those who push for such lock-in
is highly disingenuous.

 _> Huh, how do you see that?_

From what was published about it so far (origin in Mantle, collaborative input
of those who know better and so on).

 _> A real alternative would be for the FOSS/Linux dev community to create and
implement a standard properly._

Linux community was involved. In fact the main link in this post is from one
of the contributors to Wayland and Mesa who was working on Vulkan.

~~~
angersock
Other folks are beating about the bush, so I'll just come out and say it:

 _Linux is basically irrelevant to game developers_.

Other folks have been nice, but let's just be clear here. Linux's graphics
story is a stupid joke, the driver story is a stupid joke, the 3D story by way
of OpenGL is a stupid joke, audio is a stupid joke.

 _That 's_ why it _doesn 't matter_ if you can only use DirectCX on MS
platforms--because by reaching only that teensy tiny _vast majority_ of
installed computers, devs can do well.

MS has _always_ treated their developers better than anything in the 'nix or
BSD ecosystem, and that extends to better thought-out and implemented APIs.

Sorry, but that's the world we live in, and in reality there is little point
in MS worrying about a non-DX API--and little point in supporting one if
you're making games for PC.

~~~
shmerl
_> Linux is basically irrelevant to game developers._

Sounds like a quote form early 2000s. We are long since past that. If you
didn't pay attention to the last few years - then may be research what's going
on now.

 _> That's why it doesn't matter if you can only use DirectCX on MS platforms_

It does matter. Lock-in forces developers to do double work. I.e. if they
can't reuse the effort - they need to duplicate it. To put it differently - MS
on purpose increases the cost of making cross platform games. Obviously for
the reason of putting competing platforms at a disadvantage. How can any
developer find such behavior beneficial is hard to understand. All normal
developers have no respect for lock-in.

 _> MS has always treated their developers better than anything_

Oh, really? Forcing people to do double work is not called treating you
better. It's called being a jerk. And jerks they are, same as anyone who uses
tools for lock-in purposes (instead of for what they should be - tools).

~~~
pjmlp
So to be clear, you are calling all the game industry studios that specialize
in platforms, porting and tooling, a practice that goes all the way back to
the industry roots, jerks.

~~~
shmerl
_> you are calling all the game industry studios that specialize in platforms,
porting and tooling, a practice that goes all the way back to the industry
roots, jerks._

How exactly did you read that into my words? I said those who force people to
do double work are jerks. I.e. those who create and enforce lock-in (MS and
their ilk). Why would developers who have no option but to do that double work
be jerks? It wasn't their decision and they have no control over those who
create those walled gardens and lock-in.

Practice of lock-in doesn't go to "industry roots". It goes to those jerks who
don't care about the industry and want to make life harder for developers by
making tooling useless outside given walled gardens. Their selfish and stupid
idea is based on assumption that the harder and more costly it is for anyone
to do the work (because of duplication), the less likely they'll do it, thus
sticking only to the walled garden they initially focused on. I.e. their usual
exclusivity idea. Remember browser lock-in? Same idea here. It has nothing to
do with the industry - it's all about jerkiness of those who make the tools
and control the market.

------
bsder
At this point, my advice to the Vulkan folks is:

Ship it, or shut up.

I don't need another slide deck promising the universe. I need an API that I
can build on even if it's primitive.

And, if it's too primitive to build on, my advice would change to:

Shut up and code.

~~~
ntakasaki
Also, Vulkan is going to support extensions like OpenGL did which fragmented
the hell out of OpenGL.

Nvidia is already beginning the lock in and fragmentation process by making
Vulkan extensions.

[https://developer.nvidia.com/engaging-voyage-
vulkan](https://developer.nvidia.com/engaging-voyage-vulkan)

>NVIDIA will therefore provide a few Vulkan extensions from day zero, so that
you as developer can enjoy less obstacles on your path to Vulkan. We will
support consuming GLSL shader strings directly next to Vulkan's mandatory
SPIR-V input

~~~
gnarbarian
Nefarious intent aside. This will make it much easier to port large projects
over piece by piece so its not an all or nothing proposal that requires a
complete rewrite from day 1.

------
dman
The lack of information about Vulkan is a bit concerning. For something that
is about to be announced anyday now there is very little concrete information
available about basic details like - what hardware that is currently shipping
will support vulkan and how long after announcement will vendors have drivers
out (weeks/months/years?).

~~~
anon4
Drivers will be available on release day and all currently sold hardware will
support it.

~~~
dman
Thanks - is reading the Mantle docs a good way to hit the ground running with
Vulkan or have things diverged significantly?

------
fitzwatermellow
Expecting to hear more Vulkan details from Khronos at the Game Developer's
Conference 2016 in March:

[https://www.khronos.org/news/events/gdc-2016-khronos-
session...](https://www.khronos.org/news/events/gdc-2016-khronos-sessions)

------
tormeh
Newest thing I've heard is that there will be games using Vulkan at launch.
So, the specification, the drivers and some game ports will all go public the
same day. Anything might be holding it up (most likely the ports), but GDC in
March seems like a reasonable deadline considering the amount of talks about
Vulkan.

------
monocasa
I really think one of the important aspects is that it should be much easier
to reverse engineer proprietary drivers now given how explicit the API is
supposed to be.

------
shmerl
I hope Vulkan will catch up. And MS deserves strong disrespect for not joining
the effort which can move the industry forward.

------
dang
Url changed from
[https://fosdem.org/2016/schedule/event/vulkan_graphics/](https://fosdem.org/2016/schedule/event/vulkan_graphics/),
which points to this.

------
stonogo
More garbage from the same trash factory. Get back to me when you have an API
that doesn't incentivize drivers to behave differently based on the name of
the video game engine.

~~~
kleiba
While some might find your wording a bit strong, I was also surprised by the
lack of content in that slide deck.

~~~
creshal
Vulkan was originally supposed to start shipping in Q4 2015, and there's still
not more publicly available than 12 months ago.

The frustration is a bit understandable.

~~~
joeld42
Its a free and open API developed in secret by committee. What could go wrong?

Still, it will be an improvement over openGL.

~~~
zanny
Seriously Khronos, take a fucking page out of C++. They went two decades with
awful broken language syntax until sometime between 2004 and 2008 they got
together and decided to fix it.

Today, [https://isocpp.org/](https://isocpp.org/) is a gold mine of how to do
an open standard correctly. Everything is public, future features are
discussed with the community, and all the working groups are on github. _That_
is how you take a legacy standardization body and modernize it for the open
source world, not make presentations at every event for over a year going "Hey
guys its gonna be great! Just wait until you see it! Ooooonnnnnneeeee day! We
just _know_ you'll love it!"

