Rename NINE_STATE_FOG_SHADER,
NINE_STATE_POINTSIZE_SHADER and NINE_STATE_PS1X_SHADER
into
NINE_STATE_VS_PARAMS_MISC and NINE_STATE_PS_PARAMS_MISC.
The behaviour is unchanged, except one minor change:
D3DRS_FOGTABLEMODE doesn't need to affect VS.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
With some test app I hit the limit.
As we allocate on demand (up to the maximum),
it is free to increase the limit.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
CC: <mesa-stable@lists.freedesktop.org>
Previously we had already found that for
MANAGED buffers the buffer started dirty
(which meant all writes out of bound
before the first draw call using the
buffer have to be taken into account).
Possibly it is the same for the other types of buffers.
For now always lock the entire buffer (starting from the offset)
for these (except for DYNAMIC buffers, which might hurt
performance too much).
Fixes: https://github.com/iXit/Mesa-3D/issues/301
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
The previous code was ignoring the input
until a cursor is set inside d3d
(with SetCursorProperties), as expected
by wine tests.
However it did still make a call to ID3DPresent_SetCursor,
which would result into a SetCursor(NULL) call, thus
hidding any cursor set outside d3d, which we shouldn't do.
Add comment about not avoiding redundant ID3DPresent_SetCursor
calls once a cursor has been set in d3d, as it has been tested to
cause regressions.
Fixes: https://github.com/iXit/Mesa-3D/issues/197
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
For some applications SetCursorPosition
is called when a cursor event is received.
Our SetCursorPosition was always calling
wine SetCursorPos which would trigger
a cursor event.
The infinite loop is avoided by not calling
SetCursorPos when the position hasn't changed.
Found thanks to wine tests.
Fixes irresponsive GUI for some applications.
Fixes: https://github.com/iXit/Mesa-3D/issues/173
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
CC: <mesa-stable@lists.freedesktop.org>
d3d9_get_pipe_depth_format_bindings assumes the input format
is a depth stencil format.
Previously the user could hit this function with an invalid format.
Protect the last non protected call with a depth_stencil_format check.
Another solution is to have d3d9_get_pipe_depth_format_bindings
support non depth stencil format, but we don't want the user
to create depth buffers with d3d formats that can't be one,
it's better to check if the format can be depth buffer with d3d.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
colorarg0, etc are 3 bits wide.
Make the code more readable by adding an & 0x7
to further indicate we only remember the first 3 bits only.
The 4th bit is always 0,
and colorarg_b4, colorarg_b5, etc are used to store
the 5th and 6th bits.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
When using csmt, ff shader creation happens on the csmt
thread. Creating the shaders, then calling RefToBind causes
the device ref to be increased then decreased.
However the device dtor assumes than no work pending on the
csmt thread could increase the device ref, leading to hang.
The issue is avoided by creating the shaders with a bind
count directly.
Fixes: https://github.com/iXit/Mesa-3D/issues/295
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Emulate perspective interpolation of depth for programmable ps fog
ff ps fog uses position z, or 1/w depending on the ff
projection matrix set. This is according to public documents
found describing the algorithm and tests we made.
In the case of programmable ps, we used position's z,
which was sufficient to pass wine tests (which test shaders
don't set w).
Issue https://github.com/iXit/Mesa-3D/issues/315 showed
that this calculation was wrong.
Using perspective interpolation on z, that is using z * 1/w
seems to satisfy both this application and wine tests.
Fixes: https://github.com/iXit/Mesa-3D/issues/315
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Tests done on several devices of all 3 vendors and
of different generations showed that there are several
ways of handling infs and NaN for d3d9.
Tests showed Intel on windows does always clamp
RCP, RSQ and LOG (thus preventing inf/nan generation),
for all shader versions (some vendor behaviours vary
with shader versions).
Doing this in nine avoids 0*inf issues for drivers
that can't generate 0*inf=0 (which is controled by
TGSI's MUL_ZERO_WINS).
For now clamp for all drivers. An ulterior optimization
would be to avoid clamping for drivers with MUL_ZERO_WINS
for the specific shader versions where NV or AMD don't
clamp.
LOG and RSQ being already clamped, this patch only
clamps RCP.
Fixes: https://github.com/iXit/Mesa-3D/issues/316
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
CC: <mesa-stable@lists.freedesktop.org>
SWR takes 17+ minutes to build. Clover builds take ~6-7 minutes.
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Since blending will be disabled later for integer formats we have to
consider that in the case of a mixed set of integer/non-integer format
buffers blending must be handled on a per buffer basis.
Fixes on r600:
dEQP-GLES31.functional.draw_buffers_indexed.random.
max_required_draw_buffers.13
Fixes: 8fb966688b
st/mesa: Disable blending for integer formats.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
That warning fires every time a string function takes an argument that
could possibly be longer than its max output, which triggers all over
the place, especially when working with file paths ("what if every file
path is MAX_PATH long?" is what GCC is saying, which is really annoying
when we *know* that "/dev/dri/cardN" is not gonna be 4096 char long and
it's safe to store it in a 32-char array).
Anyway, we either add a ton of dead code all over the place to make GCC
happy, or we get rid of its spam. I chose the latter.
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
A ZPASS_DONE packet doesn't make sense for the compute queue. It will
result in a gpu hang.
This change resolves a gpu hang for SteamVR+Vega.
Cc: mesa-stable@lists.freedesktop.org
Fixes: 1f616a840e "radv: emit a dummy ..."
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This allows NIR to CSE more operations. LLVM does this also so the
impact is limited, however doing this in NIR allows other opts to
make progress. For example in radeonsi more loops are unrolled in
Civilization Beyond Earth.
The actual pipeline-db stats are not overwhelming but even in the
negatively affected shaders the NIR is clearly better. It just
happens that the code shuffling and in some cases calls to max
rather than a flt result in the final output from LLVM not
giving as good numbers.
However this is an incremental opt that further passes build off
so the change should be made IMO.
Totals from affected shaders:
SGPRS: 20192 -> 20184 (-0.04 %)
VGPRS: 19516 -> 19524 (0.04 %)
Spilled SGPRs: 437 -> 444 (1.60 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 0 -> 0 (0.00 %) dwords per thread
Code Size: 1527444 -> 1522276 (-0.34 %) bytes
LDS: 6 -> 6 (0.00 %) blocks
Max Waves: 1018 -> 1016 (-0.20 %)
Wait states: 0 -> 0 (0.00 %)
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
By adding `_llvm == 'true'` to the required argument we can check the
'auto' and 'true' case in one path.
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Seems this fixes linking problems that occur in some situations.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
NVC0_CB_AUX_BINDLESS_INFO isn't written to on Maxwell+ and it's too small
anyway.
With these changes, TXQ is used to determine the number of samples and
the coordinate adjustment information looked up in a small array in the
driver constant buffer.
v2: rework to use TXQ and a small array instead of a larger array with an
entry for each texture
v3: get rid of the small array and calculate the adjustments in the shader
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Fixes: c2ae9b4052 ('nvc0: implement multisampled images on Maxwell+')
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
`git-branch` doesn't exist, and mesa3d-dev hasn't been used in a great
many years :)
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
I also updated the developer instructions; presumably someone who's been
given commit rights already knows how to clone a repository :)
A more useful thing is to show how to update the pushurl, and how to use
access tokens to push over HTTPS (especially for us at Intel, where
non-http traffic is a pain).
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
It's just over 10 months since 17.3.0 was released with s3tc support enabled.
Probably a good idea to update the FAQ page.
v2: Incorporate feedback from Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Fixes: 04396a134f ("mesa: Import libtxc_dxtn sources")
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Fixes: 66ca7e400b ('nvc0: add support for programmable sample locations')
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
SDL has some shaders that compute sin(angle) and cos(angle) for a rotation
matrix in the VS, and angle is usually 0.0. Our previous implementation
had quite a bit of error around 0.0, causing single-pixel rotations at
typical window sizes. SDL2 has changed as of August 28th (commit
12156:e5a666405750) to not need sin/cos in the VS, but we should still fix
this for existing implementations or similar patterns that other programs
may have.
glsl-cos goes from 32 instructions to 36, but 9 uniforms to 7.
glsl-sin goes from 32 instructions to 34, but 8 uniforms to 7.
This seems like a fine impact to have for the bugfix.
Cc: 18.1 18.2 <mesa-stable@lists.freedesktop.org>
Fixes: https://github.com/anholt/mesa/issues/110
v2: - fix typo
These are how FreeBSD and Debian handle multiple versions of LLVM
installed at the same time, respectively.
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
