When using Renderdoc to debug my Vulkan applications, I have noticed that when I execute the application normally somehow Renderdoc is also running and producing the statistics overlay on the window.
For example when executing ./executable from the command line I get:
(The information on the top left corner is the Renderdoc statistics)
Note that this still applies when deleting and re-compiling the executable.
I have tried uninstalling Renderdoc but I get the error that Vulkan fails to load librenderdoc.so, I have even tried reinstalling the Vulkan libraries but have had no luck.
Any help as to how I could execute my program normally without displaying the program statistics would be greatly appreciated.
The terminal output (from the validation layers) display:
Renderdoc uses Vulkan's layer mechanism to inject itself into the executable.
They have a lengthy blog post explaining the gory details, but basically what happens is that at runtime all your Vulkan API calls pass through Renderdoc first, which is what causes the statistics to appear. If you don't want that, you simply need to not include the Renderdoc layer when initializing Vulkan.
You either requested Vulkan to pull in the Renderdoc layer via the ppEnabledLayerNames field in the VkInstanceCreateInfo sturct passed to vkCreateInstance. In that case, you need to change your code to no longer do that and recompile the executable. Or, you may have Renderdoc loaded as an implicit layer. In that case, the executable does not need to be changed at all (and running the executable on a different machine that does not have Renderdoc installed will just work without showing the overlay). Instead, it is the Vulkan loader that pulls in the Renderdoc layer automatically.
So in that latter case, you need to change the loader configuration for your system. Since this works differently for every system and you did not mention which OS you are using, I will just leave you with a link to the official documentation that contains detailed info for all major operating systems. Simply remove Renderdoc from the list of implicit layers and the overlay should disappear.
Related
I'm using windows 10 and python 3.3. I tried to download fasttext_model300 to calculate soft cosine similarity between documents, but when I run my python file, it stops after arriving at this statement:
fasttext_model300 = api.load('fasttext-wiki-news-subwords-300')
There are no errors or not responding, It just stops without any reaction.
Does anybody know why it happens?
Thanks
I'd recommend against using the gensim api.load() functionality. It dynamically runs new, unversioned source code from remote servers – which is opaque in its operations & suboptimal for maintaining a secure local configuration, or debugging any issues which occur.
Instead, find the actual exact data files you trust and download them as plain data. Then, use specific library operations, like the KeyedVectors.load_word2vec_format() method, so instantiate exactly the model you need, using precise local-file paths you understand.
Following those steps may make it clearer what, if anything, is going wrong. If it doesn't, try also enabling logging at the INFO level to gather more information about what progress is made before failure (and add any new details as a comment or to your question).
python3 -m gensim.downloader --download fasttext-wiki-news-subwords-300
Try using this. Source : https://awesomeopensource.com/project/RaRe-Technologies/gensim-data
I'm trying to compile a project (tyr-quake) with my custom build of SDL2. My SDL2 build among other things disables all accelerated video (OpenGL, OpenGLES, Vulkan, Metal, etc), X11 and Wayland, but enables KMSDRM.
All is well, and the project I wanted to compile with this build of SDL2 compiled too. Except that when running, SDL_CreateRenderer returns Couldn't find matching render driver (even if I modify the source to pass it SDL_RENDERER_SOFTWARE and set the SDL_HINT_FRAMEBUFFER_ACCELERATION hint to "0").
I looked around the SDL source code a bit, and the software SW_CreateRenderer is indeed being called, but later on (in SDL_CreateWindowTexture) it still wants to create a renderer using a different render driver (it explicitly avoids the software one).
I also tried patching the source code to do the following:
SDL_Surface *surface = SDL_GetWindowSurface(sdl_window);
renderer = SDL_CreateSoftwareRenderer(surface);
But that also failed, as SDL_GetWindowSurface fails with No hardware accelerated renderers available and returns NULL.
My question is: is there a way to only have software rendering with SDL when using KMSDRM, or am I required to have some hardware accelerated rendering option enabled and available.
I think I figured this out on my own.
It is not possible to do so. But, if one wants to do that, implementing CreateWindowFramebuffer, UpdateWindowFramebuffer and DestroyWindowFramebuffer, and setting the appropriate function pointers should grant you the ability to create a purely software-based renderer. Sadly, I don't know KMS and DRM enough to be able to implement this myself.
We have a problem using Paperclips (printing library for SWT) on scaled monitors, but I don't think it has anything to do with the framework and all with the Eclipse environment.
Let's see an example:
Left is the print with no scaling (or 100%), right is the same print started on a monitor with 175% scaling. I know what you are thinking: the monitor and its resolution / scaling should have no influence on a print. Right, should.
While that's sad and all, it would not be much of a problem. But there comes the kicker: The above prints were generated by a JUnit test case run as plug-in test. If I run them as a regular unit test both work.
Clearly something in the Eclipse environment works differently when started in an OSGi context, and I'm trying to find out what it is (so I can maybe prevent it).
And I think that's a nice puzzle.
If you need a hint for what SWT class might be the , I narrowed it down to this file ScalePrint.java for the table (i.e if I remove the instance of ScalePrint from my demo, the table is displayed correctly; the header is still wrong, though).
I can confirm the error exists only in Eclipse 4.6, and not 4.5 or 3.7 (which is not entirely surprising, since 4.6 is the first version to support scaling). And if I add -Dswt.autoScale=100 to the VM options to disable scaling, it works as expected, too.
I could append my test case, but as I said, I don't really think it has anything to do with Paperclips per se.
So... what could break the scaling when the entire Eclipse framework is started compared to running the same code in a plain Java application?
The Problem is the use of the class Transform, which itself uses the static field DPIUtil.deviceZoom (in the form of DPIUtil.autoScaleUp(float dx)).
Since DPIUtil.deviceZoom is a static field everything fails when used with a primary monitor that has scaling (since printers don't).
I compile a DLL with mingw 4.5.0 and use it as a Game Maker 8.0 extension. Game Maker dynamically loads the dll. Everything appears to work (the dll functions are called and provide correct return values), but when I close Game Maker a dialog pops up: "Microsoft Visual C++ Runtime Library", "This application has requested the Runtime to terminate in an unusual way." After that, the process continues to linger in the background for a few seconds and then disappears.
This also happens when none of the functions of the dll are actually called. There is no DllMain, and all static/global variables are basic data types or std::string (it actually also happens when I remove the std::strings).
The dll statically links with zlib and libpng. The problem seems to vanish when I pass -static to the linker which (I assume) also links the runtime statically. However, this considerably inflates the size of my DLL, and it is at best a workaround until I understand what is going on.
Any ideas on what might be the cause?
Update: Actually, it seems that the problem only happens when two extensons are loaded in Game Maker: One with a dll linked with -static, and the other without. Linking both without -static makes the problem disappear. However, I still don't understand the problem, because the dlls never directly interact or share data structures.
Update 2: I recently found out that this might be related to strange behavior of Game Maker itself. It seems that global variables aren't initialized correctly when the DLL is loaded, which might cause a crash on unloading if global objects try to free memory they don't own. That would mean the -static was just a random factor that changed the value of the uninitialized memory the globals were associated with.
Update 3: Modified the above to include the info that this is about Game Maker extensions, since this is likely relevant as per Update 2.
It's just a guess. Try to look into something like the "static initialization order fiasco" that is described here. It may be that your problem is more related to the destructors (since it happens on close).
I'm new to VB6 but i'm currently in charge of maintaining a horror of editor like tool with plenty of forms, classes, modules and 3rd party tools all chunk together like the skin faces on that guy in the texas chainsaw massacre...
What i don't understand is why i get different results when i run the app in debugging mode, vs when i compiled it and run it on my devevelopment pc vs when i installed it on a different pc.
Yes i know i'm dumb, so please direct me to where i can find out more about this. I'm hoping to find out something like different linking, registry related etc connection that i'm simply not getting right now, i.e. something like wax on, wax off :P
The main pain in the neck is when i'm trying to debug some errors from my QA and i need to find a spare pc to test this on plus i can't directly debug because i don't know where the code is if i do it that manner.
Thanks.
i run the app in debugging mode vs when i compiled it and run it on my
devevelopment pc
When you compile you have the option of compiling to native code or pcode. The debugger runs using pcode only. Under rare circumstances when you compile to native code there will be a change in behavior. This particular is really rare. I used VB6 since it's release and I may get it once or twice a year. My application is a complex CAD/CAM creating shapes and running metal cutting machine and has two dozen DLLs. Not a typical situation. At home with my hobby software I never ran into this problem.
There are another class of errors that result from event sequencing problems. While VB6 isn't truly multi-tasking it has the ability to jump out of the current code block to process a event. If it re-enters the same block for the new event interesting things (to say the least) can result. I think this is the likely source of your problems as you software is an editor which is a highly interactive type of software.
In general the problem is fixed by reordering the effected areas. You find the effected area by inserting MsgBox or write to a text file to log where you are. I recommend logging to a text file as MsgBox tend to alter behavior that are timing or multi-tasking related.
Remember if a event fire while VB6 in the middle of a code block and there a DoEvents floating around then it will leave the code block process the event and return to the original code block. If it re-enters the same code block and you didn't mean for this to happen then you will have problems. And you will have different problems on different computers as the timing will be different for each.
The easiest way to deal with this type of issues is create some flag variables. In multi-tasking parlance they are known as semaphores or mutexes. WHen you enter a critical section of code, you set it true. When you leave the routine you set it to false. If it is already true when you enter that section of code you don't execute it.
when i installed it on a different pc.
These are usually the result of the wrong DLL installed. Most likely you have an older version while the target has a newer version. I would download the free Virtual PC and create a clean Window XP install to double check this.
If your problem is event timing this too can be different on different computers. This is found by logging (not MsgBox) suspect regions.
If you can display a screen shot or the text of your specific errors then I can help better.
The first thing to check would be the versions of all the dlls that your app depends on - including the service pack version of the VB6 dll.
Have you any more specific details about what's behaving differently?