| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There is a bug in some versions of the i915 kernel driver where it will
return immediately if the timeout is negative (it's supposed to wait
indefinitely). We've worked around this in mesa for a few months but never
implemented the work-around in the Vulkan driver.
I rediscovered this bug again while working on Ivy Bridge becasuse the
drive in my Ivy Bridge currently has Fedora 21 installed which has one of
the offending kernels.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Alignment units, i and j, match the compressed format block
width and height respectively.
v2: Don't assert against HALIGN* and VALIGN* enums (Chad)
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
| |
These formulas did not take compressed formats into account.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
| |
A non-compressed texture is a 1x1x1 block. Compressed
textures could have values which vary in different
dimensions WxHxD.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
| |
v2: Rename __brw_fmt to __hw_fmt (Chad)
Suggested-by: Jason Ekstrand <[email protected]>
Reviewed-by: Chad Versace [email protected]
|
|
|
|
|
|
|
|
|
|
|
| |
cpp (chars-per-pixel) is an integer that fails to give useful data
about most compressed formats. Instead, rename it to "bs" which
stands for block size (in bytes).
v2: Rename vk_format_for_bs to vk_format_for_size (Chad)
Use "block size" instead of "bs" in error message (Chad)
Reviewed-by: Chad Versace <[email protected]>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The new mechanism should be able to handle SSBOs as well as properly handle
emitting surface state on gen7 where we need different strides depending on
shader stage.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
We never *actually* supported them, we just used them for binding UBOs.
Now that we have BufferInfo and we aren't supporting texture buffers yet,
we should get rid of them until we can do them properly.
|
| |
|
|
|
|
|
| |
Previously, UpdateDescriptorSets was wrong because it assumed that the
binding was the offset into the descriptor set.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Tested by Crucible "func.depthstencil.stencil_triangles.*" in
commit c194292d5eadb84e9d7489fc01ce0b653cdd4ca5 (HEAD -> master)
Author: Chad Versace <[email protected]>
Date: Wed Nov 4 16:19:24 2015 -0800
Subject: func.depthstencil: Remove stencil clear workaround for Mesa
|
|
|
|
|
| |
We were treating it as if it's a BufferView and weren't taking the offset
into account properly.
|
|
|
|
|
|
| |
The anv_state is supposed to be a flyweight so we're not really saving
anything by using a pointer. Also, we were creating one, setting a pointer
to it, and then having it go out-of-scope which is bad.
|
|
|
|
|
|
|
|
|
| |
Remove members
num_color_clear_attachments
has_depth_clear_attachment
has_stencil_clear_attachment
The new clear code in anv_meta_clear.c does not use them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes Crucible test "func.clear.load-clear.attachments-8".
The old clear code, when clearing attachments for
VK_ATTACHMENT_LOAD_OP_CLEAR, suffered from some fundamental bugs. The
bugs were not fixable with the old code's approach.
- It assumed that a VkRenderPass contained at most one depthstencil
attachment.
- It tried to clear all attachments (color and the sole
depthstencil) with a single instanced draw call, using the VUE
header's RenderTargetArrayIndex to specify the instance's target
color attachment. But the RenderTargetArrayIndex does not select
entries in the binding table; it only selects an array index of
a singled layered surface.
- If at least one attachment of VkRenderPass had
VK_ATTACHMENT_LOAD_OP_CLEAR,
then the old code cleared *all* attachments. This was
a consequence of using a single draw call and single pipeline for
the clear.
The new clear code fixes those bugs by making a separate draw call for
each attachment, and using one pipeline when clearing color attachments
and a different pipeline for depth attachments.
The new code, like the old code, does not clear stencil attachments. It
is left as a FINISHME.
|
|
|
|
|
| |
No behavioral change. This patch just removes an unneeded function
parameter.
|
|
|
|
|
|
|
| |
Consistently rename bitmasks of Vulkan dynamic state to 'dynamic_mask'.
anv_meta_saved_state::dynamic_flags -> dynamic_mask
anv_meta_save(dynamic_state) -> dynamic_mask
|
|
|
|
|
|
|
|
| |
As the functions are now exposed in anv_meta.h, let's rename them
to clarify that they are meta functions.
anv_cmd_buffer_save -> anv_meta_save
anv_cmd_buffer_restore -> anv_meta_restore
|
|
|
|
|
|
| |
anv_meta.c currently handles blits, copies, clears, and resolves. The
clear code is about to grow, and anv_meta.c is already busting at the
seams.
|
|
|
|
|
| |
Move it from anv_meta.c to the common header anv_private.h. This allows
us to split the meta blit and meta clear code into separate files.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On future generation platforms the color clear value is stored elsewhere in the
surface state. By extracting this logic, we can cleanly implement the difference
in an upcoming patch.
Should have no functional impact.
v2: Move hunk from the next patch into this patch (Matt)
Whitespace fix (Ben)
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Neil Roberts <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The allocate_surface_state already zeroes out the surface state, and doing it
later in the function is destructive for what we want to accomplish when we
split out support for gen9 fast clears (next patch).
NOTE: Only dword 12 actually needed to be fixed, but it seemed more consistent
to remove the other instances as well. I can make an argument both ways (open
coding it, vs. not). I can rework the next patch if requires.
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Reviewed-by: Neil Roberts <[email protected]>
|
| |
| |
| |
| |
| |
| |
| | |
This fixes crashes with some piglit OpenCL tests.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To get the size (in bytes) of a compute parameter, clover first calls
get_compute_param() with a NULL data pointer. The RET() macro is based
on nv50.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A few new PCI ids are added here, and one is removed (0x190B) because it no
longer seems to exist anywhere.
v2-4:
Only use ascii characters (Ilia)
0x1921 is no longer marked as f
Reviewed-by: Jordan Justen <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Like other gen8+ hardware, the hardware automatically scales up thread counts.
We must be careful about the URB sizes since GT4 adds another slice.
One of the existing PCI IDs is actually mislabeled as GT3. Arguably this is a
real bug since the URB size will be wrong. Because this patch is simply meant to
add the missing IDs, that will be fixed in a later patch.
v2: No longer relevant.
v3: Update the wm thread count to support GT4. The WM thread count is used to
determine the maximum scratch space required. Currently the code always
allocates the maximum amount even though lower GT SKUs require less. The formula
is threads_per_psd * subslices_per_slice * slices
Cc: [email protected]
Reviewed-by: Jordan Justen <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Note: The OpenGL 4.3 - 4.5 specification language for DispatchCompute
appears to have an error regarding the max allowed values. When adding
the specification citation, we note why the code does not match the
specification language.
v2:
* Updates based on review from Iago
Signed-off-by: Jordan Justen <[email protected]>
Cc: Iago Toral Quiroga <[email protected]>
Cc: Marta Lofstedt <[email protected]>
Reviewed-by: Marta Lofstedt <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is some discrepancy between the return values for some error
cases for the DispatchComputeIndirect call in the ARB_compute_shader
specification. Regarding the indirect parameter, in one place the
extension spec lists that the error returned for invalid values should
be INVALID_OPERATION, while later it specifies INVALID_VALUE.
The OpenGL 4.3 and OpenGLES 3.1 specifications appear to be consistent
in requiring the INVALID_VALUE error return in this case.
Here we update the code to match the main specifications, and update
the citations use the main specification rather than the extension
specification.
v2:
* Updates based on review from Iago
Signed-off-by: Jordan Justen <[email protected]>
Cc: Iago Toral Quiroga <[email protected]>
Cc: Marta Lofstedt <[email protected]>
Reviewed-by: Marta Lofstedt <[email protected]>
|