Age | Commit message (Collapse) | Author |
|
|
|
This currently doesn't include fixing up the cliptests in the assembly
paths to support ARB_depth_clamp, so enabling depth_clamp forces the C path.
|
|
|
|
There's a symbol collision with X11/Xlib.h #define Status int
in the Mesa xlib code. This seems the simpliest way to work around this.
|
|
I'm apparently alone in prefering this calling convention, so I'll be
a team player. :p Based on review comments by Brian Paul and Eric
Anholt.
|
|
Based on review comments by Brian Paul.
|
|
Based on review comments by Brian Paul.
|
|
I believe this resolves the outstanding issues WRT sync object
deletetion. I have also added a large comment at the top of syncobj.c
describing the expected memory management behavior. I'm still a
little uncertain about the locking on ctx->Shared.
|
|
|
|
This isn't quite right yet. The delete behavior and the context
clean-up needs some work.
|
|
|
|
|
|
|
|
When no textures are enabled, the key size is 4 bytes. If unit[0] is
enabled, the key size is 16 bytes.
Inspired by a patch from Chris Wilson.
|
|
|
|
|
|
|
|
This trims down the code a bit. The next step would be to combine
the validate and map operations into one helper...
|
|
Instead of _mesa_map_readpix_pbo() use _mesa_map_pbo_source().
Instead of _mesa_map_drawpix_pbo() and _mesa_map_bitmap_pbo() use
_mesa_map_pbo_dest().
|
|
Return GL_FALSE if we failed to allocate the buffer. Then raise
GL_OUT_OF_MEMORY in core Mesa.
|
|
This reverts commit 4b08e7498230eac30eea1721f33994b30999acd4.
Don't know what I was thinking there.
|
|
|
|
|
|
|
|
|
|
It would be nice if there were a #pragma or something to disable the warnings:
main/texenvprogram.c:87: warning: type of bit-field ‘Source’ is a GCC extension
main/texenvprogram.c:88: warning: type of bit-field ‘Operand’ is a GCC extension
but there doesn't appear to be a way to do that.
|
|
By rearranging the bitfields within the key we can reduce the size
of the key from 644 to 196 bytes, reducing the cost of both the
hashing and equality tests.
|
|
Previously, MultiDrawElements just called DrawElements a bunch of times.
By sending several primitives down the pipeline at once, we avoid a bunch
of validation. On my GL demo, this improves fps by 2.5% (+/- .41%) and
reduces CPU usage by 70.5% (+/- 2.9%) (n=3).
Reviewed by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We need to clamp/saturate after each texenv stage, not just the last one.
Fixes glean texEnv failure for softpipe (and probably other fragment program-
based drivers).
|
|
|
|
|
|
The Pointer, Offset and Lenght fields should be cleared by the driver function
since ctx->Driver.Unmap() may be called from VBO code, etc.
|
|
Since ctx->Driver.MapBuffer() and ctx->Driver.MapBufferRange() may be called
from other places in Mesa (such as VBO) it's important that the driver
callbacks set all the buffer object fields properly (Pointer, Offset, Length,
etc). Add assertions to make sure that the driver does that.
|
|
Several changes are made to program parameter limits. Several of the
non-NATIVE limits are set higher. All of the NATIVE limits are set to
zero in the core Mesa code. Each driver must set the actual value in
its context creation routine. If the NATIVE value remains zero, this
indicates that hardware shaders may not be supported.
Each of the preceeding changes matches the bahavior of Apple's shader
assembler, so it seems safe.
Finally, we limit the value of MaxEnvParams to be no greater than
MaxNativeAttribs. At least one case has been found where an
application does the wrong thing if MaxNativeAttribs < MaxEnvParams.
See also bugzilla #23490.
|
|
|