Announcement

Collapse
No announcement yet.

Next-Gen OpenGL To Be Announced Next Month

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by smitty3268 View Post
    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.

    Comment


    • #32
      Originally posted by curaga View Post
      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.

      Comment


      • #33
        Originally posted by Ancurio View Post
        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

        Comment


        • #34
          Originally posted by jrch2k8 View Post
          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.

          Comment


          • #35
            Originally posted by justmy2cents View Post
            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.
            Last edited by blackiwid; 07-16-2014, 12:24 PM.

            Comment


            • #36
              Originally posted by blackiwid View Post
              ...
              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.

              Comment


              • #37
                Originally posted by blackiwid View Post
                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

                Comment


                • #38
                  Originally posted by log0 View Post
                  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.

                  Comment


                  • #39
                    Originally posted by blackiwid View Post
                    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.

                    Comment


                    • #40
                      Originally posted by gamerk2 View Post
                      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?

                      Comment


                      • #41
                        Originally posted by johnc View Post
                        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?
                        Before you can work on a big project, you have to clear the workbench of junk.

                        Comment


                        • #42
                          Originally posted by blackiwid View Post
                          they could do both, if vendor = Nvidia : use better full opengl renderer else use minimal....
                          Not going to happen I think, at least not yet. The target market/platform is just too small, much smaller than Windows/Mantle. I am actually quite impressed that game devs are seriously starting to target Linux/OpenGL. I am not sure it is financially profitable for AAA games/publishers. I could be wrong of course, don't have the numbers.

                          Comment


                          • #43
                            Originally posted by gamerk2 View Post
                            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.
                            This isn't actually true. None of AAA engines use PSGL on PS3.
                            Might be some small casual games do, but most of other games doesn't.
                            Also PSGL it's just library on top of libgcm so...

                            Comment


                            • #44
                              Originally posted by johnc View Post
                              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?
                              I guess it matters for driver developers, but not for game developers. I think what they should do is make OGL5 simple and clean with low overhead, and then reimplement OGL 4.4 using OGL 5. This way hardware vendors will only need to focus on implementing the simpler OGL 5 and will get OGL 4.4 for free.

                              Comment


                              • #45
                                Originally posted by gamerk2 View Post
                                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,
                                And u have as many big companies as there different gpus are. And especialy if you mention intel and the big arm sockels, there would be trillions of people that would have big advantages if that garbage gpus would produce 20-30% better results. Ok here u have more the problem with extremly bad gpus at least thats true for intel with often very strong cpus so the mantle effect would not bring much.

                                But then their is the other dymention u say there are several generations who cares u start with the newest and never programm the support for the older cards, 5 years later nearly nobody has such old hardware and if so they have extremly bad driver support who cares. Its not the job of grafics companies to bring top notch driver support to 5 year old gpus.

                                And if u have for one generation nearly perfect drivers, and u start the support for the next generation, its way less expensive to maintain the support for the old gpus then implementing it initialy.

                                What have we today a new driver for each single game that comes out. there are less gpus than different games so I doubt that its so hard to do.

                                I heard this aargument (why consoles bring more fps per buck) years ago. And it was exactly that argument that there are to much different setups that such loiw level apis could not support, what have we today a api that supports Jaguar APUs with 128 shader-cores that cost 25 euro, even embeded 6W versions, ohh tablet even 3,5W versions... to 1200 euro grafic cards no matter how much ram u have no matter if u use harddisk or ssd no matter if what x86 cpu u combine it. The advantages differ, for some setups it even maybe gives no advantage, but it works on all, and if you combine your hardware not totaly stupid u gain big fps advantages.

                                btw arm and x86 gaming market has very few overlaps, they dont use opengl they use openal as primary api, that maybe could be a way between opengl garbage and mantle a middle way. But only if khronos would focus on gaming needs, they dont. So I dont see a api tahts designed for everything but gaming to suceed in the gaming market.

                                and its ok why not having opengl for ever as a api for maximum compatibility like "windows compatibility mode" and use mantle for the 1-2 newest gaming generations.

                                Its not that 100% of all games need every single fps it can get, there are so much games where driver effency doesnt be the big problem and only a few where there exist no or only a few cpus that are fast enough to bring good results.

                                all f2p games look like 5 year old games, of course because else only they would exclude 95% of the possible customers, but also on the buy to play side, take blizzard they have not one high-hardware needing game, or valve, same.

                                But if I upgrade a gaming rig, I dont want to buy every time when I upgrade my grafic card my cpu too, because this apis are so extremly bad that u need double the cpu cores for the same speed.

                                Comment

                                Working...
                                X