Our behaviour was not entirely similar to what
the docs and our tests describe.
Drop d3dlock_buffer_to_pipe_transfer_usage.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Use present interface 1.2 function ID3DPresent_CreateThread
to create the thread for threadpool.
Creating the thread with WINE prevents some rarely occuring crashes.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
The problem is that if one d3d present call fails,
because of our occlusion check in present method,
the next presentation call will send the same pixmap to the Xserver again,
without waiting it is released, which is wrong.
Move the present call after occlusion check to return and prevent
Xpixmaps errors.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Any third party app might change the current screen resolution.
Poll for resolution mismatch to force a device reset.
Required for non ex devices only.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Implement presentation interface version 1.2:
* ID3DPresent_ResolutionMismatch
Poll for resolution mismatch.
A third party app might have changed resolution,
which requires a device reset.
* ID3DPresent_CreateThread
Create a thread in WINE to allow nine to use Windows API
functions. Required for multi-threaded presentation.
In single-threaded presentation mode the calling thread is
already known to WINE.
* ID3DPresent_WaitForThread
Wait for a wine thread to terminate.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
We were doing the conversion for surfaces, but not yet
volumes. Now that volumes can do conversion, use it.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
X8L8V8U8 support should be common. Some more recent cards
do support this format, but not L6V5U5.
Add fallback for this format to have it alwaus supported.
L6V5U5 conversion rule apparently differs a bit from the normal
spec, and thus the gallium equivalent format leads to slightly
wrong colors. Since some recent cards do not support it, do not
support it either.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Version 0.1 allows to assume that the second
element of the IDirect3D* structures will
be a pointer to the internal nine vtable.
This is useful if the gallium nine user wants
to wrap some interfaces.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Our code did match the user documentation of the function
quite well (except for format check).
However the DDI documentation and wine tests show that
documentation was not correct. Thus adapt our code to
fit the best possible to the -real- spec.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
This sets the AA location to the d3d11
spec.
EG/NI 8X MSAA is left as is. Not sure
why it was set different to Cayman, so
lets it as is.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Besides depth/stencil, the hardware doesn't support
mixed formats.
The GL state tracker doesn't make use of them.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
d3d 9 needs COLOR0 to be 1.0 on all channels when
undefined. 0.0 for the others is fine.
GL behaviour is undefined.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
d3d 9 needs COLOR0 to be 1.0 on all channels when
undefined. 0.0 for the others is fine.
GL behaviour is undefined.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
d3d 9 needs COLOR0 to be 1.0 on all channels when
undefined. 0.0 for the others is fine.
GL behaviour is undefined.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
As Emil pointed out, only gcc, clang and MSVC compatibility is required.
Hence the check for GNUC can be skipped, as __i386__ and __x86_64__ are
only defined for gcc/clang, not for MSVC.
Remove the #undef which has been there for historic reasons, when wine
dlls for nine have been built inside mesa. Instead use #ifndef in order
to avoid redefining WINAPI from MSVC's headers.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Axel Davy <axel.davy@ens.fr>
Mark it as unreachable. Silences a compiler warning:
spirv/spirv_to_nir.c:1397:4: warning: enumeration value
'nir_texop_txf_ms_mcs' not handled in switch [-Wswitch]
switch (instr->op) {
^
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
layout should only be null for structs, but it's checked everywhere else
and confuses Coverity (CID 1358495).
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Coverity (CID 1358496) warns that the cleanup code doesn't unlock the
mutex (which is arguably kind of stupid, since the only case that can
happen is when mtx_unlock() failed!). But, mtx_unlock() isn't going to
fail -- the mutex was locked by this thread just a few lines above it.
Operations like nir_op_bitfield_insert have four arguments, and Coverity
isn't privy to the fact that 4-argument operations aren't possible here,
so it thinks this can lead to memory corruption. Just increase the size
of the array to quell any fears.
Previously an SSO pipeline containing only a tessellation control shader
and a tessellation evaluation shader would not get locations assigned
for the TCS inputs. This would lead to assertion failures in some
piglit tests, such as arb_program_interface_query-resource-query.
That piglit test still fails on some tessellation related subtests.
Specifically, these subtests fail:
'GL_PROGRAM_INPUT(tcs) active resources' expected 2 but got 3
'GL_PROGRAM_INPUT(tcs) max length name' expected 12 but got 16
'GL_PROGRAM_INPUT(tcs,tes) active resources' expected 2 but got 3
'GL_PROGRAM_INPUT(tcs,tes) max length name' expected 12 but got 16
'GL_PROGRAM_OUTPUT(tcs) active resources' expected 15 but got 3
'GL_PROGRAM_OUTPUT(tcs) max length name' expected 23 but got 12
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: mesa-stable@lists.freedesktop.org
Commit 11096ec introduced a regression in some piglit tests (e.g.,
arb_program_interface_query-resource-query). I did not notice this
regression because other (unrelated) problems caused failed assertions
in those same tests on my system... so they crashed before getting to
the new failure.
v2: Use is_gl_identifier. Suggested by Tim.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: mesa-stable@lists.freedesktop.org
This catches a problem previously undetected until deep in the backend.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
