The OpenGL has its description about this, but how about DirectX?
In my guess, the sample result is float(0, 0, 0, 0), or arise a crash by the driver. Whatever, it just my guess, or partial case if tested it myself only. I want to make it clear.
The uninitialized texture means, did not pass any data with D3DDevice::CreateTexture2D(), and also, did not map nor update resource.
I want to take the description about DirectX 11 version if possible.
From the Create2DTexture function (that you linked):
If you don't pass anything to pInitialData, the initial content of the memory for the resource is undefined. In this case, you need to write the resource content some other way before the resource is read.
Undefined can mean anything, the driver will determine the exact behavior. It's unlikely that it will crash, but as with undefined behavior, anything is possible. A sample from this texture is certainly not guaranteed to be float4(0,0,0,0) as it is with an unbound texture.
It's analogous to accessing uninitialized system memory. The contents might be filled memory written from previous operations that had allocated the same memory (depending on the allocator's behavior). I would suggest if you want consistent behavior, either use an unbound texture instead, or, initialize the contents.
Yes you get 0 for all values its the same if you sample from a null texture.
I cant remember where it was that I read it but I know its in the MSDN doc, I also happen to do this from time to time because I allocate most of the textures\buffers\views at the start and fill as I go and if I sample from null or uninitialized then it just read 0.
Related
In vulkan.h, every instance of VkAccessFlagBits appears in a pair that contains a srcAccessMask and a dstAccessMask:
VkAccessFlags srcAccessMask;
VkAccessFlags dstAccessMask;
In every case, according to my understanding, the purpose of these masks is to help designate two sets of operations, such that results of operations in the first set will be visible to operations in the second set. For instance, write operations occurring prior to a barrier should not get hung up in caches but should instead propagate all the way to locations from which they can be read after the barrier. Or something like that.
The access flags come in both READ and WRITE forms:
/* ... */
VK_ACCESS_SHADER_READ_BIT = 0x00000020,
VK_ACCESS_SHADER_WRITE_BIT = 0x00000040,
VK_ACCESS_COLOR_ATTACHMENT_READ_BIT = 0x00000080,
VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT = 0x00000100,
/* ... */
But it seems to me that srcAccessMask should probably always be some sort of VK_ACCESS_*_WRITE_BIT combination, while dstAccessMask should always be a combination of VK_ACCESS_*_READ_BIT values. If that is true, then the READ/WRITE distinction is identical to and implicit in the src/dst distinction, and so it should be good enough to just have VK_ACCESS_SHADER_BIT etc., without READ_ or WRITE_ variants.
Why are there READ_ and WRITE_ variants, then? Is it ever useful to specify that some read operations must fully complete before some other operations have begun? Note that all operations using VkAccessFlagBits produce (I think) execution dependencies as well as memory dependencies. It seems to me that the execution dependencies should be good enough to prevent earlier reads from receiving values written by later writes.
While writing this question I encountered a statement in the Vulkan specification that provides at least part of an answer:
Memory dependencies are used to solve data hazards, e.g. to ensure that write operations are visible to subsequent read operations (read-after-write hazard), as well as write-after-write hazards. Write-after-read and read-after-read hazards only require execution dependencies to synchronize.
This is from the section 6.4. Execution And Memory Dependencies. Also, from earlier in that section:
The application must use memory dependencies to make writes visible before subsequent reads can rely on them, and before subsequent writes can overwrite them. Failure to do so causes the result of the reads to be undefined, and the order of writes to be undefined.
From this I surmise that, yes, the execution dependencies produced by the Vulkan commands that involve these access flags probably do free you from ever having to put a VK_ACCESS_*_READ_BIT into a srcAccessMask field--but that you might in fact want to have READ_ flags, WRITE_ flags, or both in some of your dstAccessMask fields, because apparently it's possible to use an explicit dependency to prevent read-after-write hazards in such a way that write-after-write hazards are NOT prevented. (And maybe vice-versa?)
Like, maybe your Vulkan will sometimes decide that a write does not actually need to be propagated all the way through a particular cache to its final specified destination for the sake of a subsequent read operation, IF Vulkan happens to know that that read operation will simply read from that same cache, saving some time? But then a second write might happen, and write to a different cache, and there'll be two caches left in a race (with the choice of winner undefined) to send their two values to the same spot. Or something? Maybe my mental model of these caches is entirely wrong.
It is fairly solidly established, at least, that memory barriers are confusing.
Let's go over all the possibilities:
read–read — well yeah that one is pretty useless. Khronos seems to agree #131 it is pointless value in src (basically equivalent to 0).
read–write — execution dependency should be sufficient to synchronize without this. Khronos seems to agree #131 it is pointless value in src (basically equivalent to 0).
write–read — that's the obvious and most common one.
write–write — similar reason to write–read above. Without it the order of the writes would be undefined. It is a bit pointless for most situations to write something you haven't even read in between. But hey, now you have a way to synchronize it.
You can provide bitmask of more of these masks to both src and dst. In which case it makes sense to have both masks for driver to sort the dependencies out for you. (I don't expect performance overhead from this on API level, so it is allowed as convenience)
From API design perspective, it could mean adding different enum for srcAccess. But perhaps _READ variants could just be forbidden in srcAccess through "Valid Usage", making this argument weak. The src == READ variant might have been kept, because it is benign.
So I have recently started using SharpDX, and have stumbled into a problem. I have no idea how to get SharpDX to multisample. I have found two things related; you can specify a SampleDescription when creating the SwapChainDescription, but any input other than (1, 0) throws a Wrong Parameter exception.
The other thing I found was SamplerState, which I put on my pixel shader, didn't do anything. I played around a lot with the parameters, but there was no visible change whatsoever.
I am sure I am missing something, but without any previous directX knowlegde I have no idea really what exactly to look for.
This will come in handy in your case:
int maxsamples = Device.MultisampleCountMaximum;
int res = device.CheckMultisampleQualityLevels(SharpDX.DXGI.Format.R8G8B8A8_UNorm, samplecount);
If res returns 0 then this Sample count is not supported.
Also please note that some options are not compatible, so if you create your SwapChain with:
sd.Usage = (other usages) | Usage.UnorderedAccess;
You are not allowed to use multisampling.
Another very useful technique to spot the problems for those errors:
Create your device with DeviceCreationFlags.Debug
In your startup project properties (debug section), tick "Enable native code debugging".
Any API call that fails will give you an error description in the debug output window.
I had the same problem, could not get Multisampling to work until I enabled the debugging and got a good hint (really wished I had done this hours ago and saved a whole lot of testing!).
Initially I read somewhere that the DepthStencilBuffer had the same SampleDescription as the Render texture - but I'm not so sure as it appears to work without this as a quick test just showed.
The thing for me was to create the DepthStencilView with a DepthStencilViewDescription that has "Dimension = DepthStencilViewDimension.Texture2DMultisampled".
Just a heads up on when you are doing multisampling.
When you set your rendertarget, if passing a rendertarget and depthstencil, you need to ensure they both have the same multisampling level.
So, for rendering to the backbuffer you have defined with MSAA, you will need to create a depth buffer with the same MSAA level.
BUT, if you are have a rendertarget that will be a texture that is fed back into the pipeline, you can define a non MSAA texture and a NON MSAA depth buffer, which is handy as you can use a sampler on the texture (you cant use a normal sampler for a MSAA Resource texture).
Most of this info maybe not new for you.
Now I can get backbuffer pointer called pBackBuffer by
m_pDevice->GetBackBuffer(0, 0, D3DBACKBUFFER_TYPE_MONO,
IREF_GETPPTR(pBackBuffer,IDirect3DSurface9));
And then create a surface called pSurfTemp in syetem memory by
m_pDevice->CreateOffscreenPlainSurface(
g_Proc.m_Stats.m_SizeWnd.cx, g_Proc.m_Stats.m_SizeWnd.cy,
s_bbFormat, D3DPOOL_SYSTEMMEM,
IREF_GETPPTR(pSurfTemp,IDirect3DSurface9), NULL );
Then I get the back buffer data by
m_pDevice->GetRenderTargetData(pBackBuffer, pSurfTemp);
Data seems transforming like this: videoMemory->systemMemory
Since next step is to operate the data in video memory again, it will copy it from system memory back into video memory. It wastes time.
I want to copy the data inside video memory, How can I do it?
If I understood right, you will want to CreateOffscreenPlainSurface() with D3DPOOL_DEFAULT flag, so driver will choose appropriate memory location automatically. But it never guaranteed that it always will be videocard's on-board memory.
By the way, premature optimization is the root of all evil. =)
Edit: Another option is to switch API from DirectX 9 (which is obsolete) to DirectX 11, which allows much more precise resources manipulations. Also, OpenGL goes somewhere in between. Both, is a huge code rewrite.
I'm encountering this error when I'm running my DirectX10 program in debug mode:
D3D10: WARNING: ID3D10Buffer::SetPrivateData: Existing private data of same name with different size found! [ STATE_SETTING WARNING #55: SETPRIVATEDATA_CHANGINGPARAMS ]
I'm trying to make the project highly OOP as a learning exercise, so there's a chance that this may be occurring, but is there a way to get some more details?
It appears this warning is raised by D3DX10CreateSprite, which is internally called by font->DrawText
You can ignore this warning, seems to be a bug in the Ms code :)
Direct3D11 doesn't have built-in text rendering anymore, so you won't encounter it in the future.
Since this is a D3D11 warning, you could always turn it off using ID3D11InfoQueue:
D3D11_MESSAGE_ID hide [] = {
D3D11_MESSAGE_ID_SETPRIVATEDATA_CHANGINGPARAMS,
// Add more message IDs here as needed
};
D3D11_INFO_QUEUE_FILTER filter;
memset(&filter, 0, sizeof(filter));
filter.DenyList.NumIDs = _countof(hide);
filter.DenyList.pIDList = hide;
d3dInfoQueue->AddStorageFilterEntries(&filter);
See this page for more. I found your question while googling for the answer and had to search a bit more to find the above snippet, hopefully this will help someone :)
What other data are you looking for or interested in?
The warning is pretty clear about what is going on, but if you want to hunt down a bit more data, there may be a few things to try.
Try calling ID3D10Buffer::GetPrivateData with the same name or do some other check to see if there is data with that name already, and if so, what the contents are. Print your results to a file, output window, or console. This may be combined with breakpoints to see where the duplicate is occurring (break when there's already data).
You may (not positive) be able to set the D3D runtimes to debug mode and to break on warnings (not sure if it can do warnings or just errors). Debug your app in VS or your preferred debugger, and when the warning is shown, it will break and you can look at the parameters.
Go through your code and track down all calls to ID3D10Buffer::SetPrivateData and look to see if there are any obvious duplicates. If there are, work up the program flow and see why and what you can do about them (this may work best after you use one of the former methods to know where to start).
How are your data names set up, and what is the buffer used for? Examining one or both may lead you to a conflict somewhere.
You may also try unicorns, they've been known to help with this kind of problem.
we just came across a peculiar behaviour of the TFileStream.Seek (actually that method is inherited from THandleStream) in Delphi 2007:
You can seek beyond the end of file without an error and after the seek you can even read from the file without an error.
The code does basically just call the Windows API function SetFilePointer and seems to do proper error handling. Can somebody explain what's happening here?
The MSDN documentation for SetFilePointer states:
It is not an error to set a file
pointer to a position beyond the end
of the file. The size of the file does
not increase until you call the
SetEndOfFile, WriteFile, or
WriteFileEx function. A write
operation increases the size of the
file to the file pointer position plus
the size of the buffer written, which
results in the intervening bytes
uninitialized.
This is how the file system is designed to work.
Afaik this behaviour (seek beyond end, write block there) is needed to support NTFS sparse files.