| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
This gets the correct srclvl image map when uploading images to the new mipmap.
|
|
|
|
(cherry picked from master, commit 19a54d9f1055c366fd77026dd67007a8d5921f58)
|
|
|
|
|
|
Can be used to enable/disable extensions as reported by
glGetString(GL_EXTENSIONS).
If a name is preceeded by '-' it's disabled. Otherwise, the named
extension is enabled.
Intended for debug/test purposes.
|
|
It's legal for ARB_vertex_program programs to not write to result.position.
The results are undefined in that case. This assertion was causing us to
abort/exit though.
|
|
|
|
The recent increase ST_MAX_SHADER_TOKENS to 8K causes stack overflows on
windows.
Failure to allocate is not being propagated to the caller. This is not
a regression since the previous _mesa_malloc result wasn't being
checked as well. Unfortunately it is not easy to fix, as the callers of
these functions do not have failure propagation mechanism either, and
so on. So leaving a just fixme note for now.
|
|
|
|
Also, MAX_NV_VERTEX_PROGRAM_PARAMS should be 96, not 128 (or 256).
|
|
We were adding references to the input arrays, but failing to drop
them on destruction. This could lead to a 64kb buffer being leaked
each context destruction.
|
|
1) Pass the correct format when calling update_array in
_mesa_VertexAttribPointerARB.
2) glVertexAttribPointerNV accepts GL_BGRA format too.
3) raise INVALID_VALUE error when format is BGRA and normalized is
false in glVertexAttribPointerARB
(cherry picked from commit 4adb190a162c5ed0684a8616331344caadba4010)
|
|
1) Pass the correct format when calling update_array in
_mesa_VertexAttribPointerARB.
2) glVertexAttribPointerNV accepts GL_BGRA format too.
3) raise INVALID_VALUE error when format is BGRA and normalized is
false in glVertexAttribPointerARB
|
|
Fixes GPU hangs in software TCL path
|
|
|
|
Signed-off-by: Maciej Cencora <m.cencora@gmail.com>
|
|
|
|
Also when index format is GL_UBYTE, convert it to GL_USHORT not GL_UINT.
Fix license header too.
Reported by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
|
|
software TCL path
|
|
|
|
|
|
|
|
|
|
Always allocate the vertex program input registers in the same order as the vertex attributes are passed in vertex arrays.
|
|
Even if we don't pass all 4 color components to vertex shader unit, the vertex program can generate the missing components.
|
|
|
|
autoconf had been designating the 8 bit libOSMesa as the default
standalone osmesa, but the Makefile expected it to be linked to libGL.
Fix up the osmesa Makefile so that it allows any of the combinations of
standalone and channel width to be built.
Fixes bug #21980.
(cherry picked from commit 7441dcd90b01df8351026af8bbb50e11bb86071a)
|
|
autoconf had been designating the 8 bit libOSMesa as the default
standalone osmesa, but the Makefile expected it to be linked to libGL.
Fix up the osmesa Makefile so that it allows any of the combinations of
standalone and channel width to be built.
Fixes bug #21980.
|
|
|
|
Conflicts:
src/mesa/main/context.c
|
|
|
|
This is about a 30% performance win in OA with high settings on my GM45,
and experiments with 915GM indicate that it'll be around a 20% win there.
Currently, 915-class hardware is seriously hurt by the fact that we use
fence regs to control the tiling even for 3D instructions that could live
without them, so we spend a bunch of time waiting on previous rendering in
order to pull fences off. Thus, the texture_tiling driconf option defaults
off there for now.
|
|
We're on the way to telling the kernel about when we need fence regs on our
objects or not, and this will cut the number of places needing them.
|
|
|
|
It's possible for mis-behaving vertex programs to produce vertex data
with very large/NaN values. This doesn't get handled reliably by the
clipper code so we may try to rasterize triangles that extend beyond
the viewport/window. Always clip spans to avoid invalid memory accesses
later.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
