How I can preload updated managed 2D texture to GPU memory in Direct3D11?
In Direct3D9 I called IDirect3DBaseTexture9::PreLoad to guarantee that texture will be ready for rendering.
Direct3D9Ex and Direct3D 10 through DirectX 12 has no concept of D3DPOOL_MANAGED. This is because these versions of Direct3D do not have "lost device" in the sense that Direct3D 9 did. They only have "device removed" which happens when the GPU crashes or the driver is updated while your game/app is running. See Microsoft Docs.
Starting in Windows Vista, Video Memory is managed by the OS. Textures are paged in and out of video memory, and backed by system memory automatically. You can provide hints by using the SetEvictionPriority method.
Related
I have 8GB or Vram (Gpu) & 16GB of Normal Ram when allocating (creating) many lets say large 4096x4096 textures i eventual run out of Vram.. however from what i can see it then create it on ram instead.. When ever you need to render (with or to) it .. it seams to transfer the render-context from the ram to vram in order to do so. Running normal accessing many render-context over and over every frame (60fps etc) the pc lags out as it tries to transfer very high amounts back and forth. However so long the amount of new (not recently used render-contexts (etc still on ram not vram)) is references each second.. there should not be a issue (performance wise). The question is if this information is correct?
DirectX will allocate DEFAULT pool resources from video RAM and/or the PCIe aperture RAM which can both be accessed by the GPU directly. Often render targets must be in video RAM, and generally video RAM is faster memory--although it greatly depends on the exact architecture of the graphics card.
What you are describing is the 'over-commit' scenario where you have allocated more resources than actually fit in the GPU-accessible resources. In this case, DirectX 11 makes a 'best-effort' which generally involves changing virtual memory mapping to get the scene to render, but the performance is obviously quite poor compared to the more normal situation.
DirectX 12 leaves dealing with 'over-commit' up to the application, much like everything else about DirectX 12 where generally "runtime magic behavior" has been removed. See docs for details on this behavior, as well as this sample
When using CreateBitmapFromWicBitmap() I can see the GPU memory usage increase.
The code looks like:
hr = pRenderTarget->CreateBitmapFromWicBitmap(pImagePoolEntry->pConverter,
NULL, pImagePoolEntry->pPoolImage.GetAddressOf());
pPoolImage is defined as ComPtr<ID2D1Bitmap> pPoolImage;
The pPoolImage pointer hangs around for the life of using the image, when done and the pPoolImage is released I do not see the GPU memory usage decrease.
So is there a way to have the GPU release the image data? or should I not be worried. The only time I see the usage drop is when the application is terminated.
Note: I'm using GPU-Z to monitor the GPU memory usage.
Thanks
DirectX video memory destruction is deferred. You can explicitly use IDXGIDevice3::Trim, but generally it doesn't matter in real-world cases.
See MSDN
I have a USB3 camera, and I need to have the captured images to be loaded into DirectX texture. Currently I'm just doing it in my code in the user mode - grab images and upload them to GPU, which is, of cause, certain overhead on CPU and delay of ~5-7 milliseconds.
On a new PC there's Nvidia Quadro GPU card, which supports GPUDirect, as I understand, this allows faster memory sharing between the GPU and the CPU, but I'm not sure how can I take advantage of it. In order to capture the images directly to GPU buffers, does the camera driver need to support it? Or it's something I can configure in my code?
Your premise is wrong
as I understand, this allows faster memory sharing between the GPU and
the CPU
GPUDirect is NVIDIA Technology to support PCI to PCI transfers between devices and not between CPU and GPU. In fact it removes a CPU copy while transferring data between 2 PCI devices.
For utilizing GPUDirect in your case you need to have a capture card which will be connected via PCI (your camera will be connected to capture card). Then you can transfer frames Directly to GPU.
Can't comment if it will be faster than USB transfer.
Is it possible to store the display list data on the video card memory?
I want to use only video memory like Video Buffer Object(VBO) to store DisplayList.
But when I try it, it always uses main memory instead of video memory.
I tested on nVidia geForce 8600GTS, and GTX260.
Display lists are a very old feature, that dates back to OpenGL-1.0. They have been depreceated a long time ago. Anyhow you can still use them for compatibility reasons.
The way OpenGL works, prevents display lists from being held in GPU memory only. The graphics server (as OpenGL calls it) is a purely abstract thing, and the specification warrants, that what you put in a display lists is always available. However in modern GPUs there's only a limited amount of memory, so payload data may be swapped in and out as needed.
Effectively GPU memory is a cache for data in system RAM (the same way system RAM should be treaded as cache for storage).
Even moreso, modern GPUs may crash, and the drivers will perform a full reset giving the user the impression everything works normal. But after the reset all the data on GPU memory must be reinitialized.
So it is necessary for OpenGL to keep copies of every payload data in memory to support smooth operation.
Hence it is perfectly normal for your data to show up as consuming system RAM as well. It is though very likely, that the display lists are also cached in GPU memory.
Display Lists are deprecated. You can use VBO with vertex indices to use graphics memory, and draw it with glDrawElements.
The OpenGL ES Driver Instrument in XCode 4 no longer has Tiler and Renderer Utilization, the two most useful statistics for measuring OpenGL ES bottlenecks. Did they get renamed? I noticed there are two new measurable stats, GPU Core Utilization and GPU Video Engine Utilization; do these now track tiling an rendering utilization, respectively?
As it turns out, the latest version of XCode (4.2) restored Tiler and Renderer Utilization to Instruments. I believe they were only missing during the initial release of XCode 4.