| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Now that descriptor sets are handled in a lowering pass, this is no longer
needed.
|
|
|
|
|
|
|
|
|
|
|
| |
When emitting the binding table for the fragment shader stage, we no
longer "walk all of the attachments, [inserting only] the color
attachments into the binding table". Instead, we iterate only over the
subpass's color attachments, which is the minimal possible iteration.
While killing the comment, also rename the variable 'attachments' to
'color_count', as it's no longer a count of all framebuffer attachments
but only the subpass's color attachment count.
|
|
|
|
|
|
| |
Right now, Broadweel and Ivy Bridge are the only supported platforms.
Hopefully, this reduces the chances that someone will try the driver on
unsupported hardware and be confused that it doesn't work.
|
|
|
|
|
|
|
| |
What we had before was kind of a hack where we made certain untrue
assumptions about the incoming data. This new support, while it still
doesn't support indirects properly (that will come), at least pulls the
offsets and strides from SPIR-V like it's supposed to.
|
| |
|
| |
|
| |
|
|
|
|
| |
Trivial fix.
|
|
|
|
|
| |
Move it from anv_device.c to new file anv_pass.c. Because it will soon
grow bigger.
|
|
|
|
|
|
|
|
|
|
|
|
| |
My original understanding of VkAttachmentDescription::loadOp,
stencilLoadOp was incorrect. Below are all possible combinations:
VkFormat | loadOp=clear stencilLoadOp=clear
---------------+---------------------------
color | clear-color ignored
depth-only | clear-depth ignored
stencil-only | ignored clear-stencil
depth-stencil | clear-depth clear-stencil
|
|
|
|
|
| |
Adds a note that we support SPIR-V revision 32. Also, we now support
geometry shaders.
|
|
|
|
|
|
| |
This reverts commit 5eccd0b4b947d806c0725899a827e622e605f2cc.
This was only needed for the store_ssbo_vk_indirect intrinsic
|
|
|
|
|
|
|
| |
This reverts commit 24bcc89c8fa326b838e9fea002065a40d4d04314.
Now that we have the new vulkan_resource_index intrinsic, these variants of
the classic UBO/SSBO instrinsics aren't needed.
|
| |
|
|
|
|
| |
This is instead of using the _vk versions of UBO/SSBO load/store intrinsics
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The 1k batch size wasn't big enough for a full pipeline setup including
geometry shaders. Some day we should make it dynamic.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Instead of just stomping on the mode, it now validates asserts that the
previously set mode is correct and only changes it if needed. We need to
do this because, in geometry shaders, there are some builtins that can be
either an input or an output depending on context. We can get that
information from the SPIR-V source but we can't throw it away.
|
|
|
|
|
| |
We'll want this in a moment for validation but, for now, it just gets
stompped by get_builtin_variable.
|
|
|
|
|
| |
Now that builtins are handled in deref chains, we don't really need this
anymore.
|
| |
|
|
|
|
| |
This equation was pulled from mesa gen8_gs_state.c
|
|
|
|
| |
This was missed in the initial enabling commit.
|
|
|
|
|
| |
The computation used to only look for uniforms that weren't samplers. Now
it also filters out arrays of samplers.
|
|
|
|
|
|
|
| |
These are supposed to be specified in the SPIR-V source as SpvExecutionMode
enums but glslang isn't giving them to us. A bug has been filed:
https://github.com/KhronosGroup/glslang/issues/84
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Now that we've done the refactoring upstream, it's much easier to to get
hooked up. We haven't tested things well enough to know that we're setting
up the GPU state correctly for them yet but at least we can compile them now.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
It's stored in bits 31:27 of g1 (along with the URB handles).
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
|
| |
| |
| |
| |
| | |
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Unlike the vs/wm structs, brw_gs_compile is actually useful: it contains
the input VUE map and information about the control data headers.
Passing this in allows us to share that code in brw_gs.c, and calculate
them before deciding on vec4 vs. scalar mode, as it's independent of
that choice.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch introduces a brw->scalar_gs flag, similar to brw->scalar_vs,
which controls whether or not to use SIMD8 geometry shaders.
For now, we control it via a new environment variable, INTEL_SCALAR_GS.
This provides a convenient way to try it out.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Geometry shaders have additional header data at the beginning of their
output URB entries. Shaders that use EndPrimitive() or multiple streams
have a control data header; shaders with a dynamic vertex count have an
additional vec4 slot to hold the 32-bit vertex count (and 96 bits of
padding).
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The GS will emit a bunch of vertices, and we don't want to do an EOT
prematurely. We'll emit GS_OPCODE_THREAD_END when we want to terminate
the thread.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| | |
GS doesn't have ClampVertexColor, and we don't want to go through VS
structures.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
|