Age | Commit message (Collapse) | Author |
|
Per a patch from Marek Olšák, we can simply multiply the incoming
value by 1/sqrt(x) instead of using rcp.
We're keeping the x==0 check to avoid generating NaN for sqrt(0).
|
|
|
|
|
|
Also set the correct release date.
|
|
|
|
|
|
|
|
(cherry picked from commit 535742d75f0096b22d1b8ff203ae561167af18f7)
|
|
Fixes fd.o bug 27340.
(cherry picked from commit 8fe3b3f66ae57a1a6eca7f6dcb0455e14ad92075)
|
|
Conflicts:
src/mesa/drivers/dri/intel/intel_mipmap_tree.c - left what was in master
|
|
Was broken since the endianness fixes.
(cherry picked from commit 4cf14fa80bda5f4ea65bef3a64e748e064d0bde1)
|
|
This probably broke the swrast DRI driver when running X in depth 16.
(cherry picked from commit 6ec259eb17dfbb74972b8cffb4e02a9dbab288cc)
|
|
|
|
Only a few state vars require state validation before querying them.
This potentially speeds up state queries.
Encode that info into the state tuple table.
Also, use the new tuple field to indicate when FLUSH_CURRENT() must
be called to validate other state vars.
Based on a patch submitted by Robert Bragg on Feb 12, 2010.
|
|
I think my maths is right?
|
|
Fixes piglit fbo-readdrawpix.
(cherry picked from commit 5782b2a968bb979b651e49bb5fc4162faa842050)
|
|
fixes piglit fbo-copypix.
(cherry picked from commit a589da14dee0c2a32e6e529f1a390b01a3ee4001)
|
|
Bug #26966: 945 miptree pitch disagreement with libdrm.
(cherry picked from commit da011faf48155a5c02ebc1fe1fa20a4f54b8c657)
|
|
(cherry picked from commit 32f143b4327521a058dc05f0ab9087a5696b9618)
|
|
If a non-zero src_y was used, this would break piglit
depth-level-clamp.
(cherry picked from commit e1e48ea15c1fe448f0b69e086b66c1123dc98bb7)
|
|
|
|
If a GL function is called w/out a current rendering context, this stub
gets called. It should return 0 so that non-void-valued functions return
0/NULL instead of a random number.
|
|
|
|
|
|
meta ops should work ok without kms.
|
|
Spotted by Pauli Nieminen
|
|
R300_PVS_MAX_CONST_ADDR field holds highest const addr, not
const count.
Fixes missing models and others rendering errors for vertex
program using 256 params.
|
|
UMS will probably require some kernel work
|
|
It may happen that the vertex attribute we were going to stuff
the wpos/fog attrs in was already written by vertex program.
In such cases we need to remove instruction accessing these
attributes, so they don't overwrite the wpos/fog related
instructions.
This fixes non-textured models in many wine games.
|
|
removed FP during compilation
|
|
Fixes piglit glsl-orangebook-ch06-bump, regressed with
4fc57322258a750c0a9cabc77372b5ccde1fa877
|
|
|
|
Since texture's can be shared by many contexts, the texture's sampler
view's context pointer might be invalid by time we delete the texture.
Prevent crashes/etc by setting the sampler view's context to be the
calling context before deleting it. This should be safe as long as
all contexts which share the texture are using the same gallium driver.
That's a reasonable assumption since pipe_texture objects aren't
compatible between different drivers anyway.
|
|
|
|
To be consistent with other Mesa driver functions.
|
|
Just to be consistent.
|
|
We still don't do proper min/mag filtering but this is better than just
sampling the base mipmap level all the time.
Fixes piglit depth-level-clamp test. Fixes fd.o bug 27256.
|
|
|
|
_glapi_Context and _glapi_Dispatch have different constness between
TLS and non-TLS builds.
|
|
|
|
Currently the test link uses -lGL to define the glapi symbols.
This makes it impossible to build DRI drivers on systems without
Mesa installed and without building the libGL from the Mesa tree
first.
Some automated build systems trigger this problem.
This commit removes -lGL and instead adds a dummy implementation of
glapi to dri_test.c
This, along with Kristian's commit, should fix all known regressions
due to the addition of unresolved symbol checking.
|
|
We're still abusing the flags by putting them where our driver stores
ctx->NewState changes. Making them into more restricted state change
flags would be a project for later.
Fixes a failure where calling intel_draw_buffer() too often would trip
up Mesa assertions about when Mesa state could get changed, when it hadn't.
Bug #27034.
|
|
This will make sure we pick up libdrm_$(chipset).so from the right place.
|
|
We're still abusing the flags by putting them where our driver stores
ctx->NewState changes. Making them into more restricted state change
flags would be a project for later.
Fixes a failure where calling intel_draw_buffer() too often would trip
up Mesa assertions about when Mesa state could get changed, when it hadn't.
Bug #27034.
|
|
|
|
Fixes a segfault when clearing a non-existent stencil buffer.
|
|
Using just mv may cause prompts on some systems/configurations.
|
|
This is a different approach to solving this problem that the patch
I previously posted, and unlike that, should not cause any problems.
Right now undefined symbols in DRI drivers will still allow the
build to succeed.
As a result, people modifying drivers they cannot test risk creating
unloadable drivers with no easy way of automatically avoiding it.
For instance, the modifications to nv50 for context transfers caused
such an issue recently.
Unfortunately, just adding -Wl,--no-undefined doesn't work, because
the DRI drivers depend on glapi symbols, but do not depend on
libGL.so.1
Adding -lGL is not the correct solution since DRI drivers are not loaded
just by libGL, but also by X and possibly by other clients.
So, this patch simply tries to build an executable linked to the DRI
driver and to libGL.
If the DRI driver contains any undefined symbols not satisfied by its
dependencies or by libGL, this will fail.
This solution does not alter the built drivers, and does not significantly
slow down the build process.
All classic DRI drivers as well as all the Gallium drivers with configure
options compiled successfully with this change.
Thanks to Xavier Chantry <chantry.xavier@gmail.com> and
Michel Daenzer <michel@daenzer.net> for helping with this.
Signed-off-by: Luca Barbieri <luca@luca-barbieri.com>
Acked-by: Brian Paul <brian.e.paul@gmail.com>
|
|
|
|
|