I am creating an OpenGL game on a Windows 7 machine using VS2010. In addition, SDL, QtCore, QtXML and FbxSdk are also used to assist in development. I am experiencing a very peculiar problem with glGenTextures when running outside debug mode. Let me explain.
When I compile and run the application in Debug mode, the models are textured and displayed properly. As soon as I debug the application or compile and run the application using release mode textures are no longer being applied to the models.
I have tracked down the problem to glGenTextures not giving me a valid name. It does not give me any errors either. The way I am loading everything is as follows:
Models are loaded as FBX through FbxSdk, Required textures are loaded as the model is loaded. All models are loaded in another thread, I made sure that no OpenGL functions get called anywhere while this thread is loading models. If I don't load models in another thread everything works. I tried everything I can think of including halting the main thread while the models get loaded to guarantee nothing else if happening while models get loaded. None of it works.
Again this wouldn't be as weird except compiling as debug works. Release and Debugging the application doesn't work. Any thoughts?
I can only guess, but did you maybe not make the GL context current on the model loading thread? Remember that the OpenGL context is thread specific!
On the other hand, it's usually advised against to use the same GL context in different threads. Either use a different context and share resources, or defer all the GL calls to the main GL thread.
The difference when using the debugging mode is that VS will use the debug-heap when you debug, but won't use it when you just run a debug build without actual debugging.
However, if you get the threads thing wrong, all kinds of crazy side-effects can happen which the debug heap might "hide".
Related
I switched to Vulkan from OpenGL to use multi-threading improvements.
In OpenGL, I was able to load dynamically object to the scene (buffer, textures, etc) while rendering by using a waiting system. I was loading all app-side stuffs in a thread, then when it was ready, just before a frame render in the main thread, I was sending everything into the video memory. That was fine.
With Vulkan, I know I can call some functions between threads without provoking the well known segfault from OpenGL. But, this doesn't works with vkQueueSubmit(). I already know, I tried the naive way. To me, it seems logical you can't bother a queue from multiple threads.
I came with some ideas, but I don't know which one is good or bad.
First, I would go the OpenGL way, I will prepare everything I can from the CPU/App side, then just before render a frame, I will submit buffers (with transfer queue) to the video memory. But I feel there is no a real improvement from OpenGL way...
Second, I will try to use the synchronization mechanism to be able to send buffers in a thread and render from an other. But I keep reading there is a lot of way to slow down everything by causing irrelevant locks or by using incorrectly semaphores and fences.
So my question, is basically what path to pick to solve this problem ? How can I load a buffer dynamically from an other thread while the main thread is rendering without making too much pain to performances ? How Vulkan can help ?
If you want to stream resources for immediate use (i.e. the main render cannot proceed without them), then you're pretty much going to either block the main thread waiting, or have it spin doing something visually interesting (e.g. an animated loading screen) waiting for the resources to load.
If you want to stream resources while the app is doing real rendering then the main trick here is to load resources asynchronously in the background and only switch to using those resources in the main thread once they are already loaded. If the main thread ever ends up actually blocked on a semaphore then you've probably already started dropping frames, so your "engine" design needs to ensure that never happens. A lot of game use simple low-detail proxy objects as stand-in versions while the high-detail version is loading in the background.
None of this is particularly related to the graphics API - both GL and Vulkan need the same macro-scale behavior. Vulkan API features don't particularly help because the major bottlenecks which cause problems here are storage/network/CPU which have nothing to do with the graphics part of the problem.
I decided to trust threads !
In the first place it seems to work, I get a lot of :
[MESSAGE:Validation Error: [ UNASSIGNED-Threading-MultipleThreads ] Object 0: handle = 0x56414228bad8, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0x141cb623 | THREADING ERROR : vkQueueSubmit(): object of type VkQueue is simultaneously used in thread 0x7f6b977fe640 and thread 0x7f6bc2bcb740]
But it works !
So, the basic idea is to have a thread for loading objects while the engine is drawing. This thread takes care of creating the UBO for the location of the object, then when the geometry is loaded from RAM, it creates the VBO and IBO (I left material with image/UBO on hold for now), then creates the graphics pipeline (with layout, descriptor layout, shaders compiled with GLSLang on the fly) (The next idea is to reuse pipeline for similar needs) and finallly sets a flag to say the object is ready to use. In the other hand, I have my main thread rendering and takes new objects when they shows up ready.
I think it works because I have a gentle video card (GTX 1070) with multiple queues setup, I had one for graphics and an other one for transfer setup.
I'm pretty sure, this will crash or goes poorly with a GPU with a single queue, and this should be why the validation layers tolds me these messages.
I have developed a fairly large C++ program in VS 6.0 on a Win XP platform, and have now migrated to a new machine running Win 7 (still running VS 6.0). The code includes a function to instantiate and run a CFileDialog object to find and open an ASCII file with a specific extension from a specific initial directory. But now, the program hangs on the line
if (t1.DoModal()==IDOK)
...where t1 is the CFileDialog instance.
To investigate why the standard CfileDialog class stopped working, I created a separate test project in VS 6.0 with a simple dialog with one button, containing this code:
void CFileDialogTestDlg::OnOpenFileDialogButton()
{
CFileDialog t1(true);
if(t1.DoModal()==IDOK)
{
CString s3=t1.GetPathName();
MessageBox(s3);
}
}
This test works fine and displays a useable file dialog. I can also duplicate what I want in my large project in terms of initial directory,etc by modifying the m_ofn members of t1.
But putting this code into my large project (ie modifying the relevant button in it) still hangs on the DoModal() line. It seems unproductive trying to trace into a standard MS class, the internals are impossible to understand in a reasonable timeframe.
When I increased stackspace for my test project to match my large project (400MB), I reproduced the hanging behaviour identical to the large project.
Can anyone explain why increasing stackspace should affect file dialog execution in this way, and is there a way around the problem, bearing in mind I need the large stackspace to avoid completely rewriting my project?
I'm not sure the stack is your problem. It's been a while but I seem to recall common modals hanging if you access them from the wrong thread.
Use PostMessage() API to send commands from any thread to the thread that owns the modal dialog. It needs to be the owning (and blocking) thread that ultimately receives the command to accept/cancel the dialog so that it returns from its message pump routine.
If you install the Windows debug symbols, you can see the full call stack of your blocking thread in a debugger.
I am using LibGDX to make a game. I want to simultaneously load/unload assets on the fly as needed. However, waiting for assets to load in the main thread causes lag. In order to remedy this, I've created a background thread that monitors which assets need to be loaded (textures, sounds, etc.) and loads/unloads them appropriately.
Unfortunately, I get the following error when calling AssetManager.update() from that thread.
com.badlogic.gdx.utils.GdxRuntimeException: java.lang.RuntimeException: No OpenGL context found in the current thread.
I've tried runing the background thread in the main thread in the beginning and just dealing with the first few screens, and everything works fine. I can also change the algorithm to just load everything into memory from the start in the same thread, and that works as well. However, neither works in the background thread.
When I run this on Android with OpenGL ES 2.0 (which is flexible in odd ways) instead of on Windows, everything runs fine, and I can even get the pixel dimensions of the images - but the textures render black.
My searches have told me that this is an issue of the OpenGL context being bound to a single thread, but not much else. This explains why everything works when I shove it in the main thread, and not when I put it in a different one. How do I fix this context problem?
First things first, you should not access the OpenGL context outside of the rendering thread.
I assume you have looked at these already, but just to make sure read up on the AssetManager wiki article, which talks a bit about how to use the AssetManager for asynchronous managing of assets. In addition to the wiki article, check out the AssetManagerTest to better understand how to use it. The asset manager test is probably your best bet into loading at how to dynamically load assets.
If you are loading a ton of stuff, you may want to look into creating a loading bar to load anything large upfront. It might work to check assets and such from another thread (and set a flag to call update), but at the end of the day you will need to call update() on the rendering thread.
Keeping in mind you have to call update() it from a different thread, I don't see why you would want another thread to check conditions and set a flag. There is probably more overhead using another thread and synchronizing the update() call than to just do it all on the rendering thread. Also, the update() method only pauses for a couple milliseconds at a time as it incrementally loads files. Typically, you would simply call load() for your asset, then check isLoaded() on your asset. If it isn't loaded you would then call update() once per frame until isLoaded() returns true. Once it returns true, you can then call get() and get whatever asset you were loading. This can all be done via the main rendering thread without having the app lag while its loading.
If you really want your other thread to call update(), you need to create a Runnable object and call postRunnable() such as how they have it described in the wiki article on multi-threading with libGDX. However, this defeats the whole point of using other threads because anything you use with postRunnable runs synchronously on the rendering thread.
Edit : If you're seeing this same problem (and you're accustomed to NOT seeing this under VS2010) please comment below so I know it's not just me - but be sure to check Han's answer to make sure none of those scenarios appear...
I've been updating my app to run with .NET 4.5 in VS2012 RTM and noticing something that I don't quite understand and that is unexpectedly green highlighted statements (instead of yellow).
Now I'm well aware of what this is supposed to mean, and the IDE is even showing me a little explanation tooltip.
This is the next statement to execute when this thread returns from
the current function
However there's absolutely nothing asynchronous or thread based about this code. In this simple example I'm sure you'll agree that string.ToUpper() won't be off in another thread. I can step through the code no issue.
There's nothing else going on and I am on the main thread as you can see here.
I am using async and await and MVVM-Light (the above method is the result of a RelayCommand) but I still get this behavior even when the code path is directly off an event handler such as PreviewKeyDown.
If I create a new app I cannot duplicate this - the coloring is yellow as expected - even when using await.
Anybody got any idea? It's starting to drive me crazy!!
It is green when the current instruction pointer is not exactly at the start of the statement. Some common causes:
Common in threaded code, setting a breakpoint in one thread and switching context to another. The other thread will have been interrupted by the debugger at an entirely random location. Often in code that you don't have source code or debugging info for, like String.ToUpper(), the debugger can only show the "closest" source code
Using Debugger + Break All to break into the debugger. Same idea as above, the instruction pointer will be at a random address
Getting an exception in code you don't have debugging info for. The editor shows the last entry in the Call Stack that it does have source code for. You need the call stack window to see where the actual exception was raised. Or the Exception Assistant, its reason for being
Debugging optimized code. The jitter optimizer scrambles the code pretty heavily, making it likely that the debugger can't show the current location accurately
Having out-dated debugging info or editing the code while debugging
Debugging code generated by the x64 jitter, happens when the project's Target Platform setting is AnyCPU. The x64 jitter has a number of chronic bugs that are not getting fixed, generating incorrect debugging info is one of them. Problems that were not addressed until it was completely rewritten, done by the RyuJIT project and first available in .NET version 4.6. Targeting x86 in your EXE project is the workaround.
I understand that this is old post yet I would like to answer the question with my experience.
I have encountered same issue recently in one of my WCF application. After debugging and closely looking service logs and I find out that my code was giving this error because service was hitting max allowed limit for code execution and once the service hit max allowed time limit it was trying to offload the current debugging session.
ERROR IN GREEN STATEMENT: this is the next statement to execute when thread return
So avoiding this issue you can try to look any potential code(Code/Service Timeout or any other code block) which is trying to offload your currently executing code context and try to fix it, furthermore original explanation given by #Hans is still very much relevant for trouble shooting this issue.
Actually, I am also facing this issue. This is because I missed some layout component in landscape mode, So check all the Id's and components and Run, you will not get this error.
I have a multi-threaded application that I'm debugging inside the IDE (Visual Studio 2008, Win7-64, C++).
For "debugging" purposes, I "pretend" that I always have a single processor (the program detects the number of local processors), but the program design establishes a minimum of two threads (e.g., the "main thread" which handles GUI and event traffic, and a second "processing" thread where work is moved off of the "main thread"). (In a "production" build there would be a single main thread, and one-or-more "processing" threads depending on the number of detected processors.)
ISSUE: Breakpoints in the code (within the IDE) sometimes are triggered, and sometimes not. Re-running the program may "catch" on a break point where the previous run it did not "catch" (no source code changes or rebuild is performed to see this change-in-breakpoint-catch-behavior, the program execution path is identical).
(I mostly only care about triggering breakpoints in the non-GUI/non-main-thread, but I assume that should not matter.)
QUESTION: Is there a way to make these break points catch more "reliably"? (What influences whether a break point "catches" or not?)
I'm aware of, and NOT concerned with the following:
Source is out-of-sync with latest linked executable
Build is not "debug" (no debug symbols available)
"Clean build" is needed (debug artifacts out-of-date)
"Step Over/Into" may not work properly when another thread "breaks"
during that first thread's stepping operation
On web searches, there was a mention of possibly setting the compiler setting to "x86" and not "Any Processor" to catch breakpoints, not sure why that might matter ... ?
Finally, yes, of course, all logic "should" be tested in a single-threaded application (e.g., re-factor to ensure deterministic single-threaded execution for unit and regression tests). However, for the current testing, I need to be in the "real" application (think "integration testing" or "systems integration").
Normally breaking is extremely reliable. Here are some things to try:
Hard code a breakpoint with DebugBreak(). This should always be caught, but if this exhibits the same broken behavior, you have narrowed down the problem.
Where you currently have the bp set, add a line to print to screen/file, and set the breakpoint on that line. This is to be certain this line is really even being hit. You may have a strange, unexpected bug that is actually skipping the entire section unexpectedly and this is necessary to be sure.
Try with and without any optimizations. Debugging works best with all optimizations off, but even with deadstripping and inlining features at work, breakpoints are expected to still work. Does this issue occur even with optimizations off?
You say ISO C++, does this mean you've actually switched off all microsoft extensions? I've never compiled this way in visual studio, but if you have, try switching extensions back on and see if that has any effect.
I'm going to agree with VoidStar and other comments. I have worked with VC6, VS2005, VS2008 and VS2010 and I have debugged pretty complex multi-threaded apps with them and breakpoints have always been reliable for me.
With once exception. For projects that use DLLs, sometimes breakpoints that are set in code from a DLL do not work. This is not because VS misses the breakpoint, but instead because the debugger cannot map that line of code to an actual location in the compiled code, probably because the pdb file could not be loaded for some reason. When this happens you see a hollow red circle in the left margin of the breakpoint line instead of the full red ball. Could this be your problem?
I have not figured out why this happens sometimes, but in my experience it only happens for breakpoints in modules that are not the main project being debugged. A workaround that I use is to start the debugger from the DLL, putting the exe in the startup debug configuration for the DLL project. Another trick that sometimes helps is to have all the projects in a single solution, and have them all setup with correct references, so that with one compilation you can rebuild the whole thing.
Good luck, I hope this helps.