These tests were designed before having access to canonical information
about the hardware and thus had two purposes:
* Validating that our understanding of an instruction (as defined by IR
semantics) matches hardware behaviour -- obsoleted by new information.
* Validating that the IR packing code is correct -- obsoleted by
rewriting the IR and rewriting the packing.
I dislike removing tests as much as the next person, but the value of
these will be nil by the end of the series, and will prove burdensome.
Proper unit tests will be useful, however.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8213>
Letting the caller zero-initialize the program object is error prone,
not to mention that resources attached to the program might not be freed
by the caller. Let's simplify that by letting the compiler allocate the
panfrost_program object. Those objects should be freed with ralloc_free().
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7206>
So we can extend it more easily without having to patch all callers.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7066>
We'd like to wire in attributes and uniforms as inputs and look at the
varying as output for automatic testing on-device, building up a test
framework for us.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4396>
This emulates the functionality of shader_runner (built for kbase) using
the bifrost testing infrastructure so it runs on mainline. Ideally this
will let us test shaders from the assembler.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4396>
Normally mesa/st would do this for us, but we're using the standalone
compiler (in advance of having the hardware) and need this pass
particularly for fragment writeout.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4097>
Pretty much a copypaste from Midgard except where architectural
decisions diverge around vectorization. On that note, we will need our
own ALU scalarization pass at some point (or rather we'll need to extend
nir_lower_alu_scalar) to allow partial lowering for 8/16-bit ops. I.e.
we'll approximately need to lower
vec4 16 ssa_2 = fadd ssa_0, ssa_1
to
vec2 16 ssa_2 = fadd ssa_0.xy, ssa_1.xy
vec2 16 ssa_3 = fadd ssa_0.zw, ssa_1.zw
vec4 16 ssa_4 = vec4 ssa_2.x, ssa_2.y, ssa_3.x, ssa_4
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4097>
Modeled after the Midgard system. Already we know of two
compiler-visible differences between G52 and G71, so let's keep track so
we can eventually port the compiler to other Bifrost systems.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4061>
We're making some pretty dramatic design pivots so this early on it'll
be easier to start from scratch, I think.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4061>
Set of opcodes doesn't have enough flexibility in certain cases. E.g.
Utgard PP has vector conditional select operation, but condition is always
scalar. Lowering all the vector selects to scalar increases instruction
number, so we need a way to filter only those ops that can't be handled
in hardware.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
We don't actually have a standalone compiler in-tree yet, but let's get
prepared for when we do.
Signed-off-by: Ryan Houdek <Sonicadvance1@gmail.com>
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
In preparation for a Panfrost-based non-Gallium driver (maybe
Vulkan...?), hoist everything except for the Gallium driver into a
shared src/panfrost. Practically, that means the compilers, the headers,
and pandecode.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-07-10 10:43:23 -07:00
Renamed from src/gallium/drivers/panfrost/bifrost/cmdline.c (Browse further)