Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


wack

Member Since 02 May 2007
Offline Last Active Nov 25 2014 03:31 PM

Posts I've Made

In Topic: Next Generation OpenGL

21 August 2014 - 11:12 AM

I wouldn't have any issues with it happening as either of those two, but the ARB has done it the way I described in the past. All of the fixed function stuff was removed from OpenGL 3.1. There is an optional extension that includes all the old stuff. Which is supported by all hardware vendors that I know of, so in practice it meant nothing.

 

I find it hard to belive that the ARB would take the time to create an emulation layer. They can't even get their reference GLSL compiler straight. A lot of it I belive was written by Valve because they had a dire need for the functionality it does have. So who in the ARB would have a dire need to help write a compatibility layer? The most probable candidates would be the vendors themselves. However, already having the code in their existing driver, it would surprise me if they bother.

 

Nobody thinks it's sexy to fiddle with the old stuff, so my bet is that they'll chose the path of least resistance and implement compatibility the same way as they did in 3.1.


In Topic: Next Generation OpenGL

21 August 2014 - 10:39 AM

 

I don't really understand this point of view. Who/what is being dragged down in what way? If the old functionality isn't good enough for you then just don't use it?

 

In an ideal world this would be enough.

 

It's not an ideal world.  This isn't about the old functionality, it's about the old driver overhead, the old lack of threading support, the old "6 different ways to do the same thing and the fast path is different for each vendor" crap, the old GL extension hell, the old GLSL version hell.  Unfortunately we don't have a choice to not use these - current OpenGL forces them on us.

 

 

Well, you'll likely only get rid of the old stuff in theory anyways. All the vendors will need to provide drivers for older versions of OpenGL, otherwise people will be pissed that their favorite games and apps stopped working. They will most likely provide these in the same driver as the new stuff. They will most likely yet again introduce an official "compatibility" extension that implements all the old functionality and is optional in theory, but in practice will be implemented by all, since they have to ship it with their driver anyways.

 

edit: The point being that if you are finding this difficult today, it's about to get even more difficult.


In Topic: Next Generation OpenGL

21 August 2014 - 09:35 AM

The Siggraph 2014 slides have been released; pdf here

Of particular note is page 72;
 

- compatibility break with OpenGL
- start from first principles

- clean modern arch
- multi-thread/core friendly
- greatly reduced cpu overhead
- arch neutral - support for tile-based as well as direct renderers
- predictable performance
- improved reliability and consistency between implementations

- explicit control - app tells driver what it wants


The first point is the most important for me; breaking GL compat means it won't be dragged down by legacy so yay!

 

 

I don't really understand this point of view. Who/what is being dragged down in what way? If the old functionality isn't good enough for you then just don't use it?


In Topic: Does this have potential?

14 August 2014 - 03:48 PM

That actually looks pretty damn sweet.

In Topic: Next Generation OpenGL

14 August 2014 - 10:13 AM

You should never forget that Khronos is a committee of committees.  As such, anything it produces is going to have all the hallmarks of something designed by committee.  Mostly, it will never leave you without something to complain about.


There will be lots of complaints and whining afterwards. Not all because of Khronos, though. A lot of people seem to have some very odd/impractical hopes and expectations about this.

PARTNERS