panfrost: increment correctly kbase_ioctl_job_submit.addr array pointer

See merge request !1

Otherwise instead of passing a pointer to the next atom, we pass a
pointer 1-byte into the first atom.

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

Nowadays mali_kbase tells us when we need to mmap() things, not the
other way around. Unfortunately it's a little rude and doesn't seem to
specify the right output flag for requiring an mmap, so we just tell if
an mmap is required by checking for the magic number that's always the
first cookie. Let's hope we never try multithreading with this!

This might have something to do with the kbase API we're reporting.

Or this will cause me problems some undefined time in the future

When we started this project, I had 'interesting' ideas. Mainly, I had
made our own custom headers for interacting with mali_kbase because the
headers they had were a humongous mess. I wasn't aware the burden of
maintainership it'd incur, and nowadays the kbase headers are a lot more
acceptable anyway.

Since we're updating to the latest mali_kbase uapi, I decided to just
throw them out and start using the actual headers. Now we do that using
a simple bridging header, panfrost-mali-base.h, which handles the
various defines and other things needed to make including the kbase
headers 'just work'.

Additionally-move panfrost-int.h to panfrost-misc.h so we can stick some
other required types into it.

This commit doesn't get things onto the screen on my T82x board quite
yet, but it does communicate with the kernel properly!

Since we're about to pull in all of ARM's official headers for their
kernel driver instead of our own, and all of those are prefixed with
mali-* or mali_*, let's rename ours to panfrost-* so there isn't any
confusion.

No functional changes.

panfrost: Add .editorconfig

See merge request panfrost/mesa!2

This was missed when I added the new enum.

Cc: 18.3 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Leo Liu <leo.liu@amd.com>

Andrii Simiklit authored Nov 13, 2018 and Eric Engestrom committed Nov 14, 2018

1. brw_pipe_control.c:311:34: warning:
    unused variable ‘devinfo’
2. brw_program_binary.c:209:19: warning:
    unused variable ‘gen_size’
3. brw_program_binary.c:216:19: warning:
    unused variable ‘nir_size’

v2: Changes for unreproducible issues were removed

Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>

Andrii Simiklit authored Nov 13, 2018 and Eric Engestrom committed Nov 14, 2018

1. nir/nir_lower_vars_to_ssa.c:691:21: warning:
       unused variable ‘var’
       nir_variable *var = path->path[0]->var;

v2: Changes for some part of 'may be used uninitialized'
    warnings were removed, seems like it is a compiler issue.
        ( Eric Engestrom <eric.engestrom@intel.com> )
    Possible like this one:
    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46684


    This issue is flagged as duplicate but an
    original one is not closed yet.

Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>

Andrii Simiklit authored Nov 13, 2018 and Eric Engestrom committed Nov 14, 2018

1. tools/aub_read.c:271:31: warning: unused variable ‘end’
    const uint32_t *p = data, *end = data + data_len, *next;

2. tools/aub_mem.c:292:13: warning: unused variable ‘res’
       void *res = mmap((uint8_t *)bo.map + map_offset, 4096, PROT_READ,
   tools/aub_mem.c:357:13: warning: unused variable ‘res’
       void *res = mmap((uint8_t *)bo.map + (page - bo.addr), 4096, PROT_READ,

v2: The i965_disasm.c changes was moved into a separate patch
    The 'end' variable declared separately with MAYBE_UNUSED
    to avoid effect of it to other variables.
       ( Eric Engestrom <eric.engestrom@intel.com> )

Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>

Bump minor to signal support for new formats and higher precision
solid pictures.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

Support Component Alpha for those composite operations that do not require
per-channel alpha blending.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

constify function arguments to clean up the code a bit.

Reported-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

In the case when we had both source and mask samplers, transformations were
typically not applied correctly.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

The only solid fill picture type we supported only had 8 bit color
channels. Add a new solid picture type that supports float channels.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

Remove unused and obsolete code for gradients and component-alpha
Support solid source- and mask pictures using a variable number
of samplers in the composite pipeline rather than the fixed number
we used before.

Tested using rendercheck for XA.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

Gert Wollny authored Nov 12, 2018 and Gert Wollny committed Nov 14, 2018

Some hardware supports source mods only for float operations. Make it
possible to skip lowering to source mods in these cases.

v2: use option flags instead of a boolean (Jason Ekstrand)

Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

v2: fix for specialization constants as well

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Karol Herbst <kherbst@redhat.com>

this helps reduce the overall code changes when a bit_size parameter is
added to nir_load_system_value

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Karol Herbst <kherbst@redhat.com>

this allows to replace some nir_load_system_value calls with the specific
system value constructor

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Karol Herbst <kherbst@redhat.com>

vkpipeline-db results:

Totals from affected shaders:
SGPRS: 28400 -> 28576 (0.62 %)
VGPRS: 27916 -> 27692 (-0.80 %)
Spilled SGPRs: 140 -> 138 (-1.43 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 0 -> 0 (0.00 %) dwords per thread
Code Size: 1534456 -> 1520560 (-0.91 %) bytes
LDS: 0 -> 0 (0.00 %) blocks
Max Waves: 3541 -> 3582 (1.16 %)
Wait states: 0 -> 0 (0.00 %)

Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>

It's only used in anv_image.c

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

This shouldn't make any difference but I feel uneasy to use the
expanded aspects that do not represent the image in its entirety. If
we ever change the implementation of the anv_image_aspect_to_plane()
helper, this is safer.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

This will make it easier to associate an aspect with a plane number.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

To play around with debugging, we might want to disable one or the
other component. Having 0s as default values makes this work.
Otherwise we might have NULL components, leading to crashes.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>