This reverts commit 887ba96a.

Squish pooling

See merge request panfrost/mesa!10

panfrost: Manage texture memory with pb_slab

See merge request panfrost/mesa!9

Adds Bifrost boilerplate to the Panfrost driver

See merge request !11

Adds the disassembler from the ShaderProgramDisassembler repository with
everything renamed to match the coding practices with the rest of the
project.

For unclear reasons, glmark2-es2-drm ends up calling pandev_open twice,
causing a failure the second time leading us to abort(). The latter time
is spurious, since the init has already happened. So, keep track of when
we init and ignore attempts to double init.

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

Previously, we had artificially limited the framebuffer size to
2048x1280 to workaround a bug in old versions of Panfrost. This bug is
no longer present; the workaround, however, causes substantial issues
when paired with a larger display, like Kevin's native Hi-DPI beauty.

Previously, we allocated a massive amount of transient
(single-frame-only) command stream memory and just chipped into that
with a linear allocator. This broke if we needed more than we allocated,
and it used an absurd amount of memory when we didn't.

We continue to use a linear allocator for transient data, but we
allocate only a small slab on start-up. As more memory is needed, we
gradually increase the size of the pool, ensuring small apps require
minimal memory and large apps have enough for their needs.

This patch, in combination with the pb memory management patch on which
this patch depends, results in es2gears using one-tenth of the memory.
That's a 90% savings!

The other patch must be merged first.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

ATOMFADD is a little special -- make drivers have to specify it
explicitly.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

This is supported by at least NVIDIA hardware, and exposeable via GL
extensions.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

Not sure if this ever worked, but the current logic for setting the
min/max index is definitely wrong for indexed draws. While we're at it,
bring in all the usual logic from the non-indirect drawing path.

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


Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

We need a 64-bit value, otherwise we only handle the low 32, and happen to
sign-extend to claim to write all varying slots if VARYING_SLOT_VAR2 was
used.

Fixes: 4d0b2c7a ("ttn: Update shader->info as we generate code.")
Reviewed-by: Rob Clark <robdclark@gmail.com>

Previously, we allocated a single 256MB slab of texture memory on init,
never freed anything, and hoped it was enough. This is bad on so many
levels.

This patch uses the pb_slab interface courtesy of AMD to manage texture
memory. With the new API, we don't allocate any slabs on startup; we
instead provide a callback for allocating a new slab of memory, which
we implement with the existing kbase API. Then, we use its methods to
allocate and free texture memory.

For real-world motivation, without this patch, running
sway+es2gears (via Panfrost/llvmpipe respectively) would allocate 50% of
my memory, and then crash after a short amount of time due to OOM
conditions. With this patch, the same combination allocates about 30% of
memory and can run essentially indefinitely, since we're freeing
resources appropriately.

Future patches will extend this interface for other parts of the
cmdstream to further reduce our memory footprint.

midgard: Fix off-by-one in OP_CHANNEL_COUNT

See merge request panfrost/mesa!7

panfrost: Support float/vec2/vec3 attributes

See merge request panfrost/mesa!5

Compose the format swizzle with the descriptor swizzle (fixes sway coloring)

See merge request panfrost/mesa!6

We allocate 2-bits to store the channel count [1, 4], but the values
were not adjusted to fit in [0, 3]. Accordingly, fdot4 with a constant
exhibited the same issue as fdot3 prior to the OP_CHANNEL_COUNT quirk
was introduced to begin with.

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

Previously, we had hard-coded the number of components to equal 4
(vec4), due to mysterious issues occurring when the count was less than
4. Further investigation shows that not only the component count needs
updating but also the magic value in the unknown1 field. That field
still needs to be further decoded - I suspect it controls how extra
components are padded out - but for now, this patch allows these
attributes to work at all.

This enables Sway to render.