| Age | Commit message (Collapse) | Author |
|---|
|
There is only a few functions that have debugging enabled now.
|
|
|
|
|
|
Converted r100 to use shared debug code with sed and fast compile check. New
code has compability layer so old debugging code doesn't have to be changed
all immidiatly.
|
|
These function are aiming to make it very simple to add and keep large amount
of debugging code without having runtime impact in relase builds. Basic idea
is to expose simple printf style debugging functions that are inlined.
Level parameter will be evalueted in compile time so compiler can optimise
some of debugging functions out if compile time request for debug level is too
tight.
|
|
|
|
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).
|
|
When cross compiling on a 64bit machine, gen_matypes.c is build
for the host machine (64bit) but must generates code for the target
machine (32bit). This causes wrong offsets all over the place and
crashes googleearth on my machine. Solution is to add -m32 when
cross compiling.
Attached patch is compatible with linux-x86-32 and autoconf based
builds.
|
|
|
|
|
|
|
|
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.
|
|
This fixes a bunch of gallium regressions since
commit 8096aa521369c3bcf5226c060efa6dd06e48ddc8
|
|
|
|
Also, allow using texture rectangles, NPOT textures or regular POT textures
(preferred in that order).
|
|
|
|
|
|
|
|
|
|
Kernel side doesn't have required register in safe list so can't send it kernel.
|
|
All that state stuff should really be in state atoms :/
|
|
|
|
|
|
|
|
This looks like it's a small win on blender.
|
|
We would end up with the offset from the start of the mapping rather than
the offset from the start of the buffer.
|
|
Passes glean's bufferObject test, and should provide good performance in the
cases applications are expected to use.
|
|
Previously we blocked because I hadn't added the libdrm function. Now it's
there, so update your libdrm.
|
|
Problem was to find the correct place to run prediction. Only place that is
called for every primitive is ALLOC_VERTS so we have to do prediction there
before allocation.
|
|
DRI1 has to set scissors in framebuffer coordinates.
|
|
DRI1 didn't have support for command buffer emit for stripple.
|
|
|
|
Polygon stipple has to go to command buffer because special ioctl is disabled.
Piglit doesn't like HyperZ warning so disable it for kms.
|
|
I forgot about r600 being here.
|
|
this makes gnome-shell work on r300 for me
|
|
Passes glean's bufferObject test for this extension.
|
|
|
|
|
|
See bug 16866.
|
|
|
|
The fragment program native limits are actually higher on R4xx
as reported by Alex Deucher, but using those requires some
bit-twiddling changes to program handling.
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
Swtcl calls flush everytime primitive changes so prediction has to made again
after flushing.
|
|
|
|
|
|
For non-FBOs we need to invert, for FBOs the scissors are non-inverted.
no matter what we need to clamp them to the buffer sizes.
|
|
Increase the number of native program parameters to the same values
exposed by GLSL.
|
|
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.
|
