- 19 Dec, 2018 40 commits
-
-
Caio Oliveira authored
When copy propagation handles a store/copy, it iterates the current copy entries to remove aliases, but keeps the "equal" entry (if exists) to be updated. The removal step may swap the entries around (to ensure there are no holes), invalidating previous iteration pointers. The bug was saving such pointer to use later. Change the code to first perform the removals and then find the remaining right entry. This was causing updates to be lost since they were being made to an entry that was not part of the current copies. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108624 Fixes: b3c61469 "nir: Copy propagation between blocks" Cc: mesa-stable@lists.freedesktop.org Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net>
-
Fixes build failure if the LLVM headers aren't in a standard include directory. Fixes: ec22dd34 "radeonsi: move SI_FORCE_FAMILY functionality to winsys" Reviewed-by:
Nicolai Hähnle <nicolai.haehnle@amd.com>
-
Caio Oliveira authored
When updating a copy entry source value from a "non-SSA" (the data come from a copy instruction) to a "SSA" (the data or parts of it come from SSA values), it was possible to hold invalid data in ssa[0] depending on the writemask. Because the union, ssa[0] could contain a pointer to a nir_deref_instr left-over from previous non-SSA usage. Change code to clean up the array before use to avoid invalid data around. Fixes: 62332d13 "nir: Add a local variable-based copy propagation pass" Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net>
-
Eric Engestrom authored
Signed-off-by:
Eric Engestrom <eric.engestrom@intel.com>
-
Eric Engestrom authored
Signed-off-by:
Eric Engestrom <eric.engestrom@intel.com> Reviewed-by:
Dylan Baker <dylan@pnwbakers.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com>
-
We can remove some duplicated code. Reviewed-by:
Elie Tournier <elie.tournier@collabora.com>
-
A resource is just a buffer with some metadata. Reviewed-by:
Elie Tournier <elie.tournier@collabora.com>
-
Previously, we ignored the the glUnmap(..) operation and flushed before we flush the cbuf. Now, let's just flush the data when we unmap. Neither method is optimal, for example: glMapBufferRange(.., 0, 100, GL_MAP_FLUSH_EXPLICIT_BIT) glFlushMappedBufferRange(.., 25, 30) glFlushMappedBufferRange(.., 65, 70) We'll end up flushing 25 --> 70. Maybe we can fix this later. v2: Add fixme comment in the code (Elie) Reviewed-by:
Elie Tournier <elie.tournier@collabora.com>
-
We can reuse the helpers we created. Reviewed-by:
Elie Tournier <elie.tournier@collabora.com>
-
util_format_get_blocksize returns 1 for R8 formats (all PIPE_BUFFERs are R8). Reviewed-by:
Elie Tournier <elie.tournier@collabora.com>
-
We could allocate and destroy transfers in one place. v2: Keep l_stride around. Reviewed-by:
Elie Tournier <elie.tournier@collabora.com>
-
Reviewed-by:
Elie Tournier <elie.tournier@collabora.com>
-
Will be reused. Reviewed-by:
Elie Tournier <elie.tournier@collabora.com>
-
Will be reused. Reviewed-by:
Elie Tournier <elie.tournier@collabora.com>
-
Will be reused. Reviewed-by:
Elie Tournier <elie.tournier@collabora.com>
-
With commit 89b479, we moved to tracking buffer cleanliness when binding. TEST=dEQP-GLES31.functional.image_load_store.buffer.load_store.r32ui Reviewed-by:
Elie Tournier <elie.tournier@collabora.com>
-
It's used for all types of resources. Reviewed-by:
Elie Tournier <elie.tournier@collabora.com>
-
Nicolai Hähnle authored
Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Remove a level of indirection to make the code more explicit -- should make it easier to follow what's going on. Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
This is a move towards using composition instead of inheritance for different query types. This change weakens out-of-memory error reporting somewhat, though this should be acceptable since we didn't consistently report such errors in the first place. Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Other callers of si_set_constant_buffer don't need it. Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Reduce the number of places that encode buffer descriptors. Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
This is rather important for merged VS/TCS as LSHS shaders... Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
There is never a read-after-write hazard because the command doesn't read. Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Prepare for some later refactoring. Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
This helps some debugging cases by initializing addrlib with slightly more appropriate settings. Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Allow for a unified but efficient treatment of adding a bitmask over a wave or an entire threadgroup. Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Order-aware scan/reduce can trade-off LDS traffic for external atomics memory traffic in producer/consumer compute shaders. Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Nicolai Hähnle authored
This happened to bite me while doing some experiments. Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-