Originally posted by entropy
View Post
Announcement
Collapse
No announcement yet.
OpenGL ES 3.0 Will Be Here This Summer
Collapse
X
-
-
Originally posted by efikkan View PostOpenGL implementations for both Windows and Linux support multiple contexts and context sharing, like the features of Direct3D. The drivers are however single threaded so OpenGL has no disadvantage here. Some news was posted some time ago regarding an nVidia patent for multiple streams to the GPU, so this might show up in future generations (post Maxwell). Anyway, how is the lack of "proper" multithreading slowing down the performance of applications? Do you really think 8 CPU cores could boost the performance of your GPU? When executing calls to the GPU, either in OpenGL or Direct3D, there are two types of calls: load and render. Load calls are bandwidth limited, so multiple threads executing load calls would not help the performance. For a single viewport, multiple render threads would not help much either. Modern style, optimized SM4+ code should be GPU performance limited, so multiple threads would not give any speedup here. So you are thinking, I want one thread for rendering and one for loading. Ideally then your performance speedup would equal the amount of GPU idle time saved. Depending on usage, this might give around 10-20% theoretical speedup. But it has one condition, the data your loading thread are modifying cannot be in use by the rendering thread. However, GK110 and CUDA5 introduces direct streaming to the GPU without the CPU. Hopefully this would be included in future OpenCL specifications.
Comment
-
Originally posted by efikkan View PostOpenGL implementations for both Windows and Linux support multiple contexts and context sharing, like the features of Direct3D. The drivers are however single threaded so OpenGL has no disadvantage here. Some news was posted some time ago regarding an nVidia patent for multiple streams to the GPU, so this might show up in future generations (post Maxwell). Anyway, how is the lack of "proper" multithreading slowing down the performance of applications? Do you really think 8 CPU cores could boost the performance of your GPU? When executing calls to the GPU, either in OpenGL or Direct3D, there are two types of calls: load and render. Load calls are bandwidth limited, so multiple threads executing load calls would not help the performance. For a single viewport, multiple render threads would not help much either. Modern style, optimized SM4+ code should be GPU performance limited, so multiple threads would not give any speedup here. So you are thinking, I want one thread for rendering and one for loading. Ideally then your performance speedup would equal the amount of GPU idle time saved. Depending on usage, this might give around 10-20% theoretical speedup. But it has one condition, the data your loading thread are modifying cannot be in use by the rendering thread. However, GK110 and CUDA5 introduces direct streaming to the GPU without the CPU. Hopefully this would be included in future OpenCL specifications.
My technical knowledge concerning this topic is rather limited.
Nevertheless, this is what elanthis wrote in the forum.
Originally posted by elanthis View PostThe core code is likely identical in terms of acceleration.
The differences between GL and D3D for performance stem from GL's state model, the difficulty of threading it properly, and the extra checks that have to be run on many object uses because of the highly mutable object model. The latter at least is being slowly fixed with each successive version of GL (e.g., ARB_texture_storage), but has a long way to go. The threading problem cannot be fixed without literally scrapping and redesigning the API, as the fundamental problem is that the API expects and requires magic global hidden state (which can be thread-local, but that is not free), and in the short term requires scrapping and redesigning WGL and GLX (the changes from GL3 made it much better, but still far from perfect). The GL state model is just utter shit and needs to be shot in the face six times with a high-powered rifle; there's no fixing it, simply throwing it away and starting over. The API is simply trash, and even Khronos knows that fact (hence the Longs Peak fiasco). They just aren't willing to do anything about it; they introduce things like Core profile that break back-compat in little minor ways that barely affects anything at all while refusing to just introduce a revised API that breaks things in larger but actually useful ways.
The biggest problem with GL as an app developer is that -- on Windows -- the drivers are simply buggy and unstable. I still run into frequent driver crashes or just crazy performance problems that are simply bugs. The problems usually get fixed (though a few really bad long-term bugs haven't been fixed even after two years on NVIDIA's drivers) eventually, but the releases that fix one set of bugs inevitably just cause more.
Don't even get me started on what a horrifically bad shading language GLSL is, either. It's only just becoming sane with GLSL 4.20, which means you can't actually use any of its features since most of us need to target GL 3.1 hardware (Intel) or GL 3.2 operating systems (OS X) or just stick to GLSL|ES 2.0 (iOS, Android, NativeClient).
Comment
-
I have found, that in most cases games are not hitting a vram bandwidth bottleneck. This is relatively easy to check by overclocking the memory bus and checking the impact on the overall performance. Hint: check the relation between processing performance and memory bandwidth on the previous generation GPUs from nVidia.
BTW: To me the core profile could have been removed. There is no performance gain in it. One mobile profile(ES) and a full profile should be enough.Last edited by efikkan; 31 May 2012, 03:17 PM.
Comment
Comment