ID3D12GraphicsCommandList& commandList = *com_ptr;
FLOAT values[4] = { 1,1,1,1 };
commandList.ClearUnorderedAccessViewFloat(m_gpuUavHandle, m_cpuUavHandle, m_resource.get(), values, 0, nullptr);
I'm getting the following runtime error:
Access violation reading location 0x0000000000000140
However, m_cpuUavHandle.ptr has value 326 which is only 6 bytes after the location of the access violation 320 (=140 in hexidecimal).
Since in Direct3d12 you manually calculate the handle address, it seems that there is room for something to go wrong
m_cpuUavHandle = CD3DX12_CPU_DESCRIPTOR_HANDLE(m_descriptorHeap.get()->GetCPUDescriptorHandleForHeapStart(), offset, m_cbvSrvUavDescriptorSize);
Edit:
I succeeded reproducing this in the DirectX 12 samples (and uploaded it to github) and this time got a debug message
D3D12 ERROR: ID3D12CommandList::ClearUnorderedAccessViewFloat: Specified descriptor handle ptr=0x0000000000000021 points to a descriptor heap type that is CPU write only, so reading it is invalid. UnorderedAccessViewCPUHandle is the issue. [ EXECUTION ERROR #646: INVALID_DESCRIPTOR_HANDLE]
Now m_cpuUavHandle.ptr=33 and the location of the access violation is at 32 (0x0000000000000020 in hexidecimal).
In my main project I think the exception is hit before the debug message is printed due to threading issues.
Now in my main project I'm getting
Access violation reading location 0x0000000000000000.
which is still six bytes before m_cpuUavHandle.ptr = 6, so I'm not sure if this is right
mateeeeee solved this in the comments. The docs specify that the cpu descriptor must refer to a non-shader visible heap (one created with D3D12_DESCRIPTOR_HEAP_FLAG_NONE).
For me the solution is to just have two identical CBV_SRV_UAV heaps one created with D3D12_DESCRIPTOR_HEAP_DESC::Flags = D3D12_DESCRIPTOR_HEAP_FLAG_NONE for calling ClearUnorderedAccessViewFloat and the other created with D3D12_DESCRIPTOR_HEAP_DESC::Flags = D3D12_DESCRIPTOR_HEAP_FLAG_SHADER_VISIBLE for everything else.
It is important to note that the cpu descriptor and gpu descriptor arguments for ClearUnorderedAccessViewFloat must come from different heaps.
Related
I've been following this tutorial https://vulkan-tutorial.com/ to try and make a minecraft clone to learn how vulkan works. However, trying to create an ImageView results in "Access violation reading location 0x00000000000000F8" as can be seen here:
And here you can see that the vkCreateImageView function returns VK_SUCCESS
Initially I thought that the validation layer might be causing the exception, but removing the validation error leads to a "vector subscript out of range" error once the FrameBuffer creation tries to access the created ImageViews.
I have tried several things including: Having the VkImageView as a function variable and allocating it manually but they all result in the same Access Violation at 0x..F8. Compiling it in x86 just results in the Access Violation address changing to 0x000000A8.
I'm using the Vulkan SDK 1.0.65.1.
The Access Violation was being caused by MSI Afterburner / RivaTuner, stopping them makes the validation layers work properly again.
Source: https://vulkan-tutorial.com/FAQ
I am following a tutorial for building a DX11Engine on youtube and I have become stuck. I am trying to render a sprite to the screen but when I try to run it I am getting
Access violation reading location 0x00000000".
The problem is occurring at the line:
result = device->CreateVertexShader(vertexShaderBuffer->GetBufferPointer(), vertexShaderBuffer->GetBufferSize(), NULL, &m_vertexShader);
Which is in Shader.cpp.
I have uploaded my code on to Git Hub https://github.com/nowayout2k/PJTS-CPP-DX11Engine . Thanks for your help in advance!
Access violation at 0x00000000 sounds like you accessed a null pointer. It is possible that you attempted to call a virtual method on it, thus the process attempted to read the virtual table pointer at the beginning of the object and failed, because it would be the zero address.
Make sure that the variables device and vertexShaderBuffer aren't null pointers. If they are, it could indicate that an error occured at the time of their initialization.
I have an application that is starting to throw fits at various points. It was written ages ago using one of the first versions of the Qt library. Love to update it but that's not in the cards yet. While testing a part of the app, I received an unexpected crash:
Unhandled exception at 0x00a220db in MyApp.exe:
0xC0000005: Access violation reading location 0x00000000.
The application code that I can see (the Qt lib source code is not available for debugging so it's just a disassembly).
MyEvent myEvent = new MyEvent(str1, int, str2);
QApplication::postEvent(parent(), myEvent);
Call stack at the affected area:
MyApp.exe!QGList::append() + 0x6b bytes
MyApp.exe!QList<QPostEvent>::append() + 0x2f bytes
MyApp.exe!QApplication::postEvent() + 0x55a bytes
> MyApp.exe!SomeClass::writeTestName(const char * format=0x00f6c2b8, ...) Line 386 + 0x15 bytes
If I examine myEvent and parent(), both appear to be valid. What is the postEvent method adding my event to and, assuming it's a Qt internal, which it appears to be, why would it fail - is there some initialization that needs to be done that the original programmer might have missed?
I'm writing a pattern matching code using OpenCV with CUDA on Mac OS X. After ~ 70 frames, it slows down a lot. Using mach_absolute_time() I've been able to track the culprit (Initially I thought it was a disk access issue):
gpu::matchTemplate(currentFrame,
correlationTargets[i]->correlationImage,
temporaryImage,
CV_TM_CCOEFF_NORMED);
I believe this is caused by some memory issue inside matchTemplate. After a lot of search, I found the matchTemplateBuf structure which is presumably for memory reuse. Since the problem seems memory releated, I think using this may be the solution. However, the following code crashes:
gpu::MatchTemplateBuf mtBuff;
[...]
for(...) {
gpu::matchTemplate(correlationTargets[i]->croppedImage,
correlationTargets[i]->correlationImage,
correlationTargets[i]->maxAllocation,
CV_TM_CCOEFF_NORMED, mtBuff);
With error:
OpenCV Error: Gpu API call (Unknown error code [Code = 9999]) in convolve, file /Users/sermarc/Downloads/opencv-2.4-3.8/modules/gpu/src/imgproc.cpp, line 1431 libc++abi.dylib: terminating with uncaught exception of type cv::Exception: /Users/sermarc/Downloads/opencv-2.4-3.8/modules/gpu/src/imgproc.cpp:1431: error: (-217) Unknown error code [Code = 9999] in function convolve
I believe this is because the matchTemplateBuff is not properly initialized. However, I cannot find any information or example that shows it being set on a valid state.
The code works with:
gpu::matchTemplate(correlationTargets[i]->croppedImage,
correlationTargets[i]->correlationImage,
correlationTargets[i]->maxAllocation,
CV_TM_CCOEFF_NORMED);
I have a program that is creating a map file, its able to do that call just fine, m_hMap = CreateFileMapping(m_hFile,0,dwProtect,0,m_dwMapSize,NULL);, but when the subsequent function call to MapViewOfFile(m_hMap,dwViewAccess,0,0,0), I get an error code of 8, which is ERROR_NOT_ENOUGH_MEMORY, or error string "error Not enough storage is available to process this command".
So I'm not totally understanding what the MapViewOfFile does for me, and how to fix the situation.
some numbers...
m_dwMapSize = 453427200
dwProtect = PAGE_READWRITE;
dwViewAccess = FILE_MAP_ALL_ACCESS;
I think my page size is 65536
In case of very large file and to read it, it is recommended to read it in small pieces and then process each piece. And MapViewOfFile function is used to map a piece in memory.
Look at http://msdn.microsoft.com/en-us/library/windows/desktop/aa366761(v=vs.85).aspx need offset to do its job properly i.e. in case you want to read a very large file in pieces. Mostly due to fragmentation and related reason very large memory request fails.
If you are working on a 64 bit processor then the system will allocate a total of 4GB memory with bit set LargeaddressAware.
go to Configuration properties->linker->system. in Enable largeaddressware: check
Yes /LARGEADDRESSAWARE and check.