| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Shader hashing is very closely related to shader compilation. Putting
them right next to each other in anv_pipeline makes it easier to verify
that we're actually hashing everything we need to be hashing. The only
real change (other than the order of hashing) is that we now hash in the
shader stage.
Reviewed-by: Iago Toral Quiroga <[email protected]>
|
| |
|
|
|
|
|
| |
We're about to have more UUIDs for different things so this one really
needs to be properly labeled.
Reviewed-by: Chad Versace <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This situation can happen if we failed to allocate memory for the shader.
v2:
- We shouldn't see NULL shaders in anv_shader_bin_ref so we should not check
for that (Jason). Make sure that callers don't attempt to call this
function with a NULL shader and assert that this never happens (Iago).
v3:
- All callers to anv_shader_bin_unref seem to check for NULL before calling,
so just assert that it is not NULL (Topi)
Reviewed-by: Topi Pohjolainen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Rather than having an extra memory allocation [that we currently do not
and act accordingly] just make the API take an pointer to a stack
allocated instance.
This and follow-up steps will effectively make the _mesa_sha1_foo simple
define/inlines around their SHA1 counterparts.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Grazvydas Ignotas <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
Port of an equivalent commit for radv.
v2: Move the call just after MMAP_VERSION (Ken).
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This fixes a bunch of new CTS tests which look for exactly this. Even in
the cases where we just call vk_free to free a CPU data structure, we still
handle NULL explicitly. This way we're less likely to forget to handle
NULL later should we actually do something less trivial.
Cc: "13.0" <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Before we were caching the prog data but we weren't doing anything with
brw_stage_prog_data::param so anything with push constants wasn't getting
cached properly. This commit fixes that.
Signed-off-by: Jason Ekstrand <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98012
Reviewed-by: Timothy Arceri <[email protected]>
Cc: "13.0" <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While we can simply calculate offsets to get to things such as the
prog_data and the key, it's much more user-friendly if there are just
pointers. Also, it's a bit more fool-proof.
While we're at it, we rework the pipeline cache API to use the
brw_stage_prog_data type directly.
Signed-off-by: Jason Ekstrand <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98012
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
Cc: "13.0" <[email protected]>
|
| |
|
|
|
|
|
| |
This moves all the alloc/free in anv to the generic helpers.
Acked-by: Jason Ekstrand <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the spec - 9.6. Pipeline Cache :
If pDataSize is less than the maximum size that can be retrieved by the
pipeline cache, at most pDataSize bytes will be written to pData, and
vkGetPipelineCacheData will return VK_INCOMPLETE.
Fixes the following test from Vulkan CTS :
dEQP-VK.pipeline.cache.pipeline_from_incomplete_get_data.vertex_stage_fragment_stage
dEQP-VK.pipeline.cache.pipeline_from_incomplete_get_data.vertex_stage_geometry_stage_fragment_stage
dEQP-VK.pipeline.cache.misc_tests.invalid_size_test
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original pipeline cache the Kristian wrote was based on a now-false
premise that the shaders can be stored in the pipeline cache. The Vulkan
1.0 spec explicitly states that the pipeline cache object is transiant and
you are allowed to delete it after using it to create a pipeline with no
ill effects. As nice as Kristian's design was, it doesn't jive with the
expectation provided by the Vulkan spec.
The new pipeline cache uses reference-counted anv_shader_bin objects that
are backed by a large state pool. The cache itself is just a hash table
mapping keys hashes to anv_shader_bin objects. This has the added
advantage of removing one more hand-rolled hash table from mesa.
Signed-off-by: Jason Ekstrand <[email protected]>
Cc: "12.0" <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97476
Acked-by: Kristian Høgsberg Kristensen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new anv_shader_bin struct stores the compiled kernel (as an anv_state)
as well as all of the metadata that is generated at shader compile time.
The struct is very similar to the old cache_entry struct except that it
is reference counted and stores the actual pipeline_bind_map. Similarly to
cache_entry, much of the actual data is floating-size and stored after the
main struct. Unlike cache_entry, which was storred in GPU-accessable
memory, the storage for anv_shader_bin kernels comes from a state pool.
The struct itself is reference-counted so that it can be used by multiple
pipelines at a time without fear of allocation issues.
Signed-off-by: Jason Ekstrand <[email protected]>
Cc: "12.0" <[email protected]>
Acked-by: Kristian Høgsberg Kristensen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The pipeline layout affects shader compilation because it is what
determines binding table locations as well as whether or not a particular
buffer has dynamic offsets. Since this affects the generated shader, it
needs to be in the hash. This fixes a bunch of CTS tests now that the CTS
is using a pipeline cache.
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
Cc: "12.0" <[email protected]>
|
| |
|
|
|
|
|
| |
This gets ANV_ENABLE_PIPELINE_CACHE=false working again.
Signed-off-by: Jason Ekstrand <[email protected]>
Cc: "12.0" <[email protected]>
|
| |
|
|
|
| |
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
|
| |
|
|
|
| |
Move the environment variable check to cache creation time so we block
both lookups and uploads if it's turned off.
|
| |
|
|
|
|
|
| |
Between the initial check the returns NO_KERNEL and compiling the
shader, other threads may have added the shader to the cache. Before
uploading the kernel, check again (under the mutex) that the compiled
shader still isn't present.
|
| |
|
|
|
| |
This is state the we generate when compiling the shaders and we need it
for mapping resources from descriptor sets to binding table indices.
|
| |
|
|
|
|
|
| |
Using anv_pipeline_cache_upload_kernel() will re-upload the kernel and
prog_data when we merge caches. Since the kernel and prog_data is
already in the program_stream, use anv_pipeline_cache_add_entry()
instead to only add the entry to the hash table.
|
| |
|
|
| |
This function will grow the cache to make room and then add the entry.
|
| |
|
|
|
|
| |
This function is a helper that unconditionally sets a hash table entry
and expects the cache to have enough room. Calling it 'add_entry'
suggests it will grow the cache as needed.
|
| |
|
|
|
| |
We have to keep it there for the cache to work, so let's not have an
extra copy in struct anv_pipeline too.
|
| |
|
|
| |
A little less ambiguous.
|
| |
|
|
|
|
| |
We can serialize as much as the application asks for and just stop once
we run out of memory. This lets applications use a fixed amount of
space for caching and still get some benefit.
|
| |
|
|
| |
The final version of the pipeline cache header adds a few more fields.
|
| |
|
|
|
| |
This was copied from inline code to a helper and wasn't updated to hash
a pointer instead.
|
| | |
|
| |
|
