An API (application programming interface) is a defined technical vocabulary that makes it possible for different parts or pieces of software to communicate with each other. In this case, it's the vocabulary used between graphics applications and drivers. Vulkan is a clean redesign from the same consortium that maintains OpenGL. It attempts to only add the minimum amount of bookkeeping needed to manage newer (unified shader) graphics cards. OpenGL has a lot of fairly complex formalities that seemed like a good idea in the 90s. The main advantage is that it has slightly more useful defaults than Vulkan. *Very* simple applications are smaller in OpenGL, but it's pretty easy to reach a point where Vulkan is more straightforward.
OpenGL is not going away, it's important to stress that. Khronos has stated multiple times they'll keep maintaining it, and they already delivered on that promise with GL 4.6. Hobby engines and students will not be forced to mess with Vulkan, it serves a different niche (high-end game graphics engines) than openGL (cross-platform, widely compatible graphics)
I just wrote a longer comment about this (at the same time as you). I'd go further and say that Vulkan does not target most users, but more importantly, it targets GPU driver developers. Vulkan moves a lot of the hardware independent checks into a vendor-independent library, greatly reducing driver complexity. This was (and still is) critical in the emerging mobile sector. Vulkan is also not only high-end graphics engines, but also projects which require greater flexibility such as video-game emulators, API backwards compatibility wrappers (glide / OpenGL / ..) etc. Another showcase that the OpenGL specification is here to stay (as primary target API by software developers): WebGL.
Also there are libraries to run OpenGL code on a Vulkan driver, essentially making the library a sort of psuedo-driver for OpenGL, and since Vulkan is very "thin" it should perform fairly well. Also one of the biggest issues they were talking about were conformance and defined behaviors, which were very loose with OpenGL, but very explicit in Vulkan spec. That's not as cool to talk about in a "wtf is" video, probably, but OpenGL hasn't been demolished and will remain; probably just minus the horrors of compatibility profiles, and explicit OpenGL drivers could eventually just become static layers, which would take a HUGE load off of multiple parties
So the backwards compatibility that comes with OpenGL isn't going to be ignored in future graphics cards, there's just going to be an alternative solution for more demanding future games?
@@mnomadvfx Only way this will be acceptable for GPU manufacturers to drop OGL support is if Vulkan gets backwards compatibility up and running so until that's a thing, Vulkan has awhile before it can replace it. Part of the appeal of a PC is the fact that I can take a game I bought 20 years ago and with a few tweaks, play it. Killing that would basically make Console gaming superior at least to me because sure 4k 120+fps is great but that's a minority because it's expensive to even get hardware that can do that.
@@GrimmsDeath Yes it is indeed a no go abandoning OGL until a DXVK like layer can replace OGL code functionality on Vulkan only drivers - apparently the ANGLE effort has already begun a desktop OGL frontend specifically for their new Vulkan backend, though it will likely be some time before it reaches anything like DXVK usability.
1:30 yeah I definitely remember what a shitshow the soundcard system was back in the early nineties. A lot of the games I had then were quite particular about the sound output options, with some of them crashing if the wrong option was selected.
It was a nightmare to configure, but at least we got some de-facto standards. I had a Pro Audio Spectrum 16 for most of that era... And while some games supported it directly, more often than not I was dependent on the fact that this card was fully compatible with SB16/SB Pro, so if a better option wasn't available, that'd work. ... If you got your settings right. XD No, the real horror of that period was graphics cards. Oh sure, up until VGA everything was largely standardised. - (in fact, on a modern PC, VGA is STILL the only guaranteed basic 2d graphics settings you can be absolutely sure all systems will support directly.) But SVGA was a disaster of incompatible standards and nonsense. Sure, VESA existed, but this was a bandaid afterthought, and often very difficult to get working. Instead most games supported something like 20 different graphics card types, where there were drivers for maybe 4-5 different audio standards, and games for most people would still work just fine if the only thing supported was sound blaster or adlib... SVGA was the peak of insanity for lack of standards, since by and large the other hardware of the era had already mostly settled into various de-facto standards. SVGA was technically NEVER standardised, even to this day, we still only have the rather loose and not particularly consistently applied VESA modes. It has of course been simplified somewhat since Windows can apply a bunch of driver standards that DOS never could, and we're essentially down to just 3 graphics card manufacturers anyway... But still if you write bare metal code on PC (bypassing existing operating systems for various reasons), you STILL can't count on a PC being able to do anything better than VGA with any consistency... Which is kind of nuts when you think about it, huh.
When integrated soundcards started becoming fairly common, I thought maybe these problems were falling behind us, but it just wasn't so. The first computer in my life that was genuinely "mine" was a Packard Bell Pentium 75mhz. In order to get the sound to work in Doom I had to start the game, shut it down, then start it again. I never found any reasonable explanation for this phenomenon. That computer had quite a few interesting problems, but getting sound to work right in anything was definitely one of the most annoying.
The real problem back in the 90s was 3D accelerated graphics. I remember trying to get Shadows of the Empire on PC to work and 9 times out of 10 the game would complain about DirectX (which John Carmack was super critical of back in the day). My mom's boyfriend at the time happened to be a PC guru and was able to get it working after weeks of searching forums/bbs boards but man was it a real pain in the arse back then when a game wouldn't play nice with your hardware. Kids these days will never understand the struggle lol
Long time reader of your blog and I wasn't originally sure if I'd find these videos as good as your text posts, but this was very enjoyable and I hope to see more of stuff like this
Backwards compatibility is a double-edged sword. Look at the PC in general, and Dos and Windows in particular - their success against other computer platforms of the 80's can largely be attributed to two things; - an open platform anyone can release hardware for (wasn't intentional on IBM's part, but it happened anyway) - A very long near unbroken run of backwards compatibility, both at a hardware and software level. Even now, on windows 10, with the most recent API's, I can technically write code to the same standards I used with windows 95 and it'll still work. DOS software was a victim of some cleanup attempts, but it's not hard to get the tools needed to run those programs (DosBox, which in some ways is emulation, but in many ways isn't - it emulates old hardware like a sound blaster, but not basic elements of system operation in general - because it's STILL running on a PC in most situations) Don't like Dosbox? No problem, you can still find modernised versions of DOS that will run those old programs easily. For that matter, it's technically still possible to install something like windows 95, Dos 6.21 or the like on modern hardware. And... A modern PC is still hardware compatible with x86 code - the original 16 bit standards from the early 80's. All of this was critical to the success of the platform, but... It does come at a cost. And you remove this legacy support at your own peril - microsoft has made several attempts, but the results generally haven't been popular. (granted they also seem to combine it with trying to turn the open platform that is the PC into a walled garden, the same as the Macintosh environment. Which isn't helping matters any) Cruft is a symptom of something that is important, but it is of course a headache in it's own right... Never underestimate the benefit of backwards compatibility, but at the same time, remember it isn't free... And cruft is one of the costs of it...
I tend to like to live in the new house... But be able to visit the old family home at occasions. There is a value to preserving the old. But one does not have to live in the old all the time. (I am talking about the ability to run DOSBox on my new PC Of course) ^_^
It is a double-edged sword, but it is one of PC Gaming's greatest assets and is one of the reasons our art form is good. It isnt free, but it is a price we must be grateful to pay.
@@Cythil Art forms like literature have advanced so much and are so great, greater than all other art forms including gaming, due to their ability to be preserved. There is not just value. There is a requirement.
@@CharcharoExplorer Well I am not sure what art form is best if we go by preservation. Pretty much all digital art is easy to preserve in theory simply due to how easy it is to copy. Traditionally books where not easy to preserver or copy. Why we have lost countless works. Anyway matter little as all art is worth preserving in my book. And books are awesome ;)
@@Cythil We have lost countless works, but we have also preserved a lot of them too. And under worse conditions. And if we are smart, we won't lose anymore books...ever. And yeah, I want games to be preserved. I want my kids to be able to start their PCs and at least see my old games. Same way I do with old games now.
@@busteraycan then why western youtuber doing what should be done by indian dude, why western ppl do not do what they should instead? i will send a complain against this video, thanks for your eye-opener comment!
@golden maximo this is not dev vlog for developers, and not a vulcan conference.....go to the proper place to hear what you r expecting.Here is an consumer grade explanation, so ppl would know what is better for them to use in settings: opengl or vulcan
"I don' want to stop and explain what an API is..." Well, then you are going to have trouble in this video, because that's exactly what OpenGL and Vulkan are?
The EasyVulkan wrapper makes it as easy to use as OpenGL...but still allows expert useage. Nearly all of the math for 3D was defined in the 60s, so API stabilty is a good thing. Good review!
Hey Shamus, great video! If Vulkan is dropping backwards compatability does it mean that modern games using it will be unplayable in a couple of years? Or do they have a plan for handling that?
As far as I understand, this is a one-time cut. Software that is not updated to use Vulkan instead of OpenGL will no longer run on systems that only support Vulkan and not OpenGL, but those kinds of systems probably won't appear (or at least not be in widespread use) until a few years down the line. Until then, all games should remain playable that are currently playable on either OpenGL or Vulkan. To get to the obligatory car analogy: it's like a new fast lane that only certain vehicles can use opens up. They won't replace or make even newer fast lanes for the forseeable future, and vehicles that aren't allowed on the new lane can still use the old road. But it's an additional option.
Yea every time I hear about vulkan Im tempted to learn about how it works and try to make some kind of basic 3d engine thing with it. And then I remember how easy it is to just put some stuff in Unity and have it work immediately with no hassle.
Important thing to note is that Vulkan shaders compile down to its intermediate representation - this is about SPIR-V. GLSL shaders can also be compiled that way.
As someone who's starting to game on Linux, I am just so glad that Vulkan support and development are going up. It is just so nice to install a game and it just works. Not gonna lie, the only reason I still dual-boot Windows 10 - that horribly bloated and messy piece of software - is because of gaming and nothing else.
Vulkan being raw and closer to the metal allows not only for a finer degree of optimization, it also allows to implement other protocols on top of vulkan with very little or barely no overhead, like DXVK in Linux which implements DirectX 9/10/11 on top of Vulkan to allow windows games to run at full speed on Linux via Wine or Valve's Proton. Also it allows emulators a more efficient way to emulate old graphics hardware. There is also a project to implement OpenGL on top of Vulkan, which can potentially make OpenGL more efficient in terms of hardware usage.
first pc i had i had to manually input sound card info to some games and this info would pop up on the startup screen... that same screen that i dont think current pcs even have because it either moves by too fast or simply been removed first pc was from 97
0:19 The Vulcan That is on a pretty big hill in Birmingham, the wireless ISP in me wants to head up to the tower, point a decent radio out there and see what I can hit just because... Couple of 2,000 ft towers nearby as well, that would just be fun to play with.
Valve's Steam Play and Proton has made gaming on Linux a dream. I realize this is largely thanks to both Vulkan and DXVK, however 80%+ of my games work perfectly on Steam so I was able to totally ditch Windows late last year. Feels good to be free of Microsuck.
One thing about Vulkan is how well emulation of 3D systems can utilize it for quite accurate and way faster rendering, and utilize GPU more. Dolphin devs said that a very Unique GC graphics call would been 13 calls per frame on OGL, and it was reduced to 3 with vulkan. Playstation emulation can now utilize vulkan too, though benefits are not entirely apparent, it has more to do with accurate, yet hardware accelerated and clean output. Beetle psx displays broken graphics on some obscure titles like PAL versions of some titles, unless you utilize vulkan and it is OK. Also could been already updated. The main takeaway, hardware closeness and what Vulkan emables is apparently good for 3D console emulation.
Rooftop antennas ARE still useful despite all of us being told that modern digital broadcast requires special hi-def antennas to work. My dad, who doesn't care enough about TV or internet to get cable, decided just for the hell of it to hook up his 50 year old birdroost-looking rooftop antenna to his brand new TV just to see what would happen. He lives about 15 miles outside of a major city with digital broadcasts. He now receives over 30 channels completely free and crystal clear. Just something to consider for anyone here in the comment section with an old house full of "cruft." Don't be so quick to tear that metal eyesore off the roof just yet.
Shamus Young This is honestly the first video about Vulkan (which is by the way the German way to write "Vulcano") in which the names AMD and nVidia didn't fall. Way to avoid tribe wars XD
The only reason it would be hard for bedroom indie devs to deal with vulkan, is if the engine they're using limits them, and they start making their own enigne that only has what they need, and therefore they have to think about it.
Not even a tiny mention of DirectX? Most PC games and all Xbox games target DirectX. PS4 has a proprietary API. The real beauty of Vulkan is that it runs on all platforms so devs will only need to target one graphics API. This will come handy as well for new platforms like Stadia, which is Linux based.
Not quite on all platforms, Apple still stubbornly clings to Metal requiring MetalVK to translate from Vulkan. Not to mention Windows 10 for ARM supports only DirectX and the ancient OpenGL 1 (seriously MS you are pranking us right?).
@@MoncefNaji True enough. Still though, at least MoltenVK offers a degree of compatibility with Vulkan code on Mac and iOS, which is more than can be said of Windows on ARM. If anything the DXVK efforts combined with MoltenVK may contribute almost as much to Mac as it does to Linux.
"It runs on all platforms" is pretty much the case for OpenGL, but it didn't help to win against DirectX for games. Then it probably also won't help Vulkan against DirectX.
@@cube2fox ""It runs on all platforms" is pretty much the case for OpenGL" Nope. It's an open standard, so it can be IMPLEMENTED on all platforms, but that doesn't guarantee support - Apple stopped supporting the desktop and mobile versions of OGL some time ago after announcing their Metal API. Likewise Windows on ARM only supports the ancient OGL v1.0 - which as good as means zero support. As to Vulkan not "winning" against DX - it's in both UE4 and Unity cores, not to mention iD Tech 6/7 and Source 2, I'd hardly call that a win for DX, especially when DXVK now gets to near parity FPS with legacy DX9-11 games on Linux (packaged in Steam Play/Proton for ease too).
i remember my sound card didnt work on laptop :/ wanted to play some games but it wouldnt even launch or something like that (my memory is garbage) because the card didnt work
It's actually a lot of fun messing around with code. Maybe something already exists? There is already an efficient way to do it. But, that doesn't mean it isn't hell fun learning by failure.
@@mxdanger Well, I'm living in RGB hell then: -NZXT Hue2 RGB for the case and AIO -ASUS Aura Sync for RAM and Motherboard -Razer Chroma for keyboard -Steelseries for Mouse and Mousepad But it really sounds worse than it is. Although NZXT Cam doesn't communicate with Aura Sync they have the exact same preset colour pattern and timings so it looks actually really nice. The peripherals outside the case are just random RGB effects cause I didn't bother to adjust them. What bothers me the most about the fact that manufacturers can't settle on one standard for RGB illumination is the fact that you need so many programs running in the background if you want to have your custom settings running. Fortunately some of the devices like the ones from Steelseries can keep their settings even after closing the program and don't run in the background. Because the setting is saved on the device. In my opinion this is the way every manufacturer should implement RGB as long as there is no standard for RGB. In fact I was surprised when I learned that Razer, NZXT and others require a program to run in the background or otherwise the device goes into manufacturers preset mode. NZXT annoys me the most cause their software takes the most resources. Why can't these manufacturers implement RGB the same way Steelseries does? The Razer keyboard I got released 2019 costs 200$ and can't remember it's settings, but my Steelseries 35$ mouse from 2015 can. why? NZXT even has a "starter kit" for their LED stripes that adds 20$ to their regular 20$ LED kit and that thing can't do what a 35$ mouse from 5 years ago can.
It's not really bulldozing the house to build a new one on top. It's more like building a new one next to it. OpenGL will continue to be maintained and upgraded.
Maintained yes, but not really upgraded and further developed anymore. We are already seeing new features going straight to Vulkan und OpenGL not getting support for them. OpenGL will run and be supported for quite some time. But it's a dead technology that should not be used for new projects.
A little note about the benefit of Vulkan; It HIGHLY depends on your hardware, and the software you are running. Vulkan (usually) has a much lower overall cpu usage, and has MUCH better multithreading support. In general, this means Vulkan will show an extreme improvement on systems that are cpu limited, while you likely won't see much of a difference otherwise. As an example of the difference this can make, I recently bought Doom (2016). My desktop has a fairly good GPU, but a terrible CPU, an old intel quad core from around 2011. On the lowest graphical settings in the first area I was getting a steady 30 fps, after noticing there was an api option, I switched to Vulkan, and was able to get a steady 120 fps on near max settings. Again, this will vary a lot between systems, but you can expect to see fairly high improvements if you are cpu limited.
Actually the problem hasnt disappeared anywhere. The problem is now on more like every big company (Microsoft) Wants to have their API be the defacto standard only for gaming and tie every game development to their (microsoft's) platform. Vulkan is more or less attack against that. There would not even probpably be vulkan if DirectX would be open and or Microsoft would be using OpenGL
I like your other videos but I feel this one has missed the mark in a lot of ways. I commend your efforts on trying to take loftier concepts and make them digestible for the less tech savvy but there's an entire slew of information that would have provided some sorely needed context: - Vulkan is not really a replacement for OpenGL. Both are different API sets with a different underlying architecture and methodology that can be applied for varying projects and tasks. It seems that what you spoke of was (especially based on your channel content) geared towards gaming. From this perspective it can be viewed as a 'next generation' API that allows for a generally smoother experience, sure- but this doesn't mean that OpenGL has been made entirely obsolete. - Vulkan being more complicated and therefore more difficult for students, developers, etc... I'd have to argue there. If you take both OpenGL and Vulkan as a potential path to take for someone that doesn't know either, the disparity in difficulty is actually not that large. Taking someone that has worked with OpenGL most of their life and having them suddenly switch to Vulkan? That's a different story. There's a lot of assumptions and concepts from OpenGL that don't translate that well to Vulkan, admittedly- so you'll be having to overcome your own preconceptions which is arguably more difficult than if you're working with a clean slate. I think the issue really rests with veteran devs that are used to a specific API and its quirks already. - The greatest advantage of Vulkan hasn't even been mentioned within the video. OpenGL was never intended to be effective as a scaling API. Its architecture was not really built with future proofing in mind, per se. The way that GPU and CPU hardware has evolved, having beefier cache sizes, amounts of cores, advanced multi-threading and processing offloading techniques and ABIs to rely on has changed the landscape greatly. Vulkan was built with these newer/modern technology pipelines in mind as well as potential future use-case documentation (the one about Vulkan via quantum computing/qubits was fascinating- admittedly something I only have a surface understanding of). It therefore leverages multiple cores, advanced threading and timing chains more appropriately and skips of a lot of 'middle men' in the process. It was odd that you showed a chain of representational symbols for how OpenGL operates and all the 'layers' that are involved but didn't do the same for Vulkan. Vulkan was always intended to be a 'bare metal' API that allows for more direct calls to the hardware. Graphics Drivers, while providing the ABI and underlying bits, only acts effectively as a shim layer and most of the actual nitty-gritty management is handled by the developer, not the graphics API or driver (some exists but it's insanely minimal by comparison). - Another important and highly relevant piece that was omitted, despite the mention of backwards compatibility, is that the Khronos API standards are generally built with portability and cross-platform compatibility and ubiquity in mind. DX12 (From Microsoft) and Metal (from Apple) are comparable 'bare metal' APIs but they unfortunately are platform locked. If you develop in DX12, you're making code that is non-portable and relies on the Windows API backbone. Same thing with Metal requiring macOS to function. Vulkan allows for development that is transient and portable across multiple platforms such as Linux, Windows and macOS (I'd make mention of BSD but I know I'd get guff over it- so I'll let sleeping dogs lie). I could keep going as this is a topic I'm actually rather passionate about, but I'll stop my rambling before it gets out of hand. A re-release of this video I think would be favorable to both yourself, for your credibility's sake, and for your viewers from an educational standpoint.
Vulkan doesn't make games faster mostly. Really well optimised opengl can be almost identical but what you do get from Vulkan is lower latency and more stability of your frame rates. The biggest user of vulkan right now is really interesting, it's translating dx9 and up to vulkan for linux and it does an amazing job at that use case
Windows games that use Vulkan are also much easier to get running on Linux at native (or better than native) performance. Linux has OpenGL, and there are Linux native versions of OpenGL games, but when we want to play WINDOWS games on Linux, there's usually much less of a performance hit (or no performance hit at all) if the game is using Vulkan. For example, Both the OpenGL and Vulkan modes of the Windows version of DOOM 2016 run on Linux, but the OpenGL mode runs at like 93 percent of native performance, but the Vulkan version runs at 100 percent. Also, the biggest thing about Vulkan being used for us, is that if games on Windows use Vulkan instead of DirectX, we can get them to run much easier and faster on Linux. We can still run DirectX games using DXVK, which translates the DirectX calls into Vulkan calls (we also have WineD3D, which translates them into OpenGL calls), and they still run pretty great most of the time, but if more games used Vulkan, that's more games we can get to run on Linux with native performance. Or again, even better than native performance in some cases. There are actually Windows games out there that run FASTER on Linux than on Windows itself. Nier: Automata, Strange Brigade, and F1 2018 are a few of those.
It's not a bad try to explain why Vulkan so important is today. But a deeper explanation would be - at my oppinion - necessary to understand why Vulkan and a low level API important is.
You forget to mention that *Vulkan* *is* *not* *proprietary.* Since *Vulkan* *is* *a* *project* (not a product) has huge advantages over developing and learning. *Vulkan* *supports* *many* *devices* (and OS's) such as pc's, phones, game consoles etc. Yeah, It has the same principles like OpenGL but what if i did't know what OpenGL is?
To add what Xiefux said: Directx is doing the same thing Vulkan does and like with Vulkan, DX12 removes cruft to make games run faster. Problem is that if you want to use it, you need windows. If you are using linux, mac or want to put it on consoles and phones then tough luck and. Vulkan on the other hand can be used on anything, if Sony wanted to use Vulkan for PS5 they could do so and (don't quote me on this as I'm guessing) Nintendo are maybe using Vulkan on Switch. Plus there are tons of mobile games and programs that uses vulkan to run their games.
Vulkan is not a replacement for OpenGL because it carries OpenGL within it, it is a replacement for Direct-X in much the same way that a 90 lane two direction separated superhighway bridge is a replacement for a line of 2x8's on concrete blocks. Remember for a moment that talking to a graphics card occurs *through windows* on most PC's and that channel is part of the Direct-X implementation of windows even if it's a custom OGL that came with a graphics card. The Hardware Abstraction Layer is the all powerful god. Vulkan replaces it entirely and supports OGL as well. It isn't a replacement, it's a completely new system that can coordinate iterative GPU operation.
Is Vulkan maybe somehow of German origin? Because Vulkan is the German word for vulcan (all vulcans - the fire mountains, the species of Mr Spock, the cheap copy of the Grrek god of craftsmanship etc.)
Rage 2, from the looks of it. A good choice since Id is one of the biggest supporters of Vulkan, and was also probably the biggest supporter of OpenGL before that-continuing to use it even on Windows where almost everything else used DirectX instead.
Nice video, but you failed to touch upon probably the best aspect of OpenGL and Vulkan: the fact that they're open source, unlike Microsoft's DirectX API which is closed source and only available on Windows. This means that games that make use of Vulkan can be more readily ported to Linux without the developers having to waste time and resources to support an OS that represents only 2% of their audience, thus increasing the likelihood that more games will be made available for Linux users. To most people that use Windows for gaming and call it a day it's not a big deal, but to us Linux users, Vulkan has been a godsend and opened the door to more games making their way to the Mighty Tux. Maybe this topic warrants its own video?
vulkan, just like OpenGL, is developed by the Khronos Group. So everything regarding being open, that applies to OpenGL, also applies to Vulkan. In both cases though, you cannot really say, that they're open source. In fact, neither OpenGL, nor Vulkan were ever open source. They're just a standard, a description of how to talk to the graphics hardware. How these descriptions are applied to the graphics card and What exactly happens on the graphics hardware, has always been closed source and part of the graphics driver. But you still don't have to worry. Since every graphics hardware manufacturer has to develop their own version of vulkan/opengl and they all want you to use them to develop fancy stuff to showcase the power of their hardware, you'll always be independent of a particular hardware vendor, and will always have access to OpenGL and Vulkan.
@@sfrigge of course companies are gonna close what they develop whenever possible, but as long as it's an open standard, making it /possible/ to develop open source drivers, I'm happy.
@@ActingNT i wouldn't blame them though. The implementation talks directly to the hardware and thus opening that up would expose all sorts of Hardware details, their intelectual property. This would in turn make it way easier to reverse engineer the hardware.
I think a lot of people see "Open" and assume "Open Source" OpenGL is not "Open Source" it's just "Open for everyone to use it" If it were OpenSource then that will give developers the right to change and add things how they like. AMD may include some awesome new feature for OpenGL, that may give them the edge over another company. They wont have to share it, and this is where problems will arise. And why standards are needed in some things. Remember the browser wars? Adding in supported features that went against competitors? It is thanks to standards why it shouldnt matter what browser we use (although just like OpenGL it's down to the developer of the browser how they implement those rules, as long as the code does what it is supposed to do) Also Linux: again the OS itself is open source, but the Kernal at the heart, is not. Its developed based on feedback and suggestions but it's the Linux foundation that has final say.
