| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
| |
Co-Authored-By: ReinUsesLisp <reinuseslisp@airmail.cc>
|
| |
|
|\
| |
| | |
maxwell_to_vk: Initial implementation
|
| | |
|
|/
|
|
|
|
|
|
|
| |
Removes a few unnecessary dependencies on core-related machinery, such
as the core.h and memory.h, which reduces the amount of rebuilding
necessary if those files change.
This also uncovered some indirect dependencies within other source
files. This also fixes those.
|
| |
|
|
|
|
|
| |
This buffer cache is just like OpenGL's buffer cache with some minor
style changes. It uses VKStreamBuffer.
|
|\
| |
| | |
vk_stream_buffer: Implement a stream buffer
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This manages two kinds of streaming buffers: one for unified memory
models and one for dedicated GPUs. The first one skips the copy from the
staging buffer to the real buffer, since it creates an unified buffer.
This implementation waits for all fences to finish their operation
before "invalidating". This is suboptimal since it should allocate
another buffer or start searching from the beginning. There is room for
improvement here.
This could also handle AMD's "pinned" memory (a heap with 256 MiB) that
seems to be designed for buffer streaming.
|
| | |
|
|/
|
|
|
| |
Reorders members in the order that they would actually be initialized
in. Silences a -Wreorder warning.
|
|\
| |
| | |
vk_scheduler: Implement a scheduler
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The scheduler abstracts command buffer and fence management with an
interface that's able to do OpenGL-like operations on Vulkan command
buffers.
It returns by value a command buffer and fence that have to be used for
subsequent operations until Flush or Finish is executed, after that the
current execution context (the pair of command buffers and fences) gets
invalidated a new one must be fetched. Thankfully validation layers will
quickly detect if this is skipped throwing an error due to modifications
to a sent command buffer.
|
|/
|
|
|
| |
VKMemoryCommitImpl was using as the end of its interval "begin + end".
That ended up wasting memory.
|
|
|
|
|
| |
A memory manager object handles the memory allocations for a device. It
allocates chunks of Vulkan memory objects and then suballocates.
|
| |
|
|
|
|
|
|
|
| |
Handles a pool of resources protected by fences. Manages resource
overflow allocating more resources.
This class is intended to be used through inheritance.
|
|
|
|
|
| |
CommitFence iterates a pool of fences until one is found. If all fences
are being used at the same time, allocate more.
|
|
|
|
|
|
| |
A fence watch is used to keep track of the usage of a fence and protect
a resource or set of resources without having to inherit from their
handlers.
|
|
|
|
|
|
|
|
|
|
| |
Fences take ownership of objects, protecting them from GPU-side or
driver-side concurrent access. They must be commited from the resource
manager. Their usage flow is: commit the fence from the resource
manager, protect resources with it and use them, send the fence to an
execution queue and Wait for it if needed and then call Release. Used
resources will automatically be signaled when they are free to be
reused.
|
|
|
|
|
| |
VKResource is an interface that gets signaled by a fence when it is free
to be reused.
|
|
|
|
|
|
|
| |
VKDevice contains all the data required to manage and initialize a
physical device. Its intention is to be passed across Vulkan objects to
query device-specific data (for example the logical device and the
dispatch loader).
|
|
This file is intended to be included instead of vulkan/vulkan.hpp. It
includes declarations of unique handlers using a dynamic dispatcher
instead of a static one (which would require linking to a Vulkan
library).
|