| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
We need ilo_builder for command building and ilo_cp for size check.
ilo_context is not used.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Move pipe states in ilo_context to the new ilo_state_vector. The motivation
is that ilo_context consists of several loosely related things. When we need
an ilo_context somewhere, we usually need only one or two of the things in it.
This change makes ilo_state_vector one such thing.
An immediate result is that we no longer need ilo_context in 3D pipelines,
something we have planned for since early days.
|
|
|
|
|
| |
Move the #define's and struct's to ilo_state.h. Move the inline functions and
function declarations to ilo_state_gen.h.
|
|
|
|
| |
Rename them to ilo_state_gen*.[ch].
|
|
|
|
| |
It is manipulated only in ilo_screen.c.
|
|
|
|
|
|
| |
Useful to know in some cases.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some users don't understand that these variables can break OpenGL.
The general is rule is that if an app supports MSAA, you mustn't use
GALLIUM_MSAA.
For example, if an app has an 8xMSAA FBO and GALLIUM_MSAA=4
is set, resolving the FBO to the back buffer will be rejected which will look
like this on all gallium drivers:
http://www.phoronix.com/scan.php?page=article&item=amd_radeonsi_msaa
The environment variables also have no effect on modern apps like TF2, but
there is still a performance hit due to wasted bandwidth and VRAM.
In a nutshell, it does more harm than good.
Cc: 10.2 10.3 <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
| |
Fixes the mesa reflect demo and 6 tests under interpolation/
|
|
|
|
| |
I need to get the non-reciprocal version of W for interpolation, anyway.
|
|
|
|
|
|
|
|
|
| |
These instructions only have vex encodings, thus they can't be used without
avx. (Technically, one can still use avx-128 if avx isn't available because
the environment doesn't store the ymm registers, however I don't think llvm
can.)
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
| |
It has been a bad name since we added the builder. Rename it to
ILO_DEBUG=batch to match i965, and call ilo_builder_decode() from
ilo_cp_submit_internal().
|
|
|
|
|
|
| |
"Flush" is used for too many things already: pipe resource flush, pipe context
flush, pipe transfer region flush, and hardware pipeline flush. Rename it to
ilo_cp_submit(). As such, ILO_DEBUG=flush is renamed to ILO_DEBUG=submit.
|
|
|
|
| |
Call ilo_builder_batch_used() directly.
|
|
|
|
|
|
| |
The simplification allows us to get rid of ilo_cp_set_ring() and
ilo_cp_implicit_flush(). The 3D query code is refactored for the
simplification.
|
|
|
|
|
|
|
| |
While depth test state is passed through the fragment shader as sideband,
data, the stencil test state has to be set by the fragment shader itself.
Many tests are still failing, but this gets most of hiz/ passing.
|
| |
|
| |
|
|
|
|
|
| |
Fixes 12 piglit tests (and 8 more crash -> fail) from reducing register
pressure.
|
|
|
|
| |
Prevents regression when I start doing copy propagation on uniforms.
|
| |
|
|
|
|
|
|
| |
This allows for introducing dead code eliminating of uniforms, copy
propagation of uniforms, and instruction rescheduling between instructions
that both read uniforms.
|
|
|
|
|
|
|
| |
This is particularly important for outputs, where we try to MOV the whole
vec4 to the VPM, even if only 1-3 components had been set up. It might
also be important for temporaries, if the shader reads components before
writing them.
|
|
|
|
| |
Somehow I slipped this in with the original commit of CSE.
|
|
|
|
|
|
|
|
| |
While the result of signed integer division by zero is undefined by glsl
(and doesn't exist with d3d10), we must not crash, so need to make sure we
don't get sigfpe much like udiv already does.
Unlike udiv where we return 0xffffffff (as required by d3d10) there is
no requirement right now to return anything specific so we use zero.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sample opcodes don't have valid texture target information (and I don't think
this should be changed), however it would be nice if we had that information
ready elsewhere, so stuff that information into the tgsi info when analyzing
a shader.
v2: Ilja Mirkin spotted some bugs wrt not handling msaa resources. So add them
and while there also add them to the tex opcode analysis this was cloned from
as well (plus get rid of some bug not detecting indirect textures there in some
cases too).
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
| |
...i.e. formats in which the first listed component is in the least
significant byte of the integer. The corresponding UNORM aliases already exist.
Signed-off-by: Richard Sandiford <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This means that each RnGnBnxn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
The associated UNORM and SRGB formats already exist.
Signed-off-by: Richard Sandiford <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
...i.e. formats in which the first listed component is in the least
significant half of the integer.
Signed-off-by: Richard Sandiford <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
...i.e. formats in which the alpha or green channel is first in memory.
This means that each LnAn and RnGn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
Signed-off-by: Richard Sandiford <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This was being shared using a ../../ get out of gallium into
mesa, and I swore when I did it I'd fix things when we got a util
dir, we did, so I have.
v2: move RGTC_DEBUG define
Reviewed-by: Jason Ekstrand <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
This gets a ton of piglit working that crashes in waffle context
management stuff otherwise. Actually supporting mismatched FB sizes is at
best going to require some more load/store generals for color buffers, but
if I can't manage to do that I'll want to just have state_tracker reject
those FBOs as unsupported, rather than deny GL 2.1.
|
| |
|
|
|
|
|
| |
I'm going to be rewriting it all, and having it mixed up with the
QIR-to-QPU opcode translation was messy.
|
|
|
|
| |
Fixes piglit glsl-1.10-fragdepth and early-z.
|
|
|
|
|
|
| |
The goal here is to have an argument for the depth write opcode so that I
can do computed depth. In the process, this makes the calculations that
will be emitted more obvious in the QIR.
|
|
|
|
|
|
| |
Compiler taken from the combo old/new compiler comparer + simulator.
Signed-off-by: Ilia Mirkin <[email protected]>
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
|
| |
The triangle_32_ rast functions never made it into the debug output,
confused me for a few seconds.
Reviewed-by: Roland Scheidegger <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch builds on 6c8f547f66e68b495c708f8ffcb67370caa5ffe8 and
previous patches by allowing u_format.csv to specify separate big-endian
and little-endian layouts. It then uses this to specify the correct layouts
for various depth/stencil formats. Later patches handle other formats.
To recap, the idea is that u_format.csv lists the channels for an N-byte
value as though it were an N-byte integer. For little-endian targets
the channels are listed starting at the least-significant bit of the
integer while for big-endian targets the channels are listed starting
at the most-significant bit. This means that for something like
PIPE_FORMAT_B8G8R8A8_UNORM (blue in first byte of memory, alpha in last
byte of memory) the orders are the same for both endiannesses. But for
something like PIPE_FORMAT_S8_UINT_Z24_UNORM, where the stencil is in
the least significant byte of a 32-bit integer, there need to be separate
channel definitions for each endianness.
The effect of this patch is to make the affected PIPE_FORMAT_*s have
the same layout as the associated MESA_FORMAT_*s for big-endian.
The MESA_FORMAT_*s are already handled correctly.
Fixes various piglit tests on z. No regressions on x86_64.
[airlied: squash subsequent patches]
util: Add big-endian layout for 5551 and 565 formats
util: Add big-endian layout for 10/10/10/2 formats
util: Add big-endian layout for 4444 formats
util: Add big-endian layout for 233 format
util: Add big-endian layout for 44 formats
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvmpipe treats PIPE_FORMAT_Z32_FLOAT_S8X24_UINT as a bit of a special case,
handling it as two 32-bit pieces rather than a single 64-bit block:
/* 64bit d/s format is special already extracted 32 bits */
total_bits = format_desc->block.bits > 32 ? 32 : format_desc->block.bits;
The format_desc describes the whole 64-bit block, so the z shift
will be 32 for big-endian. But since we're accessing the z channel
as a 32-bit value rather than a 64-bit value, we need to mask the shift
with 31.
Signed-off-by: Richard Sandiford <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Fallback cases in lp_bld_arit.c used 2^24 to mean "2 to the power 24",
but in C it's "2 xor 24", i.e. 26. Fixed by using 1<< instead.
Signed-off-by: Richard Sandiford <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Cc: "10.2 10.3" <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
| |
...fixing the associated TODO.
Reviewed-by: Roland Scheidegger <[email protected]>
Signed-off-by: Richard Sandiford <[email protected]>
|
|
|
|
|
|
|
|
|
| |
It looks like it was possible to attach it to both for a long time, however
since llvm r217548 attaching it to just the pass manager is no longer
sufficient and causes bugs (see http://llvm.org/bugs/show_bug.cgi?id=20903).
Tested-by: Vinson Lee <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This is just a very limited version, in particular sampler and sampler view
index must be the same. It cannot handle any modifiers neither.
Works much the same as soa version otherwise, to figure out the target we
need to store the sampler view dcls.
While here, also handle (no-op) RET and get rid of a couple bogus deprecated
comments.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
sample opcodes are a little oddly represented in the opcode_info, since
they don't count as texture instructions - they don't have valid target
information, but they may have offsets (unlike "ordinary" texture
instructions, the texture token may be optional for them).
So just make sure with these opcodes the optional offsets are accepted.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
| |
sample opcodes don't encode a texture target, it would thus always
print UNKNOWN, which is not helpful (and wouldn't parse when giving
back the shader text to tgsi).
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
| |
This query has always been useless, but we could potentially reject
well-formed, runnable programs if we expose a value that's too low.
|
|
|
|
|
|
| |
We don't have any specific limits in the hardware, just like the other
GPUs, so match their behavior. Fixes minmax_gles2 and several other
piglit tests relying on the specced uniform minmax values.
|
|
|
|
|
| |
Fixes buffer overflows in some piglit tests (which are still failing to
register allocate anyway).
|