This keeps the directory structure a bit more organized:
- brw specific code
- elk specific code
- common NIR passes that could be used in both places
It also means that you can now 'git grep' in the brw directory without
finding a bunch of elk code, or having to "grep thing b*".
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37755>
We want to be able to emit load_reloc_const_intel intrinsics from common
NIR passes (such as printf lowering). In order to do that, we need to
have the enum with the meaning of values in common code. Once you have
that, it's easy to see the (identical) data structures as a way for the
driver to communicate about relocations, rather than a compiler backend
specific thing. So we move it all up to common code, and re-unify.
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37755>
This code was duplicated and with a assert mistake in one of the copies, so
here moving it to function and calling it from both places.
Also I have removed anv_shader_bin_rewrite_embedded_samplers() as it is already
being done in anv_shader_set_relocs().
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37749>
anv_state::offset in the context of anv_state_pool is equal to the offset from
the begining of block_pool + start_offset.
Like it is set in anv_state_pool_alloc_no_vg() in the path that allocs a new
block in anv_block_pool.
As anv_state_pool_return_chunk() expects only the offset from the begining of
anv_block_pool so here subtracting to make the path that grabs a larger chunk of
memory of the pool and split into smaler chunks to properly work.
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37669>
When the system is under memory pressure (which can happen, for
example, during CI runs), don't immediately give up the exec ioctl
(which, for Vulkan, will result in the device being declared lost).
Instead, retry a little bit just like we do for i915.ko.
This is a trade-off.
One of the reasons to *not* have unified behavior regarding ENOMEM
between i915.ko and xe.ko is the fact that xe.ko uses vm_bind, so if
the user tried to bind more memory than it is able to, we'll just keep
getting ENOMEM as long as we retry the ioctl. We now have a retry
limit, so we'll eventually return the error.
On the other hand, if the problem is other applications consuming all
the memory, having the retry loop may really help avoid unnecessarily
marking the device as lost, since one of our retries may eventually
succeed.
I believe the tradeoff of "we'll now eventually succeed in some cases
where it's possible to succeed, at the expense of retrying for a few
seconds until giving up in cases where we would never be able to
succeed" is an improvement.
If xe.ko ever gives us a way to differentiate between the two
different reasons for ENOMEM, we'll be able to make things much
better. We can also tune our timeouts if needed.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37559>
This reduces duplication: we only need to distinguish between Windows
and Unix in one place.
The previous code was inconsistent about using either the `platforms`
option, or the `host_machine`. Following the logic described in
commit 94379377 "lavapipe: build "Windows" check should use the host machine, not the `platforms` option.",
I've assumed that checking the host machine is the more-correct version
and used that.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37576>
This consistently uses `NAME.dll` on Windows, `libNAME.dylib` on Darwin
derivatives such as macOS, and `libNAME.so` on Linux, *BSD and so on.
It's also consistent about using the local variable name `icd_file_name`
for this name in every Vulkan driver, which was already the case in many
but not all drivers.
Some of these drivers probably don't make sense (or don't work) on
Windows and/or macOS, but if this is kept consistent for all drivers,
it should avoid the need for driver-specific commits like
commit 611e9f29e "lavapipe: fix icd generation for windows",
commit 951f3287 "lavapipe: set empty dll prefix",
commit 13e7a39f "lavapipe: fixes for macOS support",
commit 7008e655 "radv: Update JSON generator if Windows" and so on,
each time a driver is found to be relevant on more platforms than
previously believed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37576>
If the FS has writes to multiple color outputs, but there are not enough
color attachments for them all, we may optimize out the exceeding ones.
With VK_KHR_dynamic_rendering_local_read, we were not respecting the
mapping from output to attachment set by the application, and the wrong
writes were getting eliminated.
Fixes future CTS tests: dEQP-VK.renderpasses.dynamic_rendering.primary_cmd_buff.local_read.remap_single_attachment*
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37531>
Based on git history thhese appears to be a subset of
`anv_batch_emit_batch`, so I've structured the code similarly, if
`anv_batch_emit_dwords` returns `nullptr`, we just move on without
copying the memory.
CID: 1665339
CID: 1664814
Reviewed-by: Iván Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37534>
For 3-component RGB images with OPTIMAL tiling, we need to create the
surface as RGBX or RGBA. When a host image copy to/from this image
happens, we calculate sizes and offsets based on the 4-component surface
and blow past the end of the 3-component API provided buffer.
Hilarity^WSegfault ensues.
Ideally we'd calculate the right sizes and have the tiled copy functions
handle the conversion, but they are format unaware and expect to just
copy bytes in blocks of equal sizes from both sides.
Handle this case by making an intermediate copy to/from linear RGB
from/to linear RGBX, and pass that intermediate slice to the tiled copy
functions.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36453>
Per VUID-VkCopyImageToImageInfo-srcImage-09069,
srcImage and dstImage must have been created with identical image
creation parameters, so we are not going to have copies from color <->
depth/stencil, but we can copy both D/S aspects of an image at the same
time.
Nothing says that we can't copy from one plane of a multiplanar image to
another, so handle that case too (though nothing is currently testing
it).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36453>
Lucas Fryzek