Next-Gen OpenGL To Be Announced Next Month

[curaga]

Newer hardware implements virtual memory, and the hardware provides validation to make sure your app doesn't get access to something it shouldn't be able to see. Crashes can happen, though.

Virtual memory doesn't help much when there is no zeroing. Allocate a huge texture without initializing it, read from it -> very high probability of seeing old window contents.

[log0]

Virtual memory doesn't help much when there is no zeroing. Allocate a huge texture without initializing it, read from it -> very high probability of seeing old window contents.

Just curious, is there a high probability? I would have expected that frame buffers are reused for frame buffering. But then there is composition and stuff of course.

The issue with zeroing is already there, independent of whether you have vm or not, I think.

[jrch2k8]

Can't you do that kind of stuff with decoding texture image data directly to mapped PBOs and then uploading from that?

well i guess you can but nvidia extensions for buffer storage seems to be more efficient or at least is more direct and easy to use

[gamerk2]

Problem is not that the drivers are sending millions of additional opcodes and trashing the command dispatchers or not using certain uber optimised paths or nothing like that.

The actual problem is hardware bandwidth/latency even if PCIe is really fast is not that fast so every upload to GPU ram is gonna hurt a lot, so the efficiency focus is a standard way to remove the upload process as much as possible and keep data inside the GPU ram as much as is possible to save PCIe trips to the CPU and backwards, ofc this will increase GPU ram usage(you can't have both ways) and start up times(you have to upload more data to avoid multiple/serial uploads), for example:

Current OpenGL/DX game: upload TextureA, wait for upload(hurts and hurts and hurts), process, Upload TextureB, wait for upload(hurts and hurts and hurts), process,render.

Next Gen OpenGL/DX game: upload TextureA,B,C,N... to buffersA,B,C,N ...(<-- only once per scene), reference buffer A, process, reference buffer B, process, render

Of course many more factors need to work that way, the example is just a very bastardised way to show part of the problem

If that were the case, them you'd see a performance increase going from PCI-e v2 to PCI-e v32, which you don't. Hell, even PCI-e 1.1 x16 is enough for a single mid-range GPU. PCI-e bandwidth is NOT a problem.

[blackiwid]

i might be wrong here, but zero-overhead on GL was presented with up to 4.4 extensions. only problem is that only nvidia did their work and actually made them perform as they should.

Sorry I dont fall for that propaganda, they only showed some theoretical benchmarks no game is with nvidia hardware only close as much faster then this games are that support mantle.

So even if they would have fixed opengl to matle level, its very strange that many companies implement a complete new api (mantle) to make games for the minor grafic cards vendor faster, than making some opengl tunings for the major grafic card seller with the bigger market share.

So either opengl is such a garbage such tuning would be harder than supporting a second api, or nvidia is full of crap. I bet on the second one.

Correction:

Ok I forgot 99.98999999999% of all games are made in directx and not opengl, so in both cases they have to support another engine, but still we have not seen any major advantages of the nvidia opengl implementation in not ONE real game, but we have seen big advantages with mantle in several games... it looks even the next gta version a game many people will buy and is ideal for such optimations (open world high cpu load) will support mantle.

[log0]

...
Ok I forgot 99.98999999999% of all games are made in directx and not opengl, so in both cases they have to support another engine, but still we have not seen any major advantages of the nvidia opengl implementation in not ONE real game, but we have seen big advantages with mantle in several games... it looks even the next gta version a game many people will buy and is ideal for such optimations (open world high cpu load) will support mantle.

The games using those extensions would be targeting SteamOS/Linux. Unfortunately they have to code for the baseline, which would be Intel/Mesa with GL3.3?. So you wont see games using AZDO stuff for some time I guess.

[jrch2k8]

Sorry I dont fall for that propaganda, they only showed some theoretical benchmarks no game is with nvidia hardware only close as much faster then this games are that support mantle.

So even if they would have fixed opengl to matle level, its very strange that many companies implement a complete new api (mantle) to make games for the minor grafic cards vendor faster, than making some opengl tunings for the major grafic card seller with the bigger market share.

So either opengl is such a garbage such tuning would be harder than supporting a second api, or nvidia is full of crap. I bet on the second one.

Correction:

Ok I forgot 99.98999999999% of all games are made in directx and not opengl, so in both cases they have to support another engine, but still we have not seen any major advantages of the nvidia opengl implementation in not ONE real game, but we have seen big advantages with mantle in several games... it looks even the next gta version a game many people will buy and is ideal for such optimations (open world high cpu load) will support mantle.

is not so simplistic as you wanna make it look, you can't have both ways(safe and super fast) without consequence and second you don't seem to understand what mantle is either or why is completely unrelated the specific language specification(OpenGL Next or DX12) in the performance optimisation process currently on work.

to make it more simple to understand DirectX and OpenGL today are the equivalent of C# in the CPU world aka is safe to use and protect you up to certain degree from many conceptual mistakes at the expense of a performance hit but on the other hand Mantle/Metal are equivalent to ISO C 99 aka you can squeeze more performance but you need to know what you are doing or all hell will break loose. OpenGL next and DX12 would be an equivalent of finding a middle point like C++11 aka performs very close to ISO C and still offer some protections at the expense of more expertise on the developer shoulder.

please note there are other factors at play here beyond the specification itself, for example Metal is not 10x faster than OpenGL ES like apple wanna show but 10x faster than the driver OpenGL ES implementation(as we all know ARM drivers are trash) and the same can be said of AMD proprietary drivers

Of course there are other factors like new extensions(that don't necessarily require new silicon) that apply advanced techniques to solve old problems(due to hardware limitations in previous generations) that end been more complex to use but perform better in newer hardware

[blackiwid]

The games using those extensions would be targeting SteamOS/Linux. Unfortunately they have to code for the baseline, which would be Intel/Mesa with GL3.3?. So you wont see games using AZDO stuff for some time I guess.

they could do both, if vendor = Nvidia : use better full opengl renderer else use minimal.

The Point is they do that for newer amd cards and even using a completly different api so there is no reason they would not do that for nvidia if nvidias better opengl would be so fast like mantle is.

and yes maybe mantle is more like C so what who cares. For Konsoles they use also matle like apis, so why do they need a higher level api when they port their konsole games to the pc.

ok u could argue because there are more different hardware combinations, but steam only is gpu dependend the api doesnt care which cpu it uses if u have 1000 euro cpu it doesnt hurt, the worse cpu u have the better more or less.

So its not about different combinations, its about what grafics card u have. its just retarded that companies think they can vaste by total incompetence 30% or more of the hardware of millions of customers to save them here and there a few 100 hours worktime.

they even cause global warming with that antisozial behaviour because people buy higher clocked cpus that waste 50watt more all the time, and several power plant run only because of taht reason.

its btw also not a thing that should happen in a healthy market, competition should punish such behaviour. But it seems a bit that happens thanx to amd with mantle.

[gamerk2]

they could do both, if vendor = Nvidia : use better full opengl renderer else use minimal.

The Point is they do that for newer amd cards and even using a completly different api so there is no reason they would not do that for nvidia if nvidias better opengl would be so fast like mantle is.

and yes maybe mantle is more like C so what who cares. For Konsoles they use also matle like apis, so why do they need a higher level api when they port their konsole games to the pc.

ok u could argue because there are more different hardware combinations, but steam only is gpu dependend the api doesnt care which cpu it uses if u have 1000 euro cpu it doesnt hurt, the worse cpu u have the better more or less.

So its not about different combinations, its about what grafics card u have. its just retarded that companies think they can vaste by total incompetence 30% or more of the hardware of millions of customers to save them here and there a few 100 hours worktime.

they even cause global warming with that antisozial behaviour because people buy higher clocked cpus that waste 50watt more all the time, and several power plant run only because of taht reason.

its btw also not a thing that should happen in a healthy market, competition should punish such behaviour. But it seems a bit that happens thanx to amd with mantle.

Higher level API's save a lot more then a few hundred hours. Remember how many different generations of GPUs are still out there. You have Intel IGPs, two different AMD GPU architectures (VLIW4 And GCN), several NVIDIA architectures, not to mention Qualcomm and PowerVR chips to consider. And each has a totally different HW backend. You can't target them all at a low level; you HAVE to use a higher level API that they all support. And this costs performance. Mantle, by targeting ONLY GCN, gets around this, but essentially ties AMD to a specific architecture going forward, which will be a problem 5-6 years from now when GCN looks downright ancient.

Secondly, the Xbox line in particular doesn't have a low level graphics API, it only uses a slimmed down version of DX. The PS3/PS4 has a low level libgcm library, which is used a lot, but even then, a lot of the higher order control is done via PSGL (Essentially, OpenGL ES 2.0) for simplicities sake.

Thirdly, the problem with OpenGL isn't its performance; optimized OGL could likely match Mantle. The problem is the API is a bloody mess, hard to implement the entire API correctly in HW, and a PITA to code in and debug compared to DX. No one likes it, and now that some are saying "Use OGL", the Devs are saying "NO!!!!", and for good reason. Khronos has one last shot to save the API, and they can do it by removing all the legacy cruft and redesigning it from scratch in OGL5.

[johnc]

Thirdly, the problem with OpenGL isn't its performance; optimized OGL could likely match Mantle. The problem is the API is a bloody mess, hard to implement the entire API correctly in HW, and a PITA to code in and debug compared to DX. No one likes it, and now that some are saying "Use OGL", the Devs are saying "NO!!!!", and for good reason. Khronos has one last shot to save the API, and they can do it by removing all the legacy cruft and redesigning it from scratch in OGL5.

Just out of curiosity, from a developer's perspective, what does the "legacy cruft" matter? Other than running into outdated documentation on the web, when would developers ever encounter it?