Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
FRAG & TILE buffer are unused but still they need
to be associated with a valid relocation so that
userspace can't try to abuse them to overwritte
GART and then try to write anywhere in system
memory.
|
|
The kernel lets you clear depth without getting a depth offset
from userspace, mesa used to emit state before clear, but that got
lost in the refactoring, which made the kernel bug show up. Fix
mesa driver to emit the state properly now.
cherry-pick + squash master commits.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
BUFFER_DEPTH."
This reverts commit 9d17ad2891b58de9e33e943ff918a678c6a3c2bd.
Fun stuff so fixing exposes another bug which I'm having trouble
tracking down. So for now I'm just going to revert this untill
I can fix the real bug. Sorry about this.
|
|
|
|
|
|
|
|
It was being erroneously set equal to the host offset, but it should be
zero.
|
|
Small improvement in Lightsmark 2008.
|
|
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 fixes incorrect Z position of glBitmap, glDraw/CopyPixels for the
svga driver. Now we use 0.5, 0.5 as is typical for ordinary 3D rendering.
|
|
The ST_SURFACE_x values should match the Mesa BUFFER_x values.
Added some assertions to prevent future mix-ups.
|
|
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>
|
|
Some st functions assume that they are identical.
|
|
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.
|
|
Not having a hardware buffer around doesn't change the fact that the
range is dirty and needs to be uploaded eventually.
|
|
Just cosmetic changes -- no behavior change.
|
|
Many apps don't check the return of map buffer so it is better not to
fail.
|
|
|
|
|
|
Set it to the same as 2d acceleration
|
|
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.
|
|
Fixes bug 26623. Original patch was submitted by Mathias Frohlich
and modified by Brian.
|
|
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 af2023e31cde5ad2cf8ce740e20a98c4cbab37ce.
|
|
Unnecessary now that we never destroy buffer storage.
|
|
To avoid masking synchronization issues in debug builds.
|
|
|
|
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>
|
|
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.
|
|
Once if/elif evalutes to true, all subsequent conditions are always false.
|
|
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.
|
|
Seems to be a regression from commit 60b08eb1fdf287d28ec66b9282513ab35a61aee0.
|
|
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
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.
|
|
Still used by some applications.
|
|
|
|
Also opposite ordering.
|
|
This fixes invalid calls to rastpos_point/line/tri() that can occur
when glRasterPos() is called while in feedback or selection mode.
|
|
|
|
|
|
|
|
|
|
without getBuffersWithFormat some visuals will just cause headaches (crashes),
so if we're running on an older system simply don't advertise them.
|
|
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.
|