Fixes several of the
"dEQP-GLES31.functional.image_load_store*load_store*single_layer" dEQP
tests that use image formats we implement using untyped surface
messages.

Cc: mesa-stable@lists.freedesktop.org
Tested-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

When uploading state for the compute pipeline, we don't want to
look at VS/TCS/TES/GS/FS programs, as they might be stale, and
aren't relevant anyway.  Likewise, the render pipeline shouldn't
look at CS.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93790

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

This fixes the same tests that commit 8cf2e892

 was attempting to fix:

ES31-CTS.shader_storage_buffer_object.advanced-unsizedArrayLength-cs-std430-vec-bindrangeOffset
ES31-CTS.shader_storage_buffer_object.advanced-unsizedArrayLength-cs-std430-vec-bindrangeSize

as confirmed by Samuel.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Cc: Marta Lofstedt <marta.lofstedt@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>

This reverts commit 8cf2e892

. It's
entirely bogus to attempt to store anything about the binding in the
buffer object itself, which might be bound any number of times.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Cc: Marta Lofstedt <marta.lofstedt@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>

Commit 5bb5eeea

 fixes a bug indicating that the surfaces should have the
API buffer size. Hovewer it picked the wrong value.

This patch adds a new variable, which takes into account
glBindBufferRange() values. This patch fixes the following CTS
regressions:

ES31-CTS.shader_storage_buffer_object.advanced-unsizedArrayLength-cs-std430-vec-bindrangeOffset
ES31-CTS.shader_storage_buffer_object.advanced-unsizedArrayLength-cs-std430-vec-bindrangeSize
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>

For several reasons, I don't think it's particularly useful to have
separate flags:

1. Most of the time, tessellation shaders are paired, so both will be
   replaced at the same time.

2. The data layout is tightly coupled.  Both need to agree on the number
   of per-patch slots in the VUE map.  Even adding extra TCS outputs
   that aren't read by the TES will trigger the need for recompiles.

3. The TCS is optional from an API perspective, but required by the
   hardware whenever tessellation is enabled.  So, atoms that deal with
   the TCS must check brw->tess_eval_program (BRW_NEW_TESS_EVAL_PROGRAM?)
   rather than brw->tess_ctrl_program to tell whether tessellation is
   enabled.

So, not only is it unlikely to be useful, it's a bit confusing to get
right.  Simply using one flag for both simplifies this.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

This is brw_gs_surface_state.c copy and pasted twice with search and
replace.

brw_binding_table.c code is similarly copy and pasted.

v2: Drop dword_pitch related fields.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Jason Ekstrand <jason.ekstrand@intel.com>

Cc: "11.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Cc: "11.0" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92909

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Cc: "11.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Atomic counters and Images were using ctx::Shader that does not take in
to account program pipeline changes, ctx::_Shader must be used for SSO to
work. Commit c0347705

 already changed ubo's to use this.

Fixes failures seen with following Piglit test:
	arb_separate_shader_object-atomic-counter
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>

Acked-by: Kenneth Graunke <kenneth@whitecape.org>

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

This is more optimal as it means we no longer have to upload the same set
of ABO surfaces to all stages in the program.

This also fixes a bug where since commit c0cd5b var->data.binding was
being used as a replacement for atomic buffer index, but they don't have
to be the same value they just happened to end up the same when binding is 0.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Alejandro Piñeiro <apinheiro@igalia.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90175

This is the only place in the driver where we use this. Since we now work
with separate index spaces, always use NumUniformBlocks and
NumShaderStorageBlocks instead of NumBufferInterfaceBlocks to be more
consistent with the rest of the code.
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>

Currently, these arrays in gl_shader and gl_shader_program hold both
UBOs and SSBOs, so this looks like a better name. We were already
using NumBufferInterfaceBlocks in gl_shader_program, so this makes
things more consistent as well.

In a later patch we will add {Num}UniformBlocks and
{Num}ShaderStorageBlocks which will contain only references to
UBOs and SSBOs respectively that will provide backends with
a separate index space for both types of objects.
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>

gl_image_unit::_Valid will be removed in a future commit.
Tested-by: Ye Tian <yex.tian@intel.com>
CC: "11.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

The values of intel_mipmap_tree::align_w and ::align_h correspond to the
hardware enums HALIGN_* and VALIGN_*.

See the confusion?
    align_h != HALIGN
    align_h == VALIGN

Reduce the confusion by renaming the variables to match the hardware
enum names:
    git ls-files |
    xargs sed -i -e 's/align_w/halign/g' \
                 -e 's/align_h/valign/g'
Suggested-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>

This will only be setup when the prog_data uses_num_work_groups
boolean is set.

At this point nothing will set uses_num_work_groups, but soon code
will set it when emitting code for the intrinsic that loads
gl_NumWorkGroups.

We can't emit this surface information earlier at the start of the
DispatchCompute* call because we may not have generated the program
yet. Until we generate the program, we don't know if the
gl_NumWorkGroups variable is accessed.

We also can't emit the surface as part of the brw_cs_state atom,
because we might not need the surface if gl_NumWorkGroups is not used
by the program.

Lastly, we cannot emit the surface later (after state upload) in the
DispatchCompute* call, because it needs to be run before the
brw_cs_state atom is emitted, since it changes the surface state.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>

The returned drm buffer object has a size multiple of 4096 but that should not
be exposed to the API user, which is working with a different size.

As far as I can see this problem is only visible in the calculation of the
length of unsized arrays used in SSBOs, as the implementation of this needs
to query the underlying buffer size via a message.
Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>

Otherwise we can expect odd things to happen if, for example, we ask
for the size of the attached buffer from shader code, since that
might query this value from the surface we uploaded and get random
results.
Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>

Iago Toral authored Mar 23, 2015 and Samuel Iglesias Gonsálvez committed Sep 25, 2015

Since these are a special kind of UBOs we emit them together reusing the
same infrastructure, however, we use a RAW surface so we can reuse
existing untyped read/write/atomic messages which include a pixel mask
header that we need to set to obtain correct behavior with helper
invocations of the fragment shader.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>

The spec requires that all layers of the image starting from the 0-th
are bound to the image unit regardless of the Layer parameter when
Layered is true, so I was setting gl_image_unit::Layer to zero in that
case for the convenience of the driver back-end.  However the
ES31-CTS.shader_image_load_store.basic-api-bind conformance test
checks that the layer value returned by glGetInteger is the same that
was originally specified, regardless of the value of layered.  Rename
Layer to _Layer as is usual for other derived state and keep track of
the original layer value as gl_image_unit::Layer.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

Rhys Kidd authored Aug 06, 2015 and Matt Turner committed Aug 18, 2015

mesa/src/mesa/drivers/dri/i965/brw_wm_surface_state.c: In function 'brw_upload_abo_surfaces':
mesa/src/mesa/drivers/dri/i965/brw_wm_surface_state.c:961:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    for (int i = 0; i < prog->NumAtomicBuffers; i++) {
                      ^
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Reviewed-by: Thomas Helland <thomashelland90@gmail.com>

Rhys Kidd authored Aug 06, 2015 and Matt Turner committed Aug 18, 2015

mesa/src/mesa/drivers/dri/i965/brw_wm_surface_state.c: In function 'brw_upload_ubo_surfaces':
mesa/src/mesa/drivers/dri/i965/brw_wm_surface_state.c:901:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    for (int i = 0; i < shader->NumUniformBlocks; i++) {
                      ^
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Reviewed-by: Thomas Helland <thomashelland90@gmail.com>

v2: Add CS support.  Move the image_params array back to
    brw_stage_prog_data.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>

This will be used to pass image meta-data to the shader when we cannot
use typed surface reads and writes.  All entries except surface_idx
and size are otherwise unused and will get eliminated by the uniform
packing pass.  size will be used for bounds checking with some image
formats and will be useful for ARB_shader_image_size too.  surface_idx
is always used.

v2: Add CS support.  Move the image_params array back to
    brw_stage_prog_data.
v3: Improve documentation.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

v2: Add SKL support.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

Kevin Rogovin authored Jun 17, 2015 and Martin Roukala committed Jun 17, 2015

Change references to gl_framebuffer::Width, Height, MaxNumLayers
and Visual::samples to use the _mesa_geometry_ convenience functions
for those places where the geometry of the gl_framebuffer is needed
(in contrast to the geometry of the intersection of the attachments
of the gl_framebuffer).

This patch is to pave the way to enable GL_ARB_framebuffer_no_attachments
on Gen7 and higher in i965.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Kevin Rogovin <kevin.rogovin@intel.com>

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Note that brw_update_renderbuffer_surfaces() already had a helper
variable which was used in parallel to direct access of the current
draw buffer of the context.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>

Notice that in gen7_wm_surface_state.c there is also indentation
change in the surrounding code removing tabs.

v2 (Matt): Fixed whitespace: tabs -> spaces
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>

Marius Predut authored Apr 07, 2015 and Matt Turner committed Apr 14, 2015

Consistently just use C99's __func__ everywhere.
No functional changes.
Acked-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Marius Predut <marius.predut@intel.com>

Now, we only use ctx->NewDriverState.

I used this bash & sed command in the i965 directory:
  for file in *.[ch] *.[ch]pp; do
    sed -i -e 's/state\.dirty\.brw/ctx.NewDriverState/g' $file
  done

Followed by manual changes to brw_state_upload.c.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

It's a wrapper around emit_buffer_surface_state with format=RAW, pitch=1,
rw=true and the remaining arguments ordered differently.  There's no point in
having a separate vtbl pointer for that.
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>

_mesa_choose_tex_format (texformat.c) tries I8_SNORM, L8_SNORM, and
either L8A8_SNORM or A8L8_SNORM, none of which are supported by our
driver.  Failing that, it falls back to RGBX for luminance, and RGBA
intensity and luminance alpha.  So, we need to use swizzle overrrides
to obtain the correct values.

Fixes Piglit's EXT_texture_snorm/fbo-blending-formats and
fbo-clear-formats.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>

Null surfaces are going to be useful to have something to point
unbound image units to, as the ARB_shader_image_load_store extension
requires us to behave deterministically in cases where some shader
tries to access an unbound image unit: Invalid stores and atomics are
supposed to be discarded and invalid loads are supposed to return
zero, which is precisely what the null surface does.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>