I am trying to get Vulkan running under X11.
I have (apparently) successfully created an instance, device and surface, and several calls relating to the surface also succeed, and even return reasonable values (for example vkGetPhysicalDeviceSurfaceFormatsKHR returns two formats). However, when I call vkGetPhysicalDeviceSurfaceCapabilitiesKHR, I get the following:
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 14 (X_GetGeometry)
Resource id in failed request: 0x5800009
Serial number of failed request: 42
Current serial number in output stream: 42
The X11 Window is 0x5800009, as referenced in the error. I am using Vulkan SDK 1.0.5, and Nvidia 364.12 drivers (if that is relevant).
On the hunch that Vulkan was querying something about the Window that had not yet been created, I put a XSync(<display>, false) call before this one, and that seems to have solved the issue.
I am not sure whether this is required for proper operation (I am not an X11 expert), or whether this is an issue with Vulkan itself. If somebody has a better explanation, I would love to hear it.
I had the same error on Linux with XCB and I resolved it (with the help of MuertoExcobito's answer) by calling xcb_flush after the window creation.
I came across that same error when I bound ::XDisplay to VkSwapchainCreateInfoKHR.dpy before a window handle was actually created. So long as I keep that structure updated during resize events (with both .dpy and .window), everything continues to work fine.
Related
Example: Here's the debug log for CreateGraphicsPipelineState, it tells me what went wrong:
D3D12 ERROR: ID3D12Device::CreateGraphicsPipelineState: Root Signature doesn't match Vertex Shader: Shader CBV descriptor range (RegisterSpace=0, NumDescriptors=1, BaseShaderRegister=0) is not fully bound in root signature
However, a call to windows FormatMessage(MESSAGE_FROM_SYSTEM...) will return this for the exact same error:
The parameter is incorrect.
The first is obviously far more useful...
We used to have dxerr.lib, and we have source for dxerr.cpp in DXUT. But this doesn't cover DX12. I can't see any way for a shader-tool to retrieve the error and present it to the user from the API.
This can be done with the ID3D12InfoQueue interface, as documented here:
https://learn.microsoft.com/en-us/windows/win32/api/d3d12sdklayers/nn-d3d12sdklayers-id3d12infoqueue
As far as I can tell it's currently not possible to set a callback, which means that you'll need to explicitly query for feedback.
There are two different sources of error/status information involved here. The error code you have returned from the API call is E_INVALIDARG and you obtained a good string for it. This is the status code from the API.
The descriptive message you see in debug output is emitted by Direct3D 12 debug layer, which you loaded during API initialization. It is, generally speaking, an optional component and might be not available in the system while the API itself is available.
To intercept debug output programmatically you can either
utilize this trick: Capture OutputDebugString output
or, attach as a debugger to your application and process debug output event recording the contents
When using opengl through lwjgl, when an opengl context is made unavailable by making no context current (using glfwMakeContextCurrent(0)), the opengl calls all return 0 as a result. This can lead to unexpected results and it is often hard to see where the problem is. Is there any way of telling when a context is switched using a callback or something, so that a proper error can be filed?
As far as I can tell, the lwjgl library uses several different APIs', including GLFW. If you are using the GLFW API to create contexts(or the library is, which it looks like it from their website), then you can request to receive the window that the context is currently bound to using:
glfwGetCurrentContext();
If this returns NULL, it is probably not currently bound to any window. You could implement this function in a glfwPollEvents() style callback(or something similar), and output an error message when it checks the contexts status.
I'm running a VB6 app in WINE and the OpenGL portion of the program doesn't work. It is using PFD_DRAW_TO_BITMAP. PFD_DRAW_TO_WINDOW formats seem to work.
I've enumerated all the pixel formats (there are around 256) and a few of them match what I request. ChoosePixelFormat seems to return a correct format (in this case pixelFormat 6), but when I pass this value into SetPixelFormat it returns 0. I looked at the documentation and it says to check GetLastError() for more information, but when I call that, it returns 0 which formats to a blank error message.
Does anyone know anyway to figure out why SetPixelFormat would fail? I've done some reading and it sounds like DRAW_TO_BITMAP has been implemented since like May 2009.
I know DRAW_TO_BITMAP is not hardware accelerated. That is perfectly acceptable. This app works fine in Windows, -- I just need to figure out why a supported pixel format doesn't seem to get recognized.
I'm running Ubuntu, most recent version of WINE in their package manager, -- on a Quadro if that matters (not sure if Wine attempts to use the underlying graphics card or if it virtualizes all the pixel formats for software rendering)
I don't know why SetPixelFormat would be failing only on WINE, but it is in any case incorrect to call GetLastError manually from VB6 code. VB makes its own DLL calls behind the scenes. These will (generally) succeed, resetting the error code seen by GetLastError and making it useless from VB code.
Instead, VB calls GetLastError itself immediately after every user-initiated DLL call. It saves the value and makes it available as the property Err.LastDllError. Use that to find out the real error code.
My application is reading/writing data to a removable media (USB DOK) in the background. The problem is that when the USB is removed while the app is working, the computer pops up an error message:
Wrong Volume
The wrong volume is in the drive. Please insert volume into drive E:.
Cancel Try Again Continue
This happens during operations such as GetFileSize, ReadFile. Obviously, since the app is supposed to work in the background, I would like to suppress those messages and fail silently.
BTW - It seems that the process giving those message is not my process, but CSRSS.EXE (although the cause is definitely the operation from my process).
One direction I am considering is switching to NtQueryInformationFile, NtReadFile, etc., but I'd rather not...
Thanks
Try calling:
SetErrorMode(SEM_NOOPENFILEERRORBOX);
At the beginning of your main function.
From the documentation:
The system does not display a message box when it fails to find a file. Instead, the error is returned to the calling process.
I suggest you properly disconnect your hardware using the icon in the windows system tray so that it's not being accessed when you pull it out of the drive. Or at least exit your ap first.
I am getting error on debugger:
cocos2d: CCTexture2D. Can't create Texture. UIImage is nil
cocos2d: Couldn't add image:bg.png in CCTextureCache
* Assertion failure in -[StartTrain addChild:z:tag:], /Users/nishant/Downloads/AnimBear 2/libs/cocos2d/CCNode.m:370
* Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Argument must be non-nil'
An Application runs on simulator but not on actual device.
please help.. :(
Is your device an iPhone 4? Someone on the cocos2d-iphone forums had a similar problem; this thread documents what he tried and what ended up solving the problem. It's possible that the hd version of the image you are trying to load is too large or is not in the correct format.
If you are running 0.99.5 rc1, you may also want to upgrade to the release version of 0.99.5, as mentioned in this thread about another similar problem.
I had a similar problem, the name of the file was correct, format was correct (was .png) and I had cleaned in xcode and deleted the app from my iphone, yet I still had the error.
As someone else said in the comment, the size of the sprite just might be too large (depending on your memory usage). For me I had all sorts of sprites and stuff flying over the screen. So I resized it and it currently runs perfect.
Also I was using a iPhone 3G.