| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Missed in commit 3a4de321.
|
|
|
|
|
| |
Signed-off-by: Connor Abbott <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
| |
According to BSpec the correct number for min_vs_entries is 34 for CHV.
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change max_wm_threads to match the spec on CHV. The max number of
threads in 3DSTATE_PS is always programmed to 64 and the hardware
internally scales that depending on the GT SKU. So this doesn't
change the max number of threads actually used, but it does affect
the scratch space calculation.
On CHV the old value was too small, so the amount of scratch space
allocated wasn't sufficient to satisfy the actual max number of
threads used.
Cc: [email protected]
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Connor Abbott <[email protected]>
|
|
|
|
|
|
|
|
|
| |
When emitting texturing from indirect texture units, we need to be able to
scratch around in the header message. Since we only do this for >= HSW,
this is ok since there are no MRFs.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Anuj phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this commit, the adjust_sampler_state_pointer function took an
extra register that it could use as scratch space. The usual candidate was
the destination of the sampler instruction. However, if that register ever
aliased anything important such as the sampler index, this would scratch
all over important data. Fortunately, the calculation is such that we can
just do it in place and we don't need the scratch space at all.
Reviewed-by: Chris Forbes <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous code semantic was:
. if ff ps will not run a ff stage, then do not output texture coords for this stage
for vs
. if XYZRHW is used (position_t), use only the mode where input coordinates are copied
to the outputs.
Problem is when apps don't give texture inputs. When apps precise PASSTHRU, it means
copy texture coord input to texture coord output if there is such input. The case
where there is no texture coord input wasn't handled correctly.
Drivers like r300 dislike when vs has inputs that are not fed.
Moreover if the app uses ff vs with a programmable ps, we shouldn't look at
what are the parameters of the ff ps to decide to output or not texture
coordinates.
The new code semantic is:
. if XYZRHW is used, restrict to PASSTHRU
. if PASSTHRU is used and no texture input is declared, then do not output
texture coords for this stage
The case where ff ps needs a texture coord input and ff vs doesn't output
it is not handled, and should probably be a runtime error.
This fixes 3Dmark05, which uses ff vs with programmable ps.
Reviewed-by: Tiziano Bacocco <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
|
|
|
|
|
|
|
| |
declaration
Reviewed-by: Tiziano Bacocco <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the shader does indirect addressing on the constants,
we allocate a temporary constant buffer to which we copy
the constants from the app given user constants and
the constants filled in the shader.
This patch makes this buffer be allocated once.
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Signed-off-by: Tiziano Bacocco <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Tiziano Bacocco <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Relative addressing needs the constant buffer to get all
the correct constants, even those defined by the shader.
The code to copy the shader constants to the constant buffer
was enabled only for debug build. Enable it always.
Cc: "10.4" <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Since constant indirect adressing is not allowed for ps,
we can remove our code to handle that.
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
| |
relative adressing for constants is possible only for vs float
constants.
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
The fix is that this line:
"src[s] = tx->regs.vT[s];" is wrong if s doesn't start from 0.
Instead access tx->regs.vT directly when needed.
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Not filling them correctly results in bad padding and later crash.
Reviewed-by: David Heidelberg <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
texcoord for ps < 1_4 should clamp between 0 and 1 the values.
texcrd (texcoord ps 1_4) does not clamp and can be used with
two modifiers _dw and _dz that means the channels are divided
by w or z.
Implement those in shared code, since the same modifiers can be used
for texld ps 1_4.
v2: replace DIV by RCP + MUL
v3: Remove an useless MOV
Reviewed-by: Tiziano Bacocco <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nothing seems to indicates the negation modifier would be stored in the
instruction flags instead of the source modifier. tx_src_param has
already handled it if it is in the source modifier.
In addition,
when the card supports native integers, the boolean
are stored in 32 bits int and are equal to
0 or 0xFFFFFFFF.
Given 0xFFFFFFFF is NaN if it was a float, better use
UIF than IF.
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
|
|
|
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This is wine (and windows) behaviour.
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
|
|
|
|
|
|
|
| |
Signed-off-by: Axel Davy <[email protected]>
Signed-off-by: Tiziano Bacocco <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Previous implementation was behaving fine, but improve it by:
. Improved documentation
. Decreasing counter (comparing to 0 is likely to be faster than to constant)
. Move the counter update at the end for better performance for shaders that
break the loop earlier than when the count is done.
Reviewed-by: Tiziano Bacocco <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous implementation didn't work well with nested loops.
Instead of using several address registers, put a0 and aL
into normal registers, and copy them to one address register when
we need to use them.
Wine tests loop_index_test() and nested_loop_test() now pass correctly.
Fixes r600g crash while loading Bioshock -
bug https://bugs.freedesktop.org/show_bug.cgi?id=85696
Tested-by: David Heidelberg <[email protected]>
Reviewed-by: Tiziano Bacocco <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We should take the absolute value of the input.
Also return -FLT_MAX instead of -Inf for an input of 0.
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the input's xyz are 0.0, the output
should be 0.0. This is due to the fact that
Inf * 0 = 0 for dx9. To handle this case,
cap the result of RSQ to FLT_MAX. We have
FLT_MAX * 0 = 0.
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
We should use the absolute value of the input as input to ureg_RSQ.
Moreover, an input of 0.0 should return FLT_MAX.
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
POW doesn't match directly TGSI, since we should
take the absolute value of src0.
Fixes black textures in some games
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
| |
Cc: "10.4" <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's say we have c1 and c2 declared in the shader and c0 given by the app
Then here we would have read c0, c1 and c2 given by the app, instead
of the correct c0, c1, c2.
This correction fixes several issues in some games.
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
According to docs and Wine, these two vs outputs have
to be saturated.
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
don't support integers
The shader code is already behaving as if they are floats when the the card doesn't support integers
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert them to shader booleans at earlier stage.
Previous code is fine, but later patch will make
integers being converted at earlier stage, so do
the same for booleans
Reviewed-by: Tiziano Bacocco <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds ATI1 and ATI2 support to nine.
They map to PIPE_FORMAT_RGTC1_UNORM and PIPE_FORMAT_RGTC2_UNORM,
but need special handling.
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Signed-off-by: Xavier Bouchoux <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
According to msdn, we must act as if user didn't ask srgb if we don't
support it.
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Buffers in the MANAGED pool are supposed to have the content in a ram buffer,
a copy in VRAM if there is enough memory (driver manages memory and decide when
to delete the buffer in VRAM).
This is not implemented properly in nine, and a VRAM copy is going to be created
when the RAM memory is filled, and the VRAM copy will get synced with the RAM
memory updates.
Due to some issues (in the implementation or in app logic), it can happen
we try to create a sampler view of the resource while we haven't created the
VRAM resource. This hack creates the resource when we hit this case, which prevents
crashing, but doesn't help with the resource content.
This fixes several games crashing at launch.
Acked-by: Axel Davy <[email protected]>
Acked-by: David Heidelberg <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Stanislaw Halik <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
While previous code was having the correct behaviour in general,
this new code is more readable (without checking all gallium formats
manually) and has a more defined behaviour for depth stencil resources.
Reviewed-by: Tiziano Bacocco <[email protected]>
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implicit swapchains are destroyed when the device instance is
destroyed. However for non-implicit swapchains, it is not the case,
and the application can have kept an reference on the swapchain
buffers to reuse them.
Fixes problems with battle.net launcher.
Cc: "10.4" <[email protected]>
Tested-by: Nick Sarnie <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This->surfaces contains the surfaces associated to the levels
and faces. This->surfaces[6*Level] is what we want here,
since it gives us a face descriptor for the level 'Level'.
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: David Heidelberg <[email protected]>
Signed-off-by: Axel Davy <[email protected]>
Signed-off-by: Xavier Bouchoux <[email protected]>
Cc: "10.4" <[email protected]>
|