Jump to content

View more

Image of the Day

New ninja for my game.
#screenshotsaturday #gamedev #indiedev #IndieDevHour
https://t.co/sJdnPuiVgh
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net's newsletters to receive the latest updates and exclusive content.


Sign up now

Vulkan is Next-Gen OpenGL

2: Adsense
  • You cannot reply to this topic
499 replies to this topic

#21 swiftcoder   Senior Moderators   

18098
Like
1Likes
Like

Posted 03 March 2015 - 11:52 AM

Not on tablet/phone hardware they don't.

I'm not sure that Microsoft-based phones and tablets represent a credible enough install-base to be worried about.

 

More interesting to see if Apple will let this in the door to iOS - without that chunk of the mobile market, you'll be stuck supporting Vulcan and Metal for the foreseeable future.


Tristam MacDonald - Software Engineer @ Amazon - [swiftcoding] [GitHub]


#22 TheChubu   Members   

9304
Like
0Likes
Like

Posted 03 March 2015 - 11:52 AM

I've been thinking, maybe they'll expose OpenGL extensions to handle the SPIRV intermediate language...


"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator


#23 cozzie   Members   

4931
Like
0Likes
Like

Posted 03 March 2015 - 01:30 PM

Any idea how vulkan will be "deviding" the support for lots of different devices?
Meaning that you don't have a disadvantage when developing for current gen consoles/pc versus a gui for a washing machine.

Crealysm game & engine development: http://www.crealysm.com

Looking for a passionate, disciplined and structured producer? PM me


#24 Promit   Senior Moderators   

12940
Like
4Likes
Like

Posted 03 March 2015 - 02:10 PM

AMD published a new release: http://community.amd.com/community/amd-blogs/amd-gaming/blog/2015/03/03/one-of-mantles-futures-vulkan

The main point being that Vulkan is essentially an iterated cross platform version of Mantle. I like that AMD was willing to describe their own press release hours earlier as cryptic.


SlimDX | Shark Eaters for iOS | Ventspace Blog | Twitter | Proud supporter of diversity and inclusiveness in game development

#25 mrhyperpenguin   Members   

467
Like
0Likes
Like

Posted 03 March 2015 - 02:18 PM

 

and not sure how Microsoft will cooperate (DX12 still not available).


Why would MS have to do anything?
They don't support OpenGL, Mantle, OpenCL and CUDA and yet they all work just fine... this is no different.

 

 

I was trying to bring up the fact that some people believe that Microsoft sabotaged the OpenGL implementation on Windows to increase DirectX adoption. And whether Microsoft will allow Vulkan and Mantle to be first-class citizens with DX12 (if it's even possible) and whether Microsoft will keep their open-source friendly ways up (like Promit mentioned).

 

IIRC, Apple has to explicitly allow support for new APIs because they write their own drivers. So "it just works" isn't always possible.



#26 mhagain   Members   

13012
Like
1Likes
Like

Posted 03 March 2015 - 02:31 PM

I was trying to bring up the fact that some people believe that Microsoft sabotaged the OpenGL implementation on Windows to increase DirectX adoption. And whether Microsoft will allow Vulkan and Mantle to be first-class citizens with DX12 (if it's even possible) and whether Microsoft will keep their open-source friendly ways up (like Promit mentioned).

 

IIRC, Apple has to explicitly allow support for new APIs because they write their own drivers. So "it just works" isn't always possible.

 

The story I heard was that the Windows NT team had OpenGL because they wanted to break into the CAD workstation market.  The Windows 95 team wanted OpenGL for games, the NT team wouldn't play ball, and hence DirectX (or more specifically Direct3D because DirectX already existed) was born.  If that was the case, any sabotage was internal.  If you've ever had to deal with Microsoft in a professional capacity that's perfectly believable.

 

As for open-source friendliness, it hardly seems relevant; it was never the case that OpenGL was open-source (it's not even software so it can't be).


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#27 phantom   Members   

11195
Like
3Likes
Like

Posted 03 March 2015 - 02:47 PM

I was trying to bring up the fact that some people believe that Microsoft sabotaged the OpenGL implementation on Windows to increase DirectX adoption.


Yes, people do enjoy painting MS as the 'big bad' in all of this when, truth be told, 99% of OpenGL's problems were caused by ARB infighting and incompetence (see GL2.0 and Longs Peak/GL3.0) - the worst MS ever did was fix their software version back on GL1.1 and not ship GL drivers/dlls via Windows update for updated graphics drivers (which is a pain, but given they don't test that component I can see why), but they never actively sabotaged things.
(btw, if your source for this was the Wolfire blog from some time back then... well, forget you read it, it was trash frankly.)

The biggest tell in all of this is the utter amazement which has been expressed by many long time graphics programmers that Valkan seems, well, sane and well thought out.. I think many of us are still waiting for the other shoe to drop and won't be 100% convinced until we have working drivers in our hands to play with/test.

#28 Zlodo   Members   

642
Like
0Likes
Like

Posted 03 March 2015 - 03:28 PM

 

I was trying to bring up the fact that some people believe that Microsoft sabotaged the OpenGL implementation on Windows to increase DirectX adoption.


Yes, people do enjoy painting MS as the 'big bad' in all of this when, truth be told, 99% of OpenGL's problems were caused by ARB infighting and incompetence (see GL2.0 and Longs Peak/GL3.0) - the worst MS ever did was fix their software version back on GL1.1 and not ship GL drivers/dlls via Windows update for updated graphics drivers (which is a pain, but given they don't test that component I can see why), but they never actively sabotaged things.

 

https://www.opengl.org/archives/about/arb/meeting_notes/

Go dig in there and see for yourself what Microsoft was doing back when they were part of the ARB.

 

For instance:

 

March 5, 2002
 
ARB_vertex_program:
"Microsoft wanted to alleviate concerns about their statement last week regarding possible claims on vertex program IP. Dave Aronson apologized for the perception that they aren't acting in good faith. They are trying to follow ARB regulations about stating IP as much as possible. When a vote was imminent, they reviewed and felt that they had patents or patents pending covering vertex programming. They do plan on coming up with licensing terms, and have set a hard deadline for themselves of 2 weeks before the June ARB meeting."
 
June 18, 2002
 
ARB_vertex_program:
"Microsoft believes they have patent rights relating to the ARB_vertex_program extension. They did not contribute to the extension, but are trying to be upfront about it. They're offering to license their IP under reasonable and nondiscriminatory terms; will license rights to the extent necessary, provided a reciprocal license is granted to MS. Granted on 1:1 basis for OpenGL 1.3, 1.4, and earlier versions. Contact Dave Aronson for more specifics. Suzy asked Dave to circulate his statement to the participants' list."
 
ARB_fragment_program:
"Microsoft does believe they have IP claims against fragment shaders, too."
"Bill asked about Microsoft's IP position on just the program management framework; Dave was unable to comment at this point."
"Suzy asked Microsoft to figure out their IP claims, if any, against just the program management stuff."
 
September 18, 2002
 
ARB_fragment_program:
"Microsoft noted their previously mentioned IP claim. They were asked if they could be at all more specific as to what their claim was, and will follow up with their lawyers to determine this."


#29 Promit   Senior Moderators   

12940
Like
5Likes
Like

Posted 03 March 2015 - 03:59 PM

*
POPULAR

There's nothing even vaguely unusual or improprietous about those excerpts. It's somewhat reflective of the standard internal MS dysfunction that has afflicted them for many years, but it's certainly not misconduct.


Edited by Promit, 03 March 2015 - 04:01 PM.

SlimDX | Shark Eaters for iOS | Ventspace Blog | Twitter | Proud supporter of diversity and inclusiveness in game development

#30 phantom   Members   

11195
Like
5Likes
Like

Posted 03 March 2015 - 04:06 PM

*
POPULAR

Asserting rights to IP is not sabotage; if it was then the same claim can be levelled at others in the group too over their various IP claims over the years. Hell, S3 caused issues with their texture compression IP claims.

Btw, MS left the ARB in March of the following year; it has taken 12 years for the rest of them to stop messing up with the following years being series of mistakes, missteps, bad choices and back tracking.
(Years, btw, that I lived as an OpenGL programmer, one time moderator of this sub-form, vocal GL advocate vs DX9, and GLSL chapter author for More OpenGL Game Programming... so, I know a thing or two about the history ;))

All of this is of course horribly off topic so should probably stop...

#31 mhagain   Members   

13012
Like
6Likes
Like

Posted 03 March 2015 - 04:41 PM

*
POPULAR

Yes, it probably should stop, but two more points are relevant.

 

First one is the evidence being that the worst damage was done to OpenGL after Microsoft's departure.  I'm talking about 2.0 and Longs Peak here.  That's relevant because they represent the previous two times that the ARB had tried, and failed, to redesign a modernized OpenGL.

 

Second one is the story of ARB_occlusion_query.  The story is here but in summary: it's odd that QUERY_COUNTER_BITS_ARB was allowed to be 0, and it turns out that the reason why was so that Intel could advertise support for the extension but without actually having to really support it.  That's a classic example of the kind of madness that infected OpenGL's evolution (and note that Microsoft weren't involved here either) and it's exactly the kind of thing we'd like to see avoided in Vulkan.

 

I remain cautiously optimistic; it's quite notable that there is a significant number of game developers on the board this time around, rather than just hardware technicians, so the resulting API will at least stand a better chance of being something that matches well with what the people who are going to be using it actually want.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#32 Joshhua5   Members   

1358
Like
1Likes
Like

Posted 03 March 2015 - 07:40 PM

I really hope this lives upto it's expectation. I'd love to adopt this asap, also all this OGL history is rather facinating to read.



#33 SeanMiddleditch   Members   

17445
Like
5Likes
Like

Posted 03 March 2015 - 08:14 PM

*
POPULAR

I've been thinking, maybe they'll expose OpenGL extensions to handle the SPIRV intermediate language...


Almost a certainty. I don't see OpenGL development stopping any time soon. NVIDIA has already announced extensions for command buffers in GL, for instance. SPIRV support is almost a certainty especially since OpenCL will now require it anyway.

Remember, Vulkan is going to be a huge pain in the ass compared to GL. The Vulkan API is _much_ cleaner, yes, but it also eschews all the hand-holding and conveniences of GL and forces you to manage all kinds of hardware state and resource migration manually. Vulkan does not _replace_ OpenGL; it simply provides yet another alternative.

The same is true in Microsoft land: D3D11.3 is being released alongside D3D12, bringing the new hardware features to the older API because the newer API is significantly more complicated to use due to the greatly thinner abstractions; it's expected that the average non-AAA developer will want to stick with the older, easier APIs.

Game Developer, C++ Geek, Dragon Slayer - http://seanmiddleditch.com

C++ SG14 "Games & Low Latency" - Co-chair - public forums

Wargaming Seattle - Lead Server Engineer - We're hiring!


#34 Matias Goldberg   Members   

9393
Like
0Likes
Like

Posted 03 March 2015 - 11:03 PM

Remember, Vulkan is going to be a huge pain in the ass compared to GL. The Vulkan API is _much_ cleaner, yes, but it also eschews all the hand-holding and conveniences of GL and forces you to manage all kinds of hardware state and resource migration manually. Vulkan does not _replace_ OpenGL; it simply provides yet another alternative.

The same is true in Microsoft land: D3D11.3 is being released alongside D3D12, bringing the new hardware features to the older API because the newer API is significantly more complicated to use due to the greatly thinner abstractions; it's expected that the average non-AAA developer will want to stick with the older, easier APIs.

THIS. A lot of people don't seem to get these are very low level APIs with a focus on raw memory manipulation and baking of objects/commands that are needed very frequently. You destroyed a texture while it was still in use? BAM! Graphics corruption (or worse, BSOD). You wrote to a constant buffer while it was still in use? Let the random jumping of objects begin! You manipulated the driver buffers and had an off-by-1 error? BAM! Crash or BSOD. Your shader has a loop and is reading the count from unitialized memory? BAM! TDR kicks in or system becomes highly unresponsive.
You need to change certain states more frequently than you thought? Too bad, turns out you need to make some architectural modifications to do what you want efficiently.

It's hard. But I love it, with great power comes great responsability. None of this is a show-stopper for people used to low level programming. But it is certainly not newbie friendly like D3D11 or GL were (if you considered those newbie friendly). Anyway, a lot of people learned hardcore programming back in the DOS days when it was a wild west. So may be this is a good thing.

Edited by Matias Goldberg, 03 March 2015 - 11:06 PM.


#35 Ashaman73   Members   

13708
Like
1Likes
Like

Posted 03 March 2015 - 11:48 PM


Remember, Vulkan is going to be a huge pain in the ass compared to GL. The Vulkan API is _much_ cleaner, yes, but it also eschews all the hand-holding and conveniences of GL and forces you to manage all kinds of hardware state and resource migration manually. Vulkan does not _replace_ OpenGL; it simply provides yet another alternative.

I started my engine with OGL1.2 and being at OGL2.1 + extensions now,I have removed a lot of this convenience OGL over time. I'm currently at the state of handling many things by buffers and in the application itself and that with OGL2.1 (allocate buffer, manage double/triple buffering yourself, handling buffer sync yourself etc.). Most likely I use only a few % of the API at all. I think that a modern OGL architecture (AZDO, using buffers everywhere including UBOs etc) will be close to what you could expect from vulkan and that if they expose some vulkan features as extensions (command buffer), then switching over to vulkan will not be a pain in the ass.


Edited by Ashaman73, 03 March 2015 - 11:55 PM.

Ashaman

 

Gnoblins: Website - Facebook - Twitter - Youtube - Steam Greenlit - IndieDB - Gamedev Log


#36 Ashaman73   Members   

13708
Like
0Likes
Like

Posted 04 March 2015 - 12:01 AM


THIS. A lot of people don't seem to get these are very low level APIs with a focus on raw memory manipulation and baking of objects/commands that are needed very frequently. You destroyed a texture while it was still in use?

Come on, time has changed. Current game engines uses multithreading and multithreading is one of the best ways to kill your game project, still people are able to code games smile.png And as game-dev you just can't take all the easy to use OS multithreading support features (mutex, critical sections, synchronise language features etc.).

For rookie coders there will be still comfortable libs around and for professional coders this should not be a problem (thought some headache might be included). On the other hand, the other modern APIs will not take this burden from the developers too.


Edited by Ashaman73, 04 March 2015 - 12:05 AM.

Ashaman

 

Gnoblins: Website - Facebook - Twitter - Youtube - Steam Greenlit - IndieDB - Gamedev Log


#37 Matias Goldberg   Members   

9393
Like
4Likes
Like

Posted 04 March 2015 - 08:57 AM

THIS. A lot of people don't seem to get these are very low level APIs with a focus on raw memory manipulation and baking of objects/commands that are needed very frequently. You destroyed a texture while it was still in use?

Come on, time has changed. Current game engines uses multithreading and multithreading is one of the best ways to kill your game project, still people are able to code games smile.png

It's not really the same. Multithreading problems can be debugged and there's a lot of literature and tools to understand them.
It's much harder to debug a problem that locks up your entire system every time you try to analyze it.
 

I'm currently at the state of handling many things by buffers and in the application itself and that with OGL2.1 (allocate buffer, manage double/triple buffering yourself, handling buffer sync yourself etc.). Most likely I use only a few % of the API at all. I think that a modern OGL architecture (AZDO, using buffers everywhere including UBOs etc) will be close to what you could expect from vulkan and that if they expose some vulkan features as extensions (command buffer), then switching over to vulkan will not be a pain in the ass.

If you're already doing AZDO with explicit synchronization then you will find these new APIs pleasing indeed. However there are breaking changes like how textures are being loaded and bound. Since there's no hazard tracking, you can't issue a draw call that uses a texture until the it is actually in GPU memory. Drivers were also handling residency for you, but since now they don't, out of GPU errors can be much more common unless you write your own residency solution. Also how textures are bound is going to change.
Then, in the case of D3D12, there's PSOs, which fortunately you should be already emulating them for forward compatibility.

Indeed, professional developers won't have much problems; whatever annoyance they may have is obliterated by the happiness from the performance gains. I'm talking from a rookie perspective.

Edited by Matias Goldberg, 04 March 2015 - 08:59 AM.


#38 vlj   Members   

1070
Like
0Likes
Like

Posted 04 March 2015 - 11:49 AM

Hopefully Vulkan "drivers" won't exclude each other so that concurrently using gpus from multiple vendors is possible.

I even wonder how feasible it would be to use igpu (since they are common) for coarse depth rasterization for occlusion culling instead of course.


Hopefully Vulkan could also be used to write an opengl implementation on top of it. With such a standard implementation a lot of non conformity troubles would come to an end.

#39 Boreal   Members   

1676
Like
1Likes
Like

Posted 04 March 2015 - 08:51 PM

I'd be excited to see the possibilities of using an HSA chip (APU) for compute and leaving the dedicated GPU for graphics.  Hopefully with AMD having a big stake in Vulkan and OpenCL 2.1 this will be possible.


"So there you have it, ladies and gentlemen: the only API I’ve ever used that requires both elevated privileges and a dedicated user thread just to copy a block of structures from the kernel to the user." - Casey Muratori

 

boreal.aggydaggy.com


#40 Hodgman   Moderators   

50325
Like
1Likes
Like

Posted 04 March 2015 - 09:39 PM

Explicit multi-device capabilities should be a standard part of all these next-gen APIs. Allowing dev's to implement SLI/Crossfire style Alternate Frame Rendering, split frame rendering, or other kind of workload splits, such as moving shadows or post-processing to another GPU, with the developer in control of synchronization and cross-GPU data transfers.

It also opens up the ability for one device to be used for graphics and another purely for compute, with different latencies on each device.

 

If Vulkan doesn't support this, I'll be quite surprised.