Jump to content

Talk:Vulkan/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Naming

Sometimes there is a lot of none-sense written on Wikipedia. "Vulkan" is not a German word. It is a Latin word which is pronounced "V-U-L-K-A-N" in many languages not just German. Until there is an official claim by Khronos that they've specifically named VULKAN in German then any such claims are baseless and misleading myth-making. So my advice is to remove this none-sense.

That the letters "Vulkan" represent the German word for "volcano" is indisputable; you can reference any German dictionary on this subject (or, as has been done here, the German Wikipedia entry on the matter). That this word might descend from a Latin one is irrelevant to that fact. The only question in dispute is whether Khronos named Vulkan-the-API from Vulkan-the-German-word or from somewhere else.
Wikipedia goes by what is verifiable, not what is or is not "none-sense" (nonsense is a real English word, FYI). Thus, what matters is whether there is a reliable source that the API is named for Vulkan-the-German-word? There is a source there, but it is of indeterminate reliability without any information on who these people are. But you have yet to produce a reliable source that stands in contradiction to that, or to prove that this source is not reliable. Korval (talk) 19:40, 12 March 2015 (UTC)
Does someone here perchance know someone high-enough up in the Khronos group to ask them whether they named the API after the German word (and ask them to write an "official blog post" about it)? Or is that likely to be a state secret, like why O'Reilly Media puts certain animals on their book covers? Jimw338 (talk) 08:44, 24 August 2015 (UTC)

Mantle

"The foundation of the Vulkan API is powered by components of the older Mantle API from AMD"
I'm not sure whether "powered by" is a good description in case of an API. Maybe more like:
"The specification of the Vulkan API is nearly identical to the older Mantle API from AMD"?

  • I think saying it's identical is a bit too far in the other direction. Vulkan is built on top of components from mantle, not just inspired by them. Wikinium (talk) 23:48, 4 March 2015 (UTC)
  • I'm not sure of the specific relevance of this tweet in relation to Vulkan's name. Oh, it certainly fits the theory, but my question is who these people are? Is this original research, or are these actual Vulkan staff members talking about how they came up with the name? Korval (talk) 02:45, 12 March 2015 (UTC)

OpenGL

"Vulkan differentiates itself from OpenGL by targeting high-performance realtime 3D graphics applications such as games and interactive media."

This was the overarching goal of OpenGL as well. This seems to be a copy-paste of some press release language, or perhaps a misunderstanding of what OpenGL is compared to Vulkan. The new API is designed to remove some of the performance limitations of older hardware, such as the cost of binding a new shader or texture, or communication between the CPU and a dedicated GPU. — Preceding unsigned comment added by 76.105.187.201 (talk) 23:46, 5 March 2015 (UTC)

It should be noted that Vulkan is not about removing limitations "of older hardware"; it's about performance limitations imposed by the API. Korval (talk) 13:29, 6 April 2015 (UTC)

Use of word Explicit

The word 'explicit' is used several times in the article, seemingly in a technical sense related to APIs. Is this worth explaining briefly in the article, or re-wording to make the usage clear? 121.45.49.170 (talk) 09:40, 6 April 2015 (UTC)

Well, I have no idea what "explicit" means with regard to an API. The wording used to be "low-level", which was accurate. User:Magwen apparently did not agree, saying that "some concepts could be considered higher level". Personally, I don't buy that one bit. Which "concepts"? Using Mantle as a guide, I can't think of a single thing in Mantle that's higher level than OpenGL. And Vulkan isn't operating at a much higher level than Mantle.
However, Wikipedia doesn't work on personal feelings; it works on verifiability. And this much is certain: Vulkan being an "explicit API" is not mentioned in any of the references. So until a source emerges claiming that it is an "explicit API", I'd say to remove it. Korval (talk) 13:20, 6 April 2015 (UTC)

AMD as author

An IP-based user has removed the citation of AMD as one of the authors of Vulkan. This was done in contradiction to the reliable source referenced to justify its presence.

I have therefore reverted this change. Since this is not the first time that the question of AMD's authorship of Vulkan has been removed, I figure we ought to have a discussion about it.

It's a verifiable fact that AMD's Mantle was the starting point for Vulkan. Is that sufficient to have AMD named as an "author" for Vulkan? Korval (talk) 14:20, 22 April 2015 (UTC)

The source says:

"It’s not clear how much of Mantle was literally copied into the Vulkan API. But we’ve been told that the two APIs enable identical capabilities and are capable of the same things. The differences between them are differences in implementation and structure, not fundamental function."

Perhaps since the issue is not clear one way or the other we should leave the parameter blank and just provide this information in the article. Sizeofint (talk) 18:29, 22 April 2015 (UTC)
I think the first question we need to answer is "what does 'Original Author' actually mean?" We know that Vulkan started from Mantle; this is well documented by the Khronos Group in their presentations. My question is whether that is sufficient to declare AMD the 'Original Author's of Vulkan? Is there some prior precedent for what "Original Author" means? What articles have this designation that we can look at for reference? Do we even need such a statement at all?
If we can't figure out what the label means, then it seems clear that we should remove it. The article already makes it clear that Vulkan derives from Mantle, so the article itself need not be changed.Korval (talk) 06:46, 24 April 2015 (UTC)
Considering the extensive code reuse, Vulkan could be considered a fork of Mantle 1.0. I don't know what the precedent of original authorship is for software forks. At LibreOffice a fork of a fork of StarOffice, they list StarDivision as the original author. Sizeofint (talk) 02:13, 25 April 2015 (UTC)
I don't think this can be considered code reuse or even fork (in software sense). AFAICU from Graphic APIs, all a Graphic API is about is providing [a preferably consistent] programming interface [maybe just a header file] that would be useful and efficient for higher level developers to develop on top of it. This can be implemented as a well accelerated by hardware or maybe totally in software (or fallback-able to, like Mesa), so rather than software sense of code sharing, this is about sharing ideas that every member of Khronos group can implement them efficiently [and again, preferably consistent]. AMD as a member of Khronos group has no special driving role [AFAIK] and even the fact Vulkan first ideas was brought from Mantle [or maybe I don't know MS DX12 even] now, specially before its public release, is being made neutral by Khronos members to take advantage of the group future hardware designs capabilities. –ebraminiotalk 12:16, 18 May 2015 (UTC)
I probably should have been more clear. Vulkan is indeed a specification rather than code (excepting the header files). The issue isn't that ideas from Mantle are being used in Vulkan. It is that, from what I can tell, parts of Mantle are being used directly within Vulkan. A commentor here for example www.pcper.com/news/General-Tech/GDC-15-Khronos-Acknowledges-Mantles-Start-Vulkan compares some Mantle dll code to some Vulkan code. They are almost exactly the same. Granted, a comment on an article is not a reliable source but I think this shows the debate is still open. Until the final specification of Vulkan is released and some reliable sources can compare it to the Mantle specification, I think the best course of action is to list the Khronos Group as the sole author in the infobox while explaining Vulkan's basis in Mantle within the article. Sizeofint (talk) 16:40, 18 May 2015 (UTC)
Agreed. I think the main quote on that page, "Many companies have made great contributions to Vulkan, including AMD who contributed Mantle. Being able to start with the Mantle design definitely helped us get rolling quickly – but there has been a lot of design iteration, not the least making sure that Vulkan can run across many different GPU architectures. Vulkan is definitely a working group design now.§" would be more reliable for Wikipedia than that comment that seems claims disassembled that dll file (AFAIK such disassemblyings, wouldn't keep header constants and variable names like this, but maybe that is just normalized to show the whole point). –ebraminiotalk 17:25, 18 May 2015 (UTC)
If that's the consensus, then we should remove the "Original Author" section entirely. I'll do that. Korval (talk) 02:49, 19 May 2015 (UTC)
AMD should be listed under the "author" section if they don't technically fit in the "developer" one. Vulkan is largely built upon Mantle, which AMD created and eventually gave some portion of to Khronos. Wikinium (talk) 17:27, 19 May 2015 (UTC) EDIT: I like the special contributions part currently in place. That will do do, it satisfies the need for clarity. Wikinium (talk) 20:38, 19 May 2015 (UTC)
IMHO we should less rely on our original researches. If Neil Trevett, the president of the Khronos Group, says "Vulkan is definitely a working group design now" and "Many companies have made great contributions to Vulkan" we should more consider that than we may know AMD contribution to the API was special so they should be considered as special and noted separately as co-authour other than being implicitly mentioned as a member of Khronos group. As far as I know the main brand new thing about these new APIs that is highlighted (e.g. on Vulkan code snippets), the command sets, was available even now on OpenGL 4.5 as an extension developed by NVIDIA, AMD and Intel, more info (well, an original research example ☺). –ebraminiotalk 00:17, 24 May 2015 (UTC)
We should probably just leave out the author entry for now until more information is available. Sizeofint (talk) 19:03, 24 May 2015 (UTC)

License

Hello people, I'm an amateur in this subject and I didn't understand a point: will Vulkan (API) be open source, free or proprietary? Does it apply to APIs? Is the license it will be released known? Should this information be pointed out someplace? Guilherme Peev (talk) 14:21, 14 July 2015 (UTC)

At this time, it would be smart to assume it's like OpenGL, but not add anything to the article until they confirm it. Wikinium (talk) 04:23, 18 July 2015 (UTC)

Reduced the load on CPUs in situations

Wouldn't vulkan increase the load on the CPU by allowing more threads to do work? — Preceding unsigned comment added by 2601:602:8100:6668:AD44:9824:88B4:76D5 (talk) 02:47, 26 October 2015 (UTC)

AMD series support needs fixing up.

As per the support page for AMD's drivers for Vulkan: http://support.amd.com/en-us/kb-articles/Pages/Radeon-Vulkan-Beta.aspx?webSyncID=c22ca125-14e6-3ba7-2140-16c1a2a5d2d5&sessionGUID=8b8499e2-2b83-2dbd-6791-6bde957b1409 the GPUs supported start at 77xx. However the table implies the entire 7xxx series are based on Terrascale, which is not true. 7xxx-76xx are based on TS, whereas 77xx-79xx are on GCN with the exception of 7790, which is on GCN1.1.

I can try fixing it up but I'm back from a huge hiatus doing anything mediawiki related. Anijatsu (talk) 11:25, 19 February 2016 (UTC)

Intel mesa drivers

Vulkan support for intel currently resides in a branch of mesa here: https://cgit.freedesktop.org/mesa/mesa/log/?h=vulkan and is not yet in a release, claiming 11.3 is speculation. Also, the Windows Intel driver is not mesa, and thus not covered. — Preceding unsigned comment added by 74.99.152.224 (talk) 17:52, 22 February 2016 (UTC)

Window System Interface

Added "Window System Interface" as a section. Maybe some day it will be an own article similar to EGL (API) and GLX. User:ScotXWt@lk 17:12, 27 February 2016 (UTC)

"implemented to" ?

I'm not sure what is meant by the phrase "implemented to" in the first paragraph: "...unable to be implemented to any older games."

Could someone either explain this to me, or provide a better phrasing of whatever this is meant to mean? — Preceding unsigned comment added by KurtHLarson (talk • contribs) 06:15, 20 July 2016 (UTC)

This was actually on the Mantle (API) page but I fixed it. Sizeofint (talk) 16:20, 20 July 2016 (UTC)

someone should fix the grammar in this article

it is kind of bad so someone should fix it.84.212.73.96 (talk) 14:29, 19 August 2016 (UTC)

Mind being more specific? Sizeofint (talk) 15:53, 19 August 2016 (UTC)

3D vs 2D

Here 3D is mentioned in the lead, as opposed to at Open GL]]: "for rendering 2D and 3D vector graphics."

2D is a subset of 3D, I just wander if it was left out on purpose. Is the API somehow less for 2D (or only for perspective not orthographic projection?).

Anyway, on OpenGL.. vector graphics implies, not bitmaps, and maybe not textures.. comp.arch (talk) 14:12, 25 August 2016 (UTC)

Games that use Vulkan

It's inevitable that, as time goes on, we will see the list of games using Vulkan grow too large to be contained on this page. When that time comes, I propose the creation of List of games that utilize the Vulkan API or List of games that use Vulkan.

Wikinium (talk) 17:47, 8 May 2016 (UTC)

Yes, I agree. Perhaps even List of applications that use Vulkan with a subsection for games. Sizeofint (talk) 02:15, 9 May 2016 (UTC)
Possibly. It depends which way Vulkan goes. It seems it'll focus on games with very few applications (CAD, modelling, etc) using it and instead going toward OpenGL. Right now it seems most likely it will mainly be used in games, but that applications list would still be nice to have if maybe 10 or more popular applications were using it. We have the option to subset both games and applications in one page, make two separate pages, or just include them in the main Vulkan page for now since the lists are extremely tiny. Wikinium (talk) 19:15, 9 May 2016 (UTC)

Should Star Citizen currently be listed as software that supports Vulkan? Although they've said they're planning to support it exclusively, the game as of right now only supports DirectX 11. They've actually released their development schedule for the rest of 2017, and nothing on there seems to pertain to the graphics API change. So at this point, it seems the game will be using DirectX 11 until further notice. Every other game listed in this section is actually playable using Vulkan, but Star Citizen isn't. Should it be there? Tre0n (talk) 10:17, 24 April 2017 (UTC)

Quake port

@Dissident93 and Wikinium: Instead of having a slow edit war about the Quake port why don't we discuss? My reservation about including the port is that it may be WP:UNDUE. The best substantial independent reporting on the port I could find on the search engines was this brief Phoronix article http://www.phoronix.com/scan.php?page=news_item&px=Quake-1-On-Vulkan. Sizeofint (talk) 23:35, 25 August 2016 (UTC)

  • The user was claiming the entire id Tech 4 engine supported Vulkan because of a mod for one single game, which is pretty silly. We should only add games if they officially support Vulkan, and exclude unofficial mods. ~ Dissident93 (talk) 01:00, 26 August 2016 (UTC)
"Support for Vulkan/OpenGL/Direct3D 9/Direct3D 11/GNM" simply means there are multiple rendering paths available. How much effort must be put into porting the Vulkan-rendering path form CryEngine 5 to CryEngine 3 or from idTech6 to idTech1 depends on the differences in the source code… Is vkQuake a new game engine, or simply idTech1 with a Vulkan-rendering path added to it. Maybe the idTech1 had to be tweaked a bit, maybe not? User:ScotXWt@lk 12:35, 21 February 2017 (UTC)

I'm not sure if it breaks policy but there's a direct link to a book for sale on amazon in the external links. Thought I should let someone know 77.218.240.5 (talk) 16:21, 22 March 2017 (UTC)

Thanks, removed it since IMO there isn't a strong reason to prefer this resource over others. Sizeofint (talk) 19:00, 22 March 2017 (UTC)

Low overhead??7

Wait the minute this molestful blurb - "low overhead" is following the name "Vulkan" everywhere on WP. In fact it's encountered NOT less than the "Vulkan" name. What this means? Or, another way - how this is possible? In the encyclopedia? I thought, advertizing speach is not welcome here. Or "someone is more equal than others". Shame on you, wikipedia! Freaking "low overhaed" shame. — Preceding unsigned comment added by 188.190.1.60 (talk) 20:25, 6 May 2017 (UTC)

What it means is explained in the article; the main point of Vulkan is to remove unnecessary work (locking, data validation etc) from the fast path of the API -- usually compared to the high-overhead OpenGL. It's factual and backed up by sources so I see no reason to remove that outright.
Please bring some examples where it's used inappropriately. -- intgr [talk] 22:38, 6 May 2017 (UTC)
oh please, don't pretend it is not an impudent advertisement! if this definition "low overhead" is meaningful at all, then only as a comparative definition with that standard, allegedly of higher overhead, and it should have been used only in the appropriate section where the comparison is made. otherwise it's a promoters' "meh" ridiculously put in every line where the word "Vulkan" is present, and left overlooked by "true" wikipedians. promoters have their sites for this nonsense. — Preceding unsigned comment added by 188.190.1.60 (talk) 07:26, 19 May 2017 (UTC)
Please quote some examples where you think it's unwarranted, then we can have a discussion whether it's appropriate for the context or not. Right now you're just handwaving and making condescending remarks towards editors — that's not a productive way to start a discussion with said editors. And if you're not here to have a productive discussion then I don't know what you're doing here. -- intgr [talk] 14:42, 19 May 2017 (UTC)
first line of the article, first line of the "Feature" section in this article. "Low overhead" there sounds as nothing but an unrelated to the unbiased description blurb. what the measure of this qualification is? how that "lowness" of the overhead was measured? it's a subjective not meaningful statement intended to attract. I was here to find a link to that "low overhead" marvel if you ask. it would be hard to say I was surprised by this, though. still, I can't imagine the same "low overhead" statement survived more than minutes applied to eg D3D here. *cough* double standards. *cough* — Preceding unsigned comment added by 188.190.1.60 (talk) 13:22, 21 May 2017 (UTC)
In features it is used as a direct comparison to OpenGL exactly what you claim you wanted. Are you just trolling? Carewolf (talk) 10:25, 22 May 2017 (UTC)
We call it "low overhead" because that is how Khronos described it here https://www.khronos.org/assets/uploads/developers/library/2015-gdc/Khronos-Vulkan-GDC_Mar15.pdf. They additionally explain Vulkan is not a "low level" API so they do not use that terminology to describe it. Sizeofint (talk) 03:46, 23 May 2017 (UTC)

Compared to what?

The first sentence includes this text: 

   can offer higher performance and more balanced CPU/GPU usage

Higher performance and more balanced CPU/GPU usage than what?

69.143.175.242 (talk) 00:40, 5 June 2017 (UTC)

Compared with OpenGL and Direct3D 11 presumably. Sizeofint (talk) 00:50, 5 June 2017 (UTC)

For me, that is just advertisement. It's not even backed up. Eluchsinger (talk) 13:50, 16 August 2017 (UTC)

I modified the wording slightly. It appears we need to add some performance analysis to this article. Sizeofint (talk) 17:07, 16 August 2017 (UTC)

Specification

Vulkan is a low-overhead, cross-platform 3D graphics and compute API.

— Vulkan (API)

It should be clarified if it is specification or just "API" as is is said on the project's main page: «Khronos launched the Vulkan 1.0 specification on February 16th, 2016 and»[1]109.206.156.72 (talk) 11:47, 15 November 2017 (UTC)

Requested move 23 March 2018

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: no consensus to move the page as proposed at this time, per the discussion below. If this is revisited at some point in the future, please consider presenting evidence of the prevalence of the requested name in reliable sources. Dekimasuよ! 01:41, 6 April 2018 (UTC)


Vulkan (API) → Vulkan API – No parentheses are necessary. It's also called "Vulkan API" in sources. ZXCVBNM (TALK) 06:33, 23 March 2018 (UTC) --Relisting. Andrewa (talk) 11:21, 30 March 2018 (UTC)

Survey

  • Oppose as official website has this as just "Vulkan" without the API in its title. The API is what it is, not neccessarily what it's called. Bungle (talk • contribs) 19:39, 25 March 2018 (UTC)
    • Per WP:NATURAL: Using an alternative name that the subject is also commonly called in English reliable sources, is preferable to using a parenthetical disambiguation. It doesn't have to be the exact name that it is called by the developers in question.ZXCVBNM (TALK) 23:13, 25 March 2018 (UTC)

Discussion

  • I'd strongly avoid using an abbreviation in the title; we have to disambiguate, so I would suggest "Vulkan (programming interface)". --Masem (t) 15:33, 30 March 2018 (UTC)
    • Interesting point... IBM and MVS are article titles, but UK is a redirect. But do similar principles regarding acronyms apply to disambiguators? I can't see why not. Andrewa (talk) 20:24, 30 March 2018 (UTC)
      • I don't particularly have an issue with abbreviations when they're very common ones, though would always want to support a move where clarity is enhanced or retained. Whilst I'd have no issue with the aforementioned suggestion of Vulkan (programming interface), I don't suspect the nominator, who seems to have a problem with (these()curly()things) would vote in support of that. Bungle (talk • contribs) 21:15, 30 March 2018 (UTC)
        • I suspect that our policies and guidelines don't entirely match our practice. To me API is a very common abbreviation, and I'd suspect it's far more commonly recognised than MVS. But both are only recognised by the subset of the population who even know that the topics exist. Among these people the full name has a rather weird sound to it... I can more vouch for MVS on this point, ask any current large-IBM sysprog what it stands for and they'd need to think and some would even then get it wrong (I have heard it called "multiple virtual-address spaces" for example, which is actually more accurate in some ways but not officially, and historically it's "Multiple Virtual Storages" and always was in my day), but prior to OS/390 it was on the first line of the "skills" part of all of our resumes as the abbreviation. Andrewa (talk) 06:49, 1 April 2018 (UTC)

A straw man that might be useful here: I don't suppose anyone wants to rename OS/390 to Operating System/IBM 390? I've never heard it expanded like that and am happy to leave it as a redlink, but I guess that would be more recognisable to the general public, arguably at least. Despite the redlink Google web search for "Operating System/IBM 390" (note the quotes) finds our article, and even one (but only one) reliable secondary source. Andrewa (talk) 06:57, 1 April 2018 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Intro needs editing for clarity

I'm a GNU-Linux using geek and I'm still struggling to understand what the Vulkan API is from the intro to this article, probably because it has too much technical detail that belongs in the article body. The intro needs to be clarified and simplified, to make sense to a lay audience. Danylstrype (talk) 06:20, 21 June 2018 (UTC)

Information about the licence is also missing throughout the article. There are hints that it's free software, since merging with OpenCL is mentioned in the present WP text, but WP:RS'd info would be better than guessing from the text... Boud (talk) 13:58, 7 March 2019 (UTC)

Vulkan 1.0 for AMD GCN 1st and 2nd Gen in Linux RADV available

See Test in

https://www.phoronix.com/scan.php?page=article&item=gcn10-tww2-radv&num=1 — Preceding unsigned comment added by 79.223.157.146 (talk) 22:12, 1 February 2019 (UTC)

Vulkan 1.1 only for AMD GCN 1.2 (2nd gen.) or higher

Vulkan 1.1 only for AMD GCN 1.2 (2nd gen.) or higher See Khronos Vulkan product Table. No Vulkan 1.1 for 1st GCN gen.

See https://www.khronos.org/conformance/adopters/conformant-products/vulkan

Also Vulkan 1.1: Nvidia Kepler and Higher Intel Kabylake and higher

And some Android Chips — Preceding unsigned comment added by 95.90.228.17 (talk) 23:46, 19 April 2018 (UTC)


Vulkan 1.1 is supported on 1st GCN gen. Vulkan 1.1 features are mostly driver related, not hardware. There were simply a bit delay before Vulkan 1.1 is fully supported, tested and officially exposed for the older hardware. On Linux on my HD 7000 series (Tahiti, which is GCN 1st gen) card it says Vulkan 1.1 is supported, and it works. 2A02:168:F609:0:4F70:D338:7795:DADF (talk) 06:02, 12 September 2019 (UTC)

How is it that ID Tech 7 uses Vulkan exclusively?

This is not cited, and doesn't really make sense as PS4 does not support Vulcan. — Preceding unsigned comment added by 144.121.72.115 (talk) 19:37, 19 March 2019 (UTC)

Ivy Bridge on Linux has Vulkan 1.1 compatibility and not fully complete Vulkan support

The table shows 1.0.

https://wiki.riteme.site/wiki/Vulkan_(API)#Compatibility

But I have an i5-3320M and vulkaninfo reports the following. 

Vulkan Instance Version: 1.1.115
...
apiVersion     = 0x401066  (1.1.102)
...
        conformanceVersion:
                major    = 1
                minor    = 1
                subminor = 2
                patch    = 0

System: Archlinux with mesa 19.1.5-1

And actually the global Vulkan support is not complete. 

# just run vulkaninfo, don't pipe to less or otherwise the warnings will not be printed
INTEL-MESA: warning: Ivy Bridge Vulkan support is incomplete
INTEL-MESA: warning: ../mesa-19.1.5/src/intel/vulkan/anv_device.c:1504: FINISHME: Implement pop-free point clipping

So we need to find sources for these two info if I understand correctly how Wikipedia works.

Tuxayo (talk) 20:18, 26 August 2019 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Talk:Vulkan/Archive_1&oldid=1086328948"