tag:blogger.com,1999:blog-7395797351911594965.post3875224950012043481..comments2024-03-24T23:19:53.674-07:00Comments on Richard Geldreich's Blog: Things that drive me nuts about OpenGLRich Geldreichhttp://www.blogger.com/profile/14358203173986928600noreply@blogger.comBlogger47125tag:blogger.com,1999:blog-7395797351911594965.post-60020000317372583262016-09-11T14:59:48.082-07:002016-09-11T14:59:48.082-07:00Did you turn on GL debug contexts and error loggin...Did you turn on GL debug contexts and error logging? Also, have you tried Renderdoc to debug the problem?Rich Geldreichhttps://www.blogger.com/profile/14358203173986928600noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-43421578530454301582016-09-11T14:55:58.613-07:002016-09-11T14:55:58.613-07:00I was trying to port my game from SDL's bad an...I was trying to port my game from SDL's bad and slow immediate mode to more optimized vertexArrays and VBO but gave up after a few days working on it. OpenGL is just retardedly, uselessly complicated for doing simple things.Anonymoushttps://www.blogger.com/profile/10410130959685097190noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-57070277339259002522014-06-05T03:58:48.794-07:002014-06-05T03:58:48.794-07:00I think OpenGL definitely needs a big reboot.
Wha...I think OpenGL definitely needs a big reboot.<br /><br />What I'd really like to see is a migration of OpenGL code to OpenCL; i.e - you write your renderer in a form of OpenCL using OpenGL calls, and the whole thing then runs on the GPU, leaving your program to just send updates or queries (depending upon what you want to get out of it).<br /><br />If this were to happen, we could get a clean OpenGL within an OpenCL based API, but keep older OpenGL calls for legacy applications (or people who hate change), and map them onto a default OpenCL program. By basing things within OpenCL in this way, we shouldn't even need much in the way of driver support at all as all of the actual OpenGL calls would be taking place on the GPU itself (so firmware supported) while the driver just needs to support loading the renderer and passing messages (though granted, some of these would necessarily need to contain content, but that should be a lot easier for driver vendors to optimise).<br /><br />Do something like that and OpenGL could potentially leap well ahead of Mantle and DirectX12 and finally be something that's a privilege to use, rather than something you only feel you should use because it's open, or you are forced to use because your target platform doesn't support anything else.Haravikkhttps://www.blogger.com/profile/13980601770275278143noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-13819343467815575732014-06-05T03:58:42.328-07:002014-06-05T03:58:42.328-07:00This comment has been removed by the author.Haravikkhttps://www.blogger.com/profile/13980601770275278143noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-75972866808252117672014-06-05T03:58:34.767-07:002014-06-05T03:58:34.767-07:00This comment has been removed by the author.Haravikkhttps://www.blogger.com/profile/13980601770275278143noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-85621568555297512832014-06-05T03:58:28.493-07:002014-06-05T03:58:28.493-07:00This comment has been removed by the author.Haravikkhttps://www.blogger.com/profile/13980601770275278143noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-2693144430134347362014-05-29T11:01:45.738-07:002014-05-29T11:01:45.738-07:00OpenGL already tried a reboot with OpenGL 3.1, and...OpenGL already tried a reboot with OpenGL 3.1, and people are STILL whining about how bad the removed features were, and it also caused point 19. A second reboot is probably not going to help anything.<br /><br />A completely new, redesigned API would be cool, but would require massive vendor buy-in to be useful, which I doubt will happen anytime soon.Anonymoushttps://www.blogger.com/profile/13611666306412990031noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-55842490887683605072014-05-15T09:57:32.784-07:002014-05-15T09:57:32.784-07:00Also Vendor B and C open source drivers dev teams ...Also Vendor B and C open source drivers dev teams went for "ONLY CORE" option for OpenGL 3.2 and up. From their perspective that is masive simplification of driver developemnt, saves tone of time, and allow focusing on futureproof stuff.Przemysław Libhttps://www.blogger.com/profile/17702180780709981763noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-35470618371921533862014-05-14T19:57:40.339-07:002014-05-14T19:57:40.339-07:00That was the plan with OpenGL "longs peak&quo...That was the plan with OpenGL "longs peak". They caved to pressure at the last minute and put backwards compatibility back in... :-(Action Man (the greatest hero of them all)https://www.blogger.com/profile/15877869348913002367noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-65928113139495809832014-05-14T19:51:26.405-07:002014-05-14T19:51:26.405-07:00Mantle is definitely designed as a cross-platform ...Mantle is definitely designed as a cross-platform and cross-vendor API, using a GL-like extension mechanism (but better, of course).<br /><br />But: It isn't even out yet; so it's silly to point at it not working on Linux yet and claiming that it's damned to a life of MS chains!<br /><br />It's still undergoing initial development by AMD and a small group of industry partners before it's officially released. Some of those partners have shipped Mantle support on Windows as part of that process... but if you or me want to use it right now, we have to wait until the actual release.Action Man (the greatest hero of them all)https://www.blogger.com/profile/15877869348913002367noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-18253797111936101722014-05-14T08:00:22.617-07:002014-05-14T08:00:22.617-07:00AMD was still evaluating the feasibility at that t...AMD was still evaluating the feasibility at that time and indeed it seems to be a ressource problem for them. <br /><br />http://www.phoronix.com/scan.php?page=news_item&px=MTY0MDM<br /><br />But that is a problem which can be overcome if other vendors or Khronos chose to adopt Mantle and put more effort behind it. As Mantle is said to be relatively close to Sony's PS4-API such a rumored "GameGL" and Mantle could have much in common.Marcus Seyfarth, LL.M.https://www.blogger.com/profile/17471096252814217981noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-8086623643586156192014-05-14T07:26:43.125-07:002014-05-14T07:26:43.125-07:00I concur with Joshua. It also reflects Joan Anders...I concur with Joshua. It also reflects Joan Andersson's vision of spreading Mantle on other vendors / devices / operating systems. He stated that the abstraction in Mantle would be high enough to enable vendor specific things through extensions, hence Nvidia and Intel could adopt it if they chose to. That's a big IF of course, but it would bring additonal value to ISV's, IHV's and the whole ecosystem alike (e.g. like a leaner development and support process). And that's what standardization is meant to achieve in the first place!Marcus Seyfarth, LL.M.https://www.blogger.com/profile/17471096252814217981noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-75921904315197960242014-05-13T13:49:57.226-07:002014-05-13T13:49:57.226-07:00There are a ton of reasons why having a GL conform...There are a ton of reasons why having a GL conformance test would be totally awesome and solve a lot of the real problems of GL dev...<br />- It's something the community can collaborate in - easily open sourced and scalable. Centralization is not needed - the spec is already centralized.<br />- IHVs are clearly playing the 80-20 rule with the matrix of possible GL interactions (and none of us can blame them, especially if we're calling for a smaller API). Conformance test results would give developers insight into what was considered heavily tested or reliable.<br />- IF backward compatibility is really a cost driver for IHVs, a conformance test would make it apparent - test count would be a good proxy for how much weird stuff compatibility is inducing.<br />- App developers could protect correct functionality of their code by building off well-tested cases in the conformance test.<br /><br />Benjamin Supnikhttps://www.blogger.com/profile/04886313844644521178noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-38850581017221423202014-05-13T11:35:14.672-07:002014-05-13T11:35:14.672-07:00Yes, no, not really.
The ES versions are designe...Yes, no, not really. <br /><br />The ES versions are designed for embedded systems which typically are lower resource processors typically found in non-desktop applications. Non desktop GPU vendors like ARM (Mali), Samsung (Exynos), Qualcomm (Snapdragon/Imageon), and Imagination Technology (PowerVR) have very little interest in designing graphics processors that have the throughput or rendering capabilities of a desktop gpu. Even Intel isn't all that interested, but the push into GPGPU and parallelization (OpenCL) has had the unintended backwards effect of forcing Intel to design architectures that are at least decent for graphics functions. <br /><br />Given that the majority of vendors designing chips and drivers around OpenGL ES are not interested in traditional gaming applications, extending that specification would likely draw no real adoption... <br /><br />There also is the issue that recent updates to OpenGL 4.x have ensured that the current OpenGL ES functions are a full subset of the 4.x specification... Simply adding extensions into OpenGL ES turns it back into something resembling full OpenGL... <br /><br />Then there is the issue, as noted by Rich, that Nvidia *LOVES* to use non-core profile extensions. I call it code-level sabotage; the most infamous to date possibly being Nvidia's Ultra-Shadow techniques. Given the amount of trouble caused by OpenGL accelerators outside the core profile as is... one can only imagine the heartache that would be generated by more and more vendor-specific OpenGL ES extensions... which already *ARE* a problem. <br /><br />To quote myself in regards to the solution, and in respect to AMD and EA's mantle: <i>"An outside viewpoint then suggests that there is room for a hardware vendor-driven graphics API that has a lower barrier of entry to developers and publishers for feedback and development; is updated and developed on a rapid schedule; and is under a full Open-Source license across all platforms. So there is some logic to AMD and Electronic Arts having gone through the trouble of making the Mantle API in the first place."</i><br /><br />... and thanks to a misclick I lost what else I was going to say after this... There were some bits about AMD's retreat on pushing Mantle as a cross-platform API, e.g.: <i>Does AMD have the development resources to push a third graphics API in addition to legacy DirectX support and contemporary OpenGL support into the Catalyst Driver set?</i><br /><br />There was also something else about software vendors like Valve, Epic, and Sony working with a vendor like Nvidia to push a [i]"GameGL"[/i] version of OpenGL. Well, maybe not Nvidia since they don't grok open-source development models. I'll remember what all I had written eventually... Anonymoushttps://www.blogger.com/profile/16837441025951698498noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-6403226473339445022014-05-13T10:31:08.602-07:002014-05-13T10:31:08.602-07:00In the printer world we just got our first "n...In the printer world we just got our first "nice" open api in ages, including a self certification test suite everyone is testing against. We got it because Apple leveraged the iPhone as incentive and got every printer manufacturer to the table.<br /><br />I think rewriting the API would be a mistake at least at this point in time. Instead Rich have you considered creating an automated test suite? From the sounds of it the issues you've hit related to pipeline stalls are beyond the OpenGL spec. Getting extra constraints into OpenGL would be an uphill battle but benchmarks and test suites might have better success.<br /><br />Users and media will not understand the issues but will understand when a test they trust says there is a problem. A fantastic showcase of this was the ACID series of browser conformance tests. The original ACID test was written by a Mozilla developer. The test got popular with users and the media which forced even Microsoft to play ball. We're now up to ACID3 and even Microsoft has released a standard compliant browser.<br /><br />Rich, writing a brand new standard might not be in the cards but OpenGL can still improve.Danielhttps://www.blogger.com/profile/11439161931643117421noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-50442901982289653022014-05-13T06:26:22.161-07:002014-05-13T06:26:22.161-07:00This calls for an OpenGL cleanup project.
ValveGL...This calls for an OpenGL cleanup project.<br /><br />ValveGL? :) Theodore Imrehttps://www.blogger.com/profile/08841963826882469853noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-73272831214182637122014-05-13T06:01:16.204-07:002014-05-13T06:01:16.204-07:00There is nothing in Mantle that would prevent it f...There is nothing in Mantle that would prevent it from being standardized and adopted by other vendors. Kronos could head this up if they wanted to. The hurdles here are political, not technical. See http://support.amd.com/en-us/search/faq/184 for AMD's take on the subject. Also, ironically: http://www.khronos.org/members/promoters. It's primarily the CPU/GPU vendors that steer OpenGL. Anonymoushttps://www.blogger.com/profile/17954704798863485416noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-48565406317051464262014-05-13T05:16:55.638-07:002014-05-13T05:16:55.638-07:00My thoughts:
Up until recently desktop OpenGL was ...My thoughts:<br />Up until recently desktop OpenGL was a bit of a neglected child. CAD programs that used it, used very old school OpenGL and new programs, like games, were few and far between. Additionally, if something used high end GL, it meant that it was a high price, low volume product so the software vendor specified the GPU vendor that was cool. Now we are in a world where consumer, high volume, is trying to target OpenGL and we find that it is a hard ride. There was an attempt years and years ago to make a leaner, meaner, GL API: long peaks. That attempt failed, likely for backwards compatibility. What we have left is just Core vs Compatibility profile which in no way really deals with the core issues of the GL API: lots of state, lots of binding and so on.<br /><br />On the other hand OpenGL ES is the mobile graphics API. To be frank, it sucks too. It suffers from all the downfalls of desktop GL: bind to use and lots of state. In fact, one can view OpenGL ES2 as basically a subset of GL2 + FBO and OpenGL ES3 as a subset of OpenGL 3 (mostly). It suffers from all the same issues as an API. The main saving grace for OpenGL ES has been Apple: namely the iPhone. There, one has one driver and one platform. That is it. Does not matter if it follows the spec exactly. Does not matter if it might act weird because all iPhone's of a fixed generation (and even really all) do the same things the same way mostly, so no surprises. Android OpenGL ES development on the other hand is a horror, far, far worse then desktop GL because of the massive variety of hardware and drivers.<br /><br />And now a crazy thought which has issues in itself: Gallium. Usually Gallium is pitched as a way to write a GL driver, but it is actually an API. A relatively simple and direct API that is expressive enough to do all what OpenGL 3 and D3D10 require. There are warts: I am not convinced that TGSI, the shader instruction set on Gallium, is expressive enough and the API has changed some over time. On the other hand it has potential and it is in such a way that making tools on top of Gallium is not so bad. Gallium API lacks some important exciting features like bindless, but nevertheless it could be addressed. <br /><br />Anonymoushttps://www.blogger.com/profile/05580136549273882977noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-23316693810425385992014-05-13T05:11:56.390-07:002014-05-13T05:11:56.390-07:00This comment has been removed by the author.Anonymoushttps://www.blogger.com/profile/05580136549273882977noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-31415277387891723902014-05-13T02:58:40.346-07:002014-05-13T02:58:40.346-07:00Mantle is a proprietary, vendor-specific API. It&#...Mantle is a proprietary, vendor-specific API. It's the last thing the gaming industry needs. I shouldn't have to elaborate, as the prospect of a GPU/CPU vendor steering a standard graphics API specification is just ridiculous.Anonymoushttps://www.blogger.com/profile/07704650347832538804noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-35246988644533523932014-05-13T01:49:53.992-07:002014-05-13T01:49:53.992-07:00From the sounds of it, OpenGL ES is in a better st...From the sounds of it, OpenGL ES is in a better state than OpenGL itself - would it be plausible to bolt all the missing features into an extended version of ES, and slowly deprecate the "classic" version of OpenGL, or would that be impossible/pointless/more work than fixing OpenGL 5 ?dnebdalhttps://www.blogger.com/profile/06176214688033421135noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-71592567536953255172014-05-12T19:10:10.598-07:002014-05-12T19:10:10.598-07:00After all, the industry is talking/putting the mou...After all, the industry is talking/putting the mouth in front of developers where money was put. Although I'm not an expert here, barely, I can say a few words about this topic.<br /><br />First of all, I like Mantle. It's leaner, modern, and as marketed, close to the hardware. But one thing is really making me anxious and that is, foremost, is it that hard to develop tools, an API,and... Forget that, proper software engineering maybe? One day?<br /><br />Just engineer and develop the core, but don't let it be hardware bound. Let the hardware vendors do the bottom-layer implementation of the core (main layer). I know it is hard to engineer such an API and tools around it, but it's feasible. <br /><br />Of the current state of these developer unfriendly tools, I'm anxious. Very! But what can I do when all this is just good old business, nothing more. Nonetheless this is not a healthy business.Anonymoushttps://www.blogger.com/profile/02381249977686164322noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-6502596380655833672014-05-12T18:33:15.547-07:002014-05-12T18:33:15.547-07:00and the solution?
I have a suggestion
have 2 ve...and the solution? <br /><br />I have a suggestion <br />have 2 versions of OpenGL <br />one legacy that would be the last released (4.4) and create the new OpenGL 5.0 in partnership with Nvidia, Intel, AMD, Apple, Google, and Valve etc. <br />this new OpenGL would have only the good features of OpenGL and adding new tools and better documentation and prepared for the future <br />Having two versions of OpenGL would not be any problem, one legacy, and the other for new games. <br />viable solution that does not create problemsH€n®1qu€ CaRioCahttps://www.blogger.com/profile/10124764722174242602noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-52366932580202249562014-05-12T17:35:31.279-07:002014-05-12T17:35:31.279-07:00And that is the mark of a good developer. You unde...And that is the mark of a good developer. You understand your target, and have chosen the best tool for the job.Anonymoushttps://www.blogger.com/profile/13405315534947882567noreply@blogger.comtag:blogger.com,1999:blog-7395797351911594965.post-64602926197207591662014-05-12T16:40:03.068-07:002014-05-12T16:40:03.068-07:00I think that what Timothy suggests could work, but...I think that what Timothy suggests could work, but in order for it to make sense, both code compatibility and ease of use need to be secondary goals for the lean core. The lean core should only provide enough abstraction to abstract across drivers. If we agree that state-based, etc. are bad for performance, but are unwilling to change them because it makes the compat profile too messy, then the lean core is going to be far less lean than it might otherwise be. <br /><br />This wouldn't be a problem if there were other ways at getting at the GPU, but there aren't any. IMO that's the crux of it. OpenGL is trying to be both a high and a low level abstraction at the same time.<br />Anonymoushttps://www.blogger.com/profile/17954704798863485416noreply@blogger.com