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 <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
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 <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
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 <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
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 <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
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 <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
GS doesn't have ClampVertexColor, and we don't want to go through VS
structures.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Tessellation shaders and SIMD8 geometry shaders may need to resort to
the pull model for inputs at times. When set, the state upload code
will tell the hardware to provide URB handles for input data.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
In scalar mode, geometry shader inputs can easily take up hundreds of
registers. This makes pushing VUE entries impractical; we'll need to
resort to the pull model in some cases.
To support this, we introduce a new opcode corresponding to the "URB
Read SIMD8" message.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
In the vec4 backend, we have a vec4_instruction::urb_write_flags field.
There are many kinds of flags for SIMD4x2 messages.
However, there are really only two (per-slot offset, use channel masks)
for SIMD8 messages. Rather than adding a boolean flag for per-slot
offsets (polluting all instructions), I decided to just make three new
opcodes.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
This commit moves the large pile of setup calculations we have to do for
geometry shaders out of brw_gs_emit and into brw_compile_gs. This has a
couple of nice implications. First, it's less work that the caller of
brw_compile_gs has to do. Second, it's consistent with the vertex and
fragment stages. Finally, it allows us to put brw_gs_compile back behind
the API boundary where it belongs.
v2 (Jason Ekstrand):
- Pull the changes to use nir info into a separate patch
- Put brw_gs_compile into brw_shader.h rather than brw_vec4_gs_visitor.h
so that we can use it for scalar GS.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we were pulling bits from GL data structures in order to set up
the prog_data. However, in this brave new world of NIR, we want to be
pulling it out of the NIR shader whenever possible. This way, we can move
all this setup code into brw_compile_gs without depending on the old GL
stuff.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If the user called vkDestroyDevice but never called
vkEnumeratePhysicalDevices, then the driver tried to ralloc_free() an
unitialized anv_physical_device.
Fixes test 'dEQP-VK.api.device_init.create_instance_name_version'.
All the documentation I can find says that this bit (and functionality) only
exists on SKL+. Since the bit isn't yet used, there is no real impact here.
The original code was added by Ken here (a surprisingly long time ago):
commit f3c6d6f1e1
Author: Kenneth Graunke <kenneth@whitecape.org>
Date: Thu Nov 29 21:00:27 2012 -0800
i965: Update 3DSTATE_PS, 3DSTATE_WM, and add 3DSTATE_PS_EXTRA.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Documentation is sparse, but it appears to have existed on G45 and ILK
as a second bit extension of the mask_control field. Setting the pair of
bits to 0b11 enables "NoCMask".
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
It only exists on Gen6+, and the next patches will add compaction
support for the (unused) field in the same location on earlier
platforms.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The next commit will add assertions dependent on devinfo->gen.
Use compact()/uncompact() macros where possible, like the 3-src code
does.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Otherwise we'd emit a MOV from the null register (which isn't allowed).
Helps 24 programs in shader-db (the geometry shaders in GSCloth):
instructions in affected programs: 302 -> 262 (-13.25%)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
GNU make predefines RM to rm -f but this is not required by POSIX
so ensure that RM is set. This fixes "make clean" on OpenBSD.
v2: use AC_CHECK_PROG
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
CC: "10.6 11.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
In bfdae9149e I disabled the opt_sampler_eot optimisation for TG4
message types because I found by experimentation that it doesn't work.
I wrote in the comment that I couldn't find any documentation for this
problem. However I've now found the documentation and it has
additional restrictions on further message types so this patch updates
the comment and adds the others.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Since 49374fab5d these macros no longer actually use the block
argument. I think this is worth doing to make the macros easier to use
because they already have really long names and a confusing set of
arguments.
Reviewed-by: Matt Turner <mattst88@gmail.com>
This fixes assigning explicit locations in the CTS test:
ES31-CTS.explicit_uniform_location.uniform-loc-arrays-of-arrays
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
process_parameters() will now be called earlier because we need
actual_parameters processed earlier so we can use it with
match_subroutine_by_name() to get the subroutine variable, we need
to do this inside the recursive function generate_array_index() because
we can't create the ir_dereference_array() until we have gotten to the
outermost array.
For the remainder of the array dimensions the type doesn't matter so we
can just use the existing _mesa_ast_array_index_to_hir() function to
process the ast.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Check current_var directly instead of using the passed in record_type.
This fixes following failing CTS test:
ES31-CTS.explicit_uniform_location.uniform-loc-types-structs
No Piglit regressions.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
UniformRemapTable is used only for remapping user specified uniform
locations to driver internally used ones, shader storage buffer
variables should not utilize uniform locations.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
A third instance of this was needed but missed in the previous commit.
Return 32 as for the two other cases.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Jason Ekstrand