I'm trying to do some profiling on my OpenGL ES code. Somewhere in my GPU pipeline (a shader I believe) is causing a huge delay. Which is the best profiler I can use? Is this one a good option? is there one I can use directly within Visual Studio?
If you have a GPU performance issue on IOS, the best is to use XCode tools to profile it directly on device, running the app from Xcode and then doing a frame capture to look at the timings for each draw call / the number of cycles used by each shader (more info here)
You can also profile on Windows if you are also able to simulate your graphics pipeline in classic OpenGL in your Windows version, but this may not be a good idea as the iPhone's GPU is very different than a classic desktop GPU so the bottleneck might not be the same on Windows than on IOS.
To profile on Windows I would suggest using either Nvidia PerfKit (if you have a Nvidia card) or AMD's GPU PerfStudio if you have an AMD card.
There is also RenderDoc which is a nice tool but not sure if it provides much profiling information (it is more for debugging graphics issues than profiling)
I own a laptop with nVidia Optimus
I tried everything to get rid of it, or make it work, and it refuses to work.
One problem in particular, is that when the WinAPI is called with information about the hardware (for example queries with capabilities, device-id, device name, and so on), apps always get the information for the integrated Intel card, that is terrible, and don't exactly match the nVidia card in capabilities either, this make some games and apps misbehave or crash.
I was wondering, can I somehow override those WinAPI calls, and make them lie? For example when the app asks about GPU Device-ID, I tell to it that it is a arbitrary device I want.
Bonus question: Can this also be applied to ASM calls, like CPUID and RDTSC? Many older games rely on those... also the Intel Compiler infamously made to work with only P4 tend to treat new (Core i7 of any generation) CPUs as AMD, and choose crap code paths.
EDIT: Some people are misunderstanding what I want to code.
I want to make a launcher app to workaround a common nVidia Optimus bug, like those apps to make games borderless, or to make them use a different more compatible version of DirectX than their original.
nVidia Optimus works (usually, it can be done differently) by the machine having a integrated Intel Chip, and a nVidia Discrete GPU, the computer treats the DGPU as a sort of video-coprocessor, the actual video chip is always the Intel video chip, but when Optimus kicks in, the Hardware Accelerated rendering is passed to the DGPU, that after finishings its work, copy the results into Intel's chip framebuffer, that finally show it on the screens.
The bug in this implementation, is that it never considered what happens when an app queries about the video capabilities, because the video chip is always the Intel one, any queries get a reply related to the Intel one, even if the chip that will actually receive the draw calls in this app is the nVidia one.
As result, any mismatched DX or OGL extensions between the GPUs can cause bugs or crashes, programs may assume wrong things about the available computing power and memory, may have timing problems, and so on.
I've been fighting with this tech for years, and found no practical solution, this idea is my "final stand" idea, make a "Optimus Launcher" app, that allows you to launch any game with Optimus and it will work, hopefully without ugly hacks like disabling Secure Boot (I disabled Secure Boot to play Age of Decadence, in machines with Optimus AoD, and other Torque3D games, don't work if Secure Boot is enabled, I have no idea why).
You can hook WinAPI calls and make them do what ever you like but it's nothing which is implemented easily. Furthermore I guess that some anti virus programs will get very nervous if you application is doing stuff like that...
Take a look at this article which is a good start: API hooking revealed
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
If you open the page "Graphics and Gaming (Windows)" on microsoft.com
the last category is described as
Legacy Graphics: Technologies that are obsolete and should not be used in new
applications.
This category includes (among others) the following APIs:
GDI
GDI+
OpenGL
What's your opinion? If i want to roll out a new software today it must support Windows XP (still about 50% of all installed systems). Direct2D requires Windows 7/Vista. What else should be used?
I suspect that Microsoft's definition of "legacy" has little to do with what any sensible developer should do, and is instead based on some Grand Rewrite of the Windows API.
Starting at around Windows Vista, Microsoft has been redesigning many of their API's. We now have MMDevAPI as the One True Sound API, WIC is the One True Image File API, etc. From what I've seen/heard, these new API's are much better than the old ones, and the "legacy" systems all work based on the new ones. In Windows Vista and later, DirectSound is entirely based on MMDevAPI, and components that need to read image files do it via WIC.
Windows 8 will have an ARM version, which it appears will support only a subset of the current Windows API. We won't know for sure until Windows on ARM is released, but, based on the libraries included for the ARM platform in Visual Studio 11 (ref: http://www.winehq.org/pipermail/wine-devel/2012-March/094559.html), it's looking like GDI+ and OpenGL will not be available. GDI is available for linking, but that doesn't necessarily mean it's intact.
This new API's from Vista and later roughly correspond to the libraries in the VS11 ARM target. I'm guessing that anything on that list is there because it's either the latest and greatest way to do what it does, or it's too technically important to discard (for now). Thus, "legacy" is anything that's not the latest and greatest way to do at least one thing.
I'm not sure what is the One True Graphics API. Already we have Direct2D, Direct3D, DirectComposition (which, by the way, is not available until Windows 8), DirectWrite, and DXGI. DXGI seems the closest, but I don't have a deep enough understanding of the graphics API's to say. I suspect gdi32 is technically very difficult to get rid of. How are non-legacy applications meant to find out when part of a window has been revealed and therefore must be painted, without using WM_PAINT, which involves an HDC, and how could a library do that on an application's behalf without replacing its window procedure? How are we meant to make semi-transparent windows without using UpdateLayeredWindow, which takes an HDC? How much does user32 depend on gdi32, and can they really be separated?
From a technical standpoint, Windows can easily get rid of GDI+ and OpenGL, but I'm not convinced that getting rid of OpenGL will work out, even on a new platform that doesn't promise any backward compatibility. It seems too valuable to developers. GDI+ isn't so important, but it's very easy for a third party to provide a replacement.
I would say use any of the API's you listed, and the worst that's likely to happen is that you have to rewrite your UI if you want to port your app to metro or Windows on ARM. GDI is a fine choice if your needs are simple and you'll be coding directly for the Windows API. There aren't many situations where I'd recommend GDI+ over OpenGL as a drawing API. GDI+ is slow, limited, and only available on Windows. The GDI+ API is simpler because it's 2D, so maybe it's worthwhile if you need to do something very simple but with anti-aliasing.
OpenGL isn't deprecated, Microsoft's implementation of it is. Microsoft's implementation is stuck at version 1.1, which is old. The current version of the standard is past version 4. If you want to use OpenGL, it is fully supported by NVidia, ATI, and Intel graphics cards on the Windows desktop, but not in Metro Windows Modern UI apps, is an industry standard, and also works on Mac and Linux. If you need a software fallback implementation, Mesa has got you covered, and it even works on DOS. (Since Mesa can render into memory buffers, there's no reason it won't work in Modern UI apps, but you probably don't want to do this because it can be slow.) One thing of note is that WGL, the API for accessing OpenGL functionality on the Windows desktop, depends on GDI (which is deprecated) so you probably want to use something like FreeGLUT or SDL instead if you want to future-proof your application, which also nets you platform independence.
OpenGL ES is a variant of OpenGL which works on Android and Apple iOS. It is also accessible in JavaScript via WebGL, which Internet Explorer 11 will support (and pretty much every other browser already does.) ANGLE provides a hardware-accelerated implementation of GLES for Windows which piggybacks off of DirectX (version 9 or 11) and thus should work in Modern UI apps as well. Once again, Mesa's got the software implementation covered.
TL;DR: OpenGL is not only not deprecated, it is cross-platform, standard, and has tremendous momentum in the industry. GDI and GDI+, well, not so much.
If you want to support Windows XP, then you're supporting a "legacy" operating system, and as such, using a "legacy" graphics framework is the logical choice.
Even if that weren't true, let's just say that I disagree with the advice given by the linked MSDN article. The "legacy" status here has more to do with which technology the Windows team thinks is cool this week. The status designation of "obsolete" just means that the group responsible is no longer accepting or fulfilling bug reports (except for critical security issues). Not too big of a deal—these technologies have been around long enough that they're fairly feature-complete and stable.
GDI isn't going anywhere, so if you need something rock-solid that is guaranteed to be supported anywhere and everywhere, that's what I would go with.
If you need a bit more 2D capabilities than GDI offers (e.g., alpha channel transparency), then you could consider using GDI+. It's nearly an order of magnitude slower than GDI, but that's not too big of an issue on modern machines with more power than you could ever want. This, too, is going to be supported for a very long time to come.
That said, if I were writing a new app today, I probably wouldn't bother with OpenGL. There's very little that it offers in benefits over Direct2D and DirectWrite, which are both what Microsoft is pushing as the replacements for GDI/GDI+. There might be some benefit to using OpenGL if you absolutely must target Windows XP because as far as I can tell, Direct2D/DirectWrite are only supported on Vista and later, but that's because (as I mentioned originally), Windows XP falls squarely into the "legacy" or "obsolete" camp itself. Alternatively, if you already know OpenGL well and don't have time or the desire to learn Direct2D/DirectWrite, then it might make sense to continue using it in a new application.
Don't let the verbiage of the MSDN article scare you. Choose whatever technology makes the most sense for your specific use case given all of the available information. By the time any of these technologies go away completely, you'll have to re-write the app completely for a dozen other reasons.
Edit: Hmm, it looks like DirectWrite has also been declared (by some people at least) "obsolete" as well, having been replaced by Direct2D. That's funny, it hasn't even been around long enough for me to bother learning it. I guess that only goes to support my earlier argument that "obsolete" simply designates that a particular technology is not what is currently considered to be in vogue by the Microsoft devs.
I'm personally waiting until all the bugs get worked out of this stuff (and we decide on a semi-permanent standard) before I make the switch for any of my applications. Everything I've seen written in DirectDraw or Direct2D has had serious rendering bugs and is a performance nightmare, even on reasonably competent machines. Sure, they only show up sometimes, under the right conditions, but that's too much for me. And I swear, the blurry text shows up all the time. Not being able to read what's on screen is a deal-killer for me and my users. GDI doesn't have this problem, and it's not going anywhere.
Are GDI, GDI+ and OpenGL really obsolete/deprecated?
This is not true for OpenGL. OpenGL 4 allows you to use geometry shaders on winxp. Which isn't possible with DirectX (DirectX 10 and up isn't supported on WInXP). It is also one of the only cross-platform 3D APIs out there.
From a business point of view MS is interested in promoting DirectX since it is their technology that lock Developer into windows platform (they're also interested in making DirectX more attractive for developer, but that's another story). So it makes sense that they aren't keen on promoting OpenGL.
What else should be used?
I'd advise to stop using platform-specific tecnologies when possible. Grab cross-platform framework and use it for your application. There's Qt, GTK, wxWidgets and other toolkits for GUI apps, and SDL(and alternatives) for games. This way when platform developer decide to make ridiculous decision (like not supporting DX10 on WinXP) you dislike, you'll be able to move elsewhere with minimum development cost. Qt is also ridiculously powerful and at the moment I have no reason to use something else for GUI development. Still, situation can change in the future.
In short, while developing for certain platform you should keep in mind that platform developer might have their goals that are not compatible with your wishes. Discovering that your source has become locked into single platform isn't very pleasant experience. Your own goals should be the first priority, and if os developer tries to make you use certain technology you don't like, then you shouldn't support that technology.
Because OpenGL is a standard, it should be considered equally deprecated as C or C++ so it is a matter of time before the entire Windows API -- which today has become a compile once run on every x86 machine API thanks to Wine -- is considered deprecated in favour of .NET and C#.
I use GDI for simple graphics and OpenGL, when I need accelerated 3d.
Another aspect is that Microsoft's build-in implementation of OpenGL is definitely to be considered as deprecated since it is just version 1.1 or something, but that has been for a long time.
Yeah, about OpenGL, it actually outperforms DirectX in many ways both resource and display wise. It will never be promoted by Microsoft because it can't own OpenGL, not to mention most people don't do their research and Microsoft can claim it is old. Truth is opengl is opensource standard and evolves at a much faster rate than closed does because it is more than 1 room of developers paid to work on it. Also Microsoft has contracts with many companies to release using only Microsoft's software, this causes more business for Microsoft and less to use the more advanced OpenGL standard. It is a interesting lock up if you will, Microsoft creates these contracts so that many programs are written in DirectX to keep business for Microsoft, and no company will refuse it because Microsoft has about 80%+ home user market.
I'm developing a very simple application for the Mac OSX platform making use of Qt and OpenGL (and QtOpenGL) so crossplatform gets easier.
The application receive a variable number of video streams that have to be rendered to the screen. Each frame of these video streams is used as a texture for mapping a rectangle in 3D space (very similar to a videowall).
Apart from the things such as receiving, locking, uploading video data, synchronizing threads... i consider it is clear that it's a quite simple application.
The fact is that all behaves ok when using cocoa based Qt 4.7 binaries (the default ones) in a 10.5 Mac.
But my code has to run fine at all of the OSX versions starting from (and including to) 10.4. So i tried the code in a 10.4 machine and it crashed just when starting. After a few hours of internet reading, i discovered that for a Qt Application to be targeted at 10.4, carbon Qt based has to be used. So i rebuild the whole project with the new framework.
When the new resulting binary gets run, all works well except by the fact that application's fps fall to about 2 fps!! And it behaves the same at both machines (10.5 computer has sensibly better features)
I've spent quite time working on this but i have not reached a solution. Any suggest?
More information about the application and things i've tried
code has not been modified when recompiling carbon based
only two (256x256 textures) videos ar used in order to assure it's not a bandwidth limit problem (although i know it shouldn't because the first code worked)
the 2 video streams arrive from network (local)
when a video stream arrives, a signal is emmited and the data will be uploaded to an OpenGL texture (glTexSubImage2D)
a timer makes render (paintGL) happen at about 20ms (~50 fps)
the render code use the textures (updated or not) to draw the rectangles.
rendering only when a video arrives won't work because of having 2 (asynchronous) video streams; besides more things have to be draw at screen.
only basic OpenGL commands are used (no PBO,FBO,VBO,...) The only one problematic thing could be the use of shaders (available only from Qt 4.7), but its code is trivial.
i've made use of OpenGLProfiler and Instruments. Nothing special/strange was observed.
Some things i suspect (conclusions)
it's clear it's not a hardware issue. The same computer behave differently
it gives me the sensation it's a threading/locking problem but, why?
carbon is 32 bits. The 10.5 application was 64. It's not possibly develop 64 bits in carbon.
for giving away the 32 bits possible cause, i also rebuild the first project for 32 bits. It worked partically the same.
i've read something about carbon having problems (more than usual) with context switching.
maybe OpenGL implementation is Multithread and code is not? (or the opposite?) That could cause a lot of stalls.
maybe carbon handle events differently from cocoa's? (i mean signal/event dispatching, main loop...)
Ok, this is (sorry for the so long writing) my actual headache. Any suggestion, idea.. would be very appreciated.
Thx in advance.
May I ask a diagnostic question? Can you ensure that it's not being passed to the software renderer?
I remember that when 10.4 was released, there was some confusion about quartz extreme, quartz and carbon, with some of it disabled, and hardware renderers disabled by default on some of them, which required configuration by the end user to get it working correctly. I'm not sure whether this information is pertinent, because you say that, having targetted 10.4, the problem exhibits on both the 10.4 and the 10.5, yes?
It's possible (though admittedly I'm grasping at straws here) that even in 10.5 carbon doesn't use the hardware renderers by default. I'd like to think though that OSX prefers hardware renderers to software renderers in all scenarios, but it may be worth spending a little time looking into, given how thoroughly you're already looking into other options.
Good luck.
If you are using Qt, I guess your code would work on a windows or linux platform. Have you tried your application under these platforms ?
This would quickly reveal if it comes from Qt or the mac OSX version.
I thought this should be easy, but... geesh! A vendor gave me a fairly simple demo program meant to showcase some trivial icon animations. The target platform is an embedded system (MX51) with accelerated OpenGL ES 2.0/OpenVG and EGL support.
Unfortunately, the demo also has an annoying dependency on a few Qt utility classes (e.g., QImage). If not for this dependency, I would compile/run the thing on the target. But I don't relish the thought of cross-compiling Qt just to run this little demo---even if there were enough room for it on the embedded board.
I hoped I might be able to run the app on a standard(ish) Ubuntu 10.04 VM, and started following these directions to make it happen. And I actually managed---like, 10 hours later---to compile everything and get a runnable binary of the demo program. However, when I run it, I see the following error:
eglCreateWindowSurface: egl error "EGL_BAD_CONFIG" (0x3005)
Sigh. Not what I wanted to see after all that effort. This seems way more difficult than it should be.
Is the embedded GL landscape really such a ghetto that I have to run even trivial programs on the target using some vendor-supplied BSP? Judging from the lack of responses to this guy's question, I'm thinking the answer might be yes. But I don't even care about acceleration (yet). I just want to run the stupidest of OpenGL ES 2/OpenVG programs on a desktop PC and get an idea of how it looks. (It doesn't matter to me whether the PC is running Linux or Windows.) How do people do this sort of thing?
There are several OpenGL ES 2.0 emulators, such as:
For ARM Mali GPUs
For PowerVR GPUs
Also very recently, AMD has posted drivers that expose OpenGL ES 2.0 on desktop.
More recently, OpenGL 4.1 exposes the GL_ARB_ES2_compatibility extension, which makes OpenGL 4.1 drivers GL ES 2.0 compatible.
For OpenVG, you can use AmanithVG GLE.
Qualcomm's OpenGL ES emulator includes OpenVG support. You can download it from http://developer.qualcomm.com