The previous algorithm had a race because of the way we were using
__sync_fetch_and_add for everything. In particular, the concept of
"returning" over-allocated states in the "next > end" case was completely
bogus. If too many threads were hitting the state pool at the same time,
it was possible to have the following sequence:
A: Get an offset (next == end)
B: Get an offset (next > end)
A: Resize the pool (now next < end by a lot)
C: Get an offset (next < end)
B: Return the over-allocated offset
D: Get an offset
in which case D will get the same offset as C. The solution to this race
is to get rid of the concept of "returning" over-allocated states.
Instead, the thread that gets a new block simply sets the next and end
offsets directly and threads that over-allocate don't return anything and
just futex-wait. Since you can only ever hit the over-allocate case if
someone else hit the "next == end" case and hasn't resized yet, you're
guaranteed that the end value will get updated and the futex won't block
forever.
We have pools, so we should be using them. Also, I think this will help
keep valgrind from getting confused when we have to end up fighting with
system allocations such as those from malloc/free and mmap/munmap.
Figuring out whether or not to do a copy requires knowing the length of the
final batch_bo. This gets set by anv_batch_bo_finish so we have to do it
afterwards. Not sure how this was even working before.
Previously, the command buffer implementation was split between
anv_cmd_buffer.c and anv_cmd_emit.c. However, this naming convention was
confusing because none of the Vulkan entrypoints for anv_cmd_buffer were
actually in anv_cmd_buffer.c. This changes it so that anv_cmd_buffer.c is
what you think it is and the internals are in anv_batch_chain.c.
Previously, the caller of emit_state_base_address was doing this. However,
putting it directly in emit_state_base_address means that we'll never
forget the flush at the cost of one PIPE_CONTROL at the top every batch
(that should do nothing since the kernel just flushed for us).
This is more generic and doesn't imply that it emits MI_BATCH_BUFFER_END.
While we're at it, we'll move NOOP adding from bo_finish to
end_batch_buffer.
Instead of walking the list of batch and surface buffers, we simply keep
track of all known batch and surface buffers as we build the command
buffer. Then we use this new list to construct the validate list.
The algorighm we used previously required us to call add_bo in a particular
order in order to guarantee that we get the initial batch buffer as the
last element in the validate list. The new algorighm does a recursive walk
over the buffers and then re-orders the list. This should be much more
robust as we start to add circular dependancies in the relocations.
Before, we were doing this thing where we had one big relocation list for
the whole command buffer and each subbuffer took a chunk out of it. Now,
we store the actual relocation list in the anv_batch_bo. This comes at the
cost of more small allocations but makes a lot of things simpler.
Previously anv_batch.relocs was an actual relocation list. However, this
is limiting if the implementation of the batch wants to change the
relocation list as the batch progresses.
This update fixes cases where a 48-bit address field was split into
two parts:
__gen_address_type MemoryAddress;
uint32_t MemoryAddressHigh;
which cases this pack code to be generated:
dw[1] =
__gen_combine_address(data, &dw[1], values->MemoryAddress, dw1);
dw[2] =
__gen_field(values->MemoryAddressHigh, 0, 15) |
0;
which breaks for addresses above 4G.
This update also fixes arrays of structs in commands and structs, for
example, we now have:
struct GEN8_BLEND_STATE_ENTRY Entry[8];
and the pack functions now write all dwords in the packet, making
valgrind happy.
Finally, we would try to pack 64 bits of blend state into a uint32_t -
that's also fixed now.
Previously, we were crawling through the anv_cmd_buffer datastructure to
pull out batch buffers and things. This meant that every time something in
anv_cmd_buffer changed, we broke aub dumping. However, aub dumping should
just dump the stuff the kernel knows about so we really don't need to be
crawling driver internals.
This used to happen magically in cmd_buffer_new_surface_state_bo. However,
according to Ken, STATE_BASE_ADDRESS is very gen-specific so we really
shouldn't have it in the generic data-structure code.
The CTS passes in NULL names right now. It's not too hard to support that
as just "main". With this, and a patch to vulkancts, we now pass all 6
tests.
Jason started the task by creating anv_cmd_buffer.c and anv_cmd_emit.c.
This patch finishes the task by renaming all other files except
gen*_pack.h and glsl_scraper.py.
This completes the FINISHME to trim unneeded data from anv_buffer_view.
A VkExtent3D doesn't make sense for a VkBufferView.
So remove the member anv_surface_view::extent, and push it up to the two
objects that actually need it, anv_image_view and anv_attachment_view.
This removes nearly all the remaining raw Anvil<->Vulkan casts from the
C source files. (File compiler.cpp still contains many raw casts, and
I plan on ignoring that).
As far as I can tell, the only remaining raw casts are:
anv_attachment_view -> anv_depth_stencil_view
anv_attachment_view -> anv_color_attachment_view
