| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Only very few places where realy converted so there isa lot of to do.
|
|
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.
|
|
|
|
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
|
|
In particular, this removes the dependency on prog_instruction, which
unfortunately creates some code duplication, but also opens a path towards
adding some hardware-specific things in there.
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
This really doesn't belong into the compiler itself, since the compiler
should eventually be independent of Mesa's program representation.
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
|
|
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>
|
