| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
This is a bit more efficient than using GEM_WAIT with a timeout of 0.
Reviewed-by: Chris Wilson <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of just advertising the aperture size, we do something more
intelligent. On systems with a full 48-bit PPGTT, we can address 100%
of the available system RAM from the GPU. In order to keep clients from
burning 100% of your available RAM for graphics resources, we have a
nice little heuristic (which has received exactly zero tuning) to keep
things under a reasonable level of control.
Reviewed-by: Kristian H. Kristensen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds support for using the full 48-bit address space on
Broadwell and newer hardware. Thanks to certain limitations, not all
objects can be placed above the 32-bit boundary. In particular, general
and state base address need to live within 32 bits. (See also
Wa32bitGeneralStateOffset and Wa32bitInstructionBaseOffset.) In order
to handle this, we add a supports_48bit_address field to anv_bo and only
set EXEC_OBJECT_SUPPORTS_48B_ADDRESS if that bit is set. We set the bit
for all client-allocated memory objects but leave it false for
driver-allocated objects. While this is more conservative than needed,
all driver allocations should easily fit in the first 32 bits of address
space and keeps things simple because we don't have to think about
whether or not any given one of our allocation data structures will be
used in a 48-bit-unsafe way.
Reviewed-by: Kristian H. Kristensen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When a client causes a GPU hang (or experiences issues due to a hang in
another client) we want to let it know as soon as possible. In
particular, if it submits work with a fence and calls vkWaitForFences or
vkQueueQaitIdle and it returns VK_SUCCESS, then the client should be
able to trust the results of that rendering. In order to provide this
guarantee, we have to ask the kernel for context status in a few key
locations.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
| |
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Nanley Chery <[email protected]>
Cc: "12.0 13.0" <[email protected]>
|
| |
|
|
|
|
|
| |
The build systems already add this as applicable. There's no need to
have this in the source file.
Signed-off-by: Emil Velikov <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
This is more consistent with the way the rest of the driver works and
ensures that all structs we pass into the kernel are zero'd out except for
the fields we actually want to fill. We were previously doing then when
building with valgrind to keep valgrind from complaining. However, we need
to start doing this unconditionally as recent kernels have been getting
touchier about this. In particular, as of kernel commit b31e51360e88 from
Chris Wilson, context creation and destroy fail if the padding bits are not
set to 0.
|
| |
|
