This fixes a regression with Lightsmark, where more compact TGSI from Mesa
was causing a zero mask MOV to be emitted for shadow map compare, causing
problems in some backends.
Add a few more assertions to catch cases like this.
This avoids exposing the ms driver structure to the winsys,
and nicely encapsulates driver customizable stuff.
In the future more things might be customizable by the winsys, like
throttling, 3D readback etc.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
The optimized Z-test functions assumed that the array of incoming quads
are adjacent, but that's not always true. The fragment shader can cull
intermediate quads, for example.
Now these Z-test functions can cope with non-adjacent quads. A little bit
of performance is probably lost, but it's probably not worth worring about.
This fixes broken glBitmap() Z testing, among other things.
Fixes crash in Homeworld2 which tries to create a 14MB buffer, because we
now avoid creating GMR buffers larger than 8MB to ensure progress given
we have only a 16MB pool.
Since the execbuffer change actually changed size off the ioctl
struct and not just a reuse of padded bits, we can't support
old kernels as easily as the scanout change was.
It seems there are still some places where draw can happen with mapped
buffers... Remove the assertions since there is not much more than can
be done at this moment.
This partially reverts commit af2023e31c.
Remove const qualifier from _mesa_HashLookup() table parameter to
avoid LOCK/UNLOCK warnings in the function body.
Signed-off-by: Brian Paul <brianp@vmware.com>
Purpose is two fold:
- when doing user-space memory management mapping a buffer stored in the
graphics aperture effectively pins it there, increasing the likelyhood
of failure of validating other buffers when flushing
- certain hardware/platform combinations do not allow a buffer to be
simultaneously mapped and validated
This fixes assertion failures in HL Uplink with the svga driver, where
vbo was holding a map to a buffer which was also referred in the command
stream.
Note: this a non-invasive fix and shouldn't be just cherry-picked into
master as-is -- a cleaner fix for this problem should be searched.
My first reading of MS docs was wrong. It says:
All rendering contexts of a shared display list must use an identical
pixel format. Otherwise the results depend on the implementation of
OpenGL used.
That is, it is OK to share contexts with different pixel formats.
Adobe Premiere Pro tries to do that: share lists between a rgbx8 and a
rgba8 pixel format.
This is a quick-fix for the time being...
The per-face mipmap LOD computation was invalid at cube edges. In
mip_filter_nearest/linear() we were trying to compute LOD using
texcoords that were sometimes indexes into different cube faces.
The subtraction used to compute the partial derivatives basically
gave random values, so the LOD was unpredictable. This fix simply
uses the same cube face for all four pixels in the quad. The per-
face texcoords all reference the same cube face so the partial
deriviates are computed properly.
A more elaborate fix would involve computing the LOD at the same
time as we choose the cube faces. But for now, this solution works
well and allows the piglit/cubemap test to pass.
we actually need to specify the formats for different attachements, otherwise
if the color buffer is 24bpp and the app asks for 16bpp depth buffer than
we end up fetching the depth from the drawable which is 24bpp and end up
creating the wrong depth buffer. use the new getBuffersWithFormat extension
to pass the depth correctly.
When our DLL is unloaded, even if we leave the data structures in memory
for sake of future calls, the MS CRT will destroy the heap. Instead we
make all calls no-ops by setting stw_dev to NULL.
Simply skip cleanup when contexts are still active.
This addresses two issues:
- in some situations the ICD DLL may be unloaded before the DLL that is
using GL contexts is, so we may receive GL calls after stw_cleanup.
- when aborting (exception, or control-c) the contexts may have been left
in an inconsistent state and attempting to destroy can cause
unpredictable results.
It's possible for min_index and max_index to be ~0 if the min/max
values were not actually set or computed in the state tracker.
Skip some assertions in that case.
This only effects the debug build error checking.
Windows doesn't really expect things to fail at this point -- it
will try many times until it finally gives up, worse, something bad
happens.
The WGL state tracker will gracefully decline to do work even when it
is loaded.
This object can be shared with another context, so we cannot just
delete it when the owning context is being destroyed.
Ensuring that buffer objects are properly refcounted guarantees
NullBufferObj is destroyed when all references to it are removed.
