It's not clear the hardware really has a maximum which confuses dEQP;
clamp to whatever we report as our maximum.
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>
The reason for doing this is two-fold:
1. These passes are likely to be shared with the Bifrost compiler
Therefore, we don't want to restrict them to Midgard
2. The coding style is different (NIR-style vs Panfrost-style)
The NIR passes are candidates for moving upstream into
compiler/nir, so don't block that off for stylistic reasons
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Just use the #define instead.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Suggested-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
PIPE_CAP_SM3 has always been an odd one out of all our caps. While most
other caps are fine-grained and single-purpose, this cap encode several
features in one. And since OpenGL cares more about single features, it'd
be nice to get rid of this one.
As it turns, this is now relatively simple. We only really care about
three features using this cap, and those already got their own caps. So
we can remove it, and make sure all current drivers just give the same
response to all of them.
The only place we *really* care about SM3 is in nine, and there we can
instead just re-construct the information based on the finer-grained
caps. This avoids DX9 semantics from needlessly leaking into all of the
drivers, most of who doesn't care a whole lot about DX9 specifically.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Shader Model 3.0 is a big promise to make to the state-tracker, and
for instance mobile hardware might support vertex-shader saturate but
not some of the other features of SM3. So let's give this its own cap
for simplicity.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Shader Model 3.0 is a big promise to make to the state-tracker, and
for instance mobile hardware might support fragment-shader derivatives
but not some of the other features of SM3. So let's give this its own
cap for simplicity.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Shader Model 3.0 is a big promise to make to the state-tracker, and
for instance mobile hardware might support texture lod but not some
of the other features of SM3. So let's give this its own cap for
simplicity.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This boolean is only consulted once during init, so there's nothing
much saved by storing this in the context. So let's just check directly
when we need it instead.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Panfrost is known to only work on a select few CPU/GPU combinations at
the moment (tested system-on-chips: RK3288, RK3399, and S912). Whitelist
the combinations known to work and refuse to load on others where
nothing works yet to avoid user confusion.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
A lot of the pan_screen.c code was cargoculted from other drivers. The
upshot is that we return true for a lot of PIPE_CAPs that we don't
actually support, resulting in us exposing way too many extensions that
we don't actually support. Be more careful.
Some CAPs we do need to fake to access higher dEQP versions (i.e. in
order to debug the features we're hiding behind the CAP). For these, we
hide the CAP behind a special PAN_MESA_DEBUG=deqp option to avoid
apps randomly using these in-development features.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
It's easy to forget about, but shader size does matter for things like
i-cache, so let's include it in the analysis.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
We have to emit it anyway for the report to be happy (with respect to
unrolling), so return an actual count rather than dummy numbers.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
bany/ball type ops read from all 4 channels even though they only write
to 1; specify this in the opcode table like we do for dot products.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Now that the output usage mask is set to 0x1 the LayerID is
correctly exported in the loop above.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
When the stage preceding FS doesn't export it the fragment shader
might read it, even if it's 0.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Much of the format selection code was inherited from softpipe (!) of all
places, and a lot of it is accordingly cruft. Later if-elses were added
in random places to workaround missing formats at various points in
history. Clean up some of this.
Theoretically, any format we can texture from we can also render to. In
practice, there are a few corner cases that we need to disable
explicitly.
For one, we do have to restrict SCANOUT formats to workaround
buggy apps (in particular, dEQP which with --deqp-surface-type=window
under Weston will end up with RGB10_A2 and complain about low alpha
precision). Just be clearer about how/why.
Also, RGB5_A1 support is still broken; let's not worry about that quite
yet.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Rather than have random variables flying around and a long if-else
chain, use a switch. They're literally *designed* for this.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
We add support for writing out (via a blend shader):
- RGBA4
- RGB10_A2_UNORM
- RGB10_A2_UINT
- RGB5_A1_UNORM
- R11G11B10_FLOAT
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
We would like to permit keying blend shaders against the framebuffer
format, which requires some new blending abstractions.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
We would like the offset field to be unsigned, letting 0 represent "no
offset" and positive represent an offset.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
I'm not sure I'm totally comfortable with this, but conceptually neither
float nor pure-int formats require any format conversion, except size
conversion. Going from a shaderable format (fp32 or i16, for instance)
into a blendable format (fp16) is a separate question, one we can defer
momentarily while we're not interested in actually blending.
As an aside, I'd be fascinated by an integer-based blending
implementation.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
We'll need some careful handling, but for now, get some baseline code
out for handling float formats in a blend shader.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Normally, disabled blend can definitely be fixed-function'd away, but
if a blend shader is used merely for format conversion rather than
blending, this code path can be nevertheless hit.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Ideally, we would keep Galliumisms far away from the compiler;
unfortunately, Mesa hasn't standardized on system of format codes to be
shared across APIs and across drivers, so using Gallium formats is our
best bet in the short run.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
We now have some preliminary fp16 support available. We're not able to
expose this for GLSL quite yet, but for internal blend shaders, we're
able to do control bitness ourselves just fine. So let's fp16 that
stuff!
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Eventually this should be replaced by proper tex RA / not emitting so
many silly moves to begin with / better general copy prop. For now
remove it since it breaks things.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Alyssa Rosenzweig
Erik Faye-Lund
Samuel Pitoiset