Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Alyssa Rosenzweig authored Oct 31, 2019 and Tomeu Vizoso committed Nov 01, 2019

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

During tests on T720, these fields were discovered.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>

Alyssa Rosenzweig authored Oct 29, 2019 and Tomeu Vizoso committed Nov 01, 2019

We've discovered a bit more about the tiler so let's update the
comments. The implementation is unchanged for now.

Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>

This is incorrect, because polygonMode only applies if the final
primitive type is a polygon; polygonMode doesn't apply to
line-primitives as the comment suggests.

The Vulkan 1.1 spec, section 26.11, "Polygons" defines that polygons are
separate from points and line segments:

" A polygon results from the decomposition of a triangle strip, triangle
  fan or a series of independent triangles. Like points and line segments,
  polygon rasterization is controlled by several variables in the
  VkPipelineRasterizationStateCreateInfo structure. "

Further, section 26.11.2, "Polygon Mode", only define polygonMode to
apply to polygons:

" Possible values of the VkPipelineRasterizationStateCreateInfo::polygonMode
  property of the currently active pipeline, specifying the method of
  rasterization for polygons, are: "

This seems to clearly define that polygonMode doesn't apply to points
and lines, so let's make sure that we don't early out with the wrong
value.

Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

We don't need it in practice, so this is some more cleanup.

Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>

Rather than having hw-specific swizzles encoded directly in the
instructions, have a unified swizzle arary so we can manipulate swizzles
generically.

Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>

We want symmetry between loads and stores, so we add a dummy source. So
we get, e.g.

   st_int4 _,    val, arg_1, arg_2
   ld_int4 dest,   _, arg_1, arg_2

Semantically, this dummy source represents the data itself, as if the
load is simply a move. That means it has a swizzle that acts as a
source.

Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>

Unused.

Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>

This function was added in 7e414b58 to work around a defect in
lower_output_reads(). As of the previous commit no NIR driver calls
lower_output_reads().

This change means we don't need the special GLSL IR style
gl_FragData handling for building the resource list in a NIR based
linker.

No shader-db change on SKL i965.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>

This will allow us to stop lowering gl_FragData in GLSL IR for NIR
drivers which means we won't need the special GLSL IR type
handling for building the resource list in a NIR based linker.

i965 has been doing this since b828f7a2.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>

Icenowy Zheng authored Oct 22, 2019 and Vasily Khoruzhick committed Oct 31, 2019

When doing an indexed draw with index_bias set to a non-zero value (e.g.
by glDrawElementsBaseVertex), the vertex buffer should be offseted by
index_bias vertices.

Add this offset when setting the vertex buffer address.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>

Now that we're no longer compacting binding table entries, the only time
they can possibly change is when we actually switch subpasses.

Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>

Instead, always emit one entry for every color attachment in the subpass
or one NULL if there are no color attachments.  This will let us adjust
an Ice Lake workaround so we don't get a stall on every draw call.

Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>

If it's NULL, we can let the compiler go ahead and delete it or flag it
as NULL.

Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>

Also, use color_outputs_valid rather than nr_color_outputs since it
should be a bit more accurate.

Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>

Yevhenii Kolesnikov authored Oct 07, 2019 and Danylo Piliaiev committed Oct 31, 2019

From OES_EGL_image_external_essl3

Closes: mesa/mesa#1901



Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

The GKE pool we're using is 1-3 32-core VMs, preemptible (to keep
costs down), with 8 jobs concurrent per system.  We have plenty of
memory (4G/core), so we run make -j8 to try to keep the cores busy even
when one job is in a single-threaded step (docker image download, git
clone, artifacts processing, etc.)  When all jobs are generating work
for all the cores, they'll be scheduled fairly.

The nodes in the pool have 300GB boot disks (over-provisioned in space
to provide enough iops and throughput) mounted to /ccache, and
CACHE_DIR set pointing to them.  This means that once a new
autoscaled-up node has run some jobs, it should have a hot ccache from
then on (instead of having to rely on the docker container cache
having our ccache laying around and not getting wiped out by some
other fd.o job).  Local SSDs would provide higher performance, but
unfortunately are not supported with the cluster autoscaler.

For now, the softpipe/llvmpipe test runs are still on the shared
runners, until I can get them ported onto Bas's runner so they can be
parallelized in a single job.

Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

It was just duplicating the code.

Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

This effectively reverts MR !2112.

Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>

Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>

Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>

That's where `xmlpool_options_h` is defined, and this way we can make sure
nobody starts making use of it in the future :)

Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>

Fixes: a44f5ee0 "anv: Rework the internal BO allocation API"
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

When switching this to dynamic state, I forgot that this also needs to
be emitted when we use a polygon-mode set to lines.

Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: 6d30abb4 ("zink: use dynamic state for line-width")

Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>

Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>

Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>