| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
This is a quick & dirty solution, but it works. See comments in
the code for other ideas.
Fixes regressions/breakage seen in progs/xdemos/glxheads, etc. from commit
6632915e957149c153a3f793c400a532b4995b18.
|
| |
|
|
|
|
|
| |
_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.
|
|
|
|
|
|
|
|
| |
The variable X_LIBS from AC_PATH_XTRA contains only the -L searchdir
parameter and not the -lX11 to link to Xlib. Use X11 prefixed build vars
for linking with Xlib to avoid the conflict.
Signed-off-by: Dan Nicholson <[email protected]>
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
On some systems, putting vertex and index buffers in VRAM instead of GART
memory eliminates massive graphics corruption which is otherwise present,
due to unclear causes.
This patch adds an environment variable that does that, along with helpful
messages.
It turns it on by default on G7x, as it is what I am seeing corruption
on and some other reports also seemed to pinpoint these cards.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we allocate buffers in GART or VRAM at creation time.
However, when using swtnl, this results in reads from uncached
memory, which drastically impair performance.
So, for now, cause nouveau_screen.c to not pass any placement flags
to buffer creation, so that the buffers are moved later.
Previously libdrm itself did this, but was changed to not to do it.
This may introduce an extra copy in normal usage, but this currently
does not seem to introduce significant performance degradation.
This will be revisited when pipebuffer is integrated.
Note that for AGP systems, properly solving this may be complex
since currently there is no fast way of reading from GART/VRAM.
We will probably need to try mapping AGP as writethrough and, in
addition, make buffer creation more aware of future buffer usage.
|
|
|
|
| |
Fixes a segfault when clearing a non-existent stencil buffer.
|
|
|
|
| |
Using just mv may cause prompts on some systems/configurations.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Makefile
src/gallium/state_trackers/glx/xlib/xm_api.c
src/mesa/drivers/dri/intel/intel_blit.c
src/mesa/drivers/dri/intel/intel_pixel_copy.c
src/mesa/main/version.h
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
We had fast paths for PIPE_FUNC_LESS and LEQUAL before. To satisfy
OpenGL invariance rules, all depth compare modes should produce the
same fragment Z values.
Fixes progs/demos/singlebuffer.c
|
| |
| |
| |
| |
| | |
This is a back-port of commit ef2664da6c4db1b52ef351641e3ee949b87f9c7b
from master.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This can happen when an X window is destroyed behind our back. We use
DRI2CopyRegion behind the scenes in many places (like flushing the fake
front to the real front) so we have to ignore X errors triggered in that
case.
The glean test cases trigger this consistently as they don't destroy the
GLX drawable nicely, they just destroy the X window.
|
| | |
|
| |
| |
| |
| | |
Fixes #27213.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently we are continuously spewing messages about these variables
since we call debug_get_bool_option everytime we want to check their value.
This is annoying, slows things down due to terminal rerendering
and obscures useful messages.
This patch only calls debug_get_bool_option once and caches the result in a
static variable.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch re-emits the viewport state on framebuffer or rasterizer
change.
This seems to be necessary on nv3x, but the reason is not fully
understood.
It is quite likely that this isn't really the correct fix, but seems
to work, and makes nv3x much better.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]> and
Michel Daenzer <[email protected]> for helping with this.
Signed-off-by: Luca Barbieri <[email protected]>
Acked-by: Brian Paul <[email protected]>
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This can happen when an X window is destroyed behind our back. We use
DRI2CopyRegion behind the scenes in many places (like flushing the fake
front to the real front) so we have to ignore X errors triggered in that
case.
The glean test cases trigger this consistently as they don't destroy the
GLX drawable nicely, they just destroy the X window.
|
| |
| |
| |
| | |
...This state's interdependent? Really? Needs moar cleanup.
|
| |
| |
| |
| | |
May or may not be responsible for slight increases in ipers FPS.
|
| |
| |
| |
| |
| | |
Those paths aren't important anymore, and a debugging warning won't stop
a hardlock anyway.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change passes a remainder of 1 to the server with the
DRI2SwapBuffers request, causing it to honor the OML semantics for the
swap rather than falling through to glXSwapBuffers behavior. The
remainder actually ends up ignored since the divisor is 0, but we need
to differentiate the OML and standard behavior somehow.
Reported-by: Mario Kleiner <[email protected]>
Signed-off-by: Jesse Barnes <[email protected]>
|
| | |
|
| |
| |
| |
| | |
Rejecting all doesn't seem to be helping get the pipeline lit up.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
It appears that the thing that was killing VS threads was the
gratuitous NOP that replaced the gratuitous jump from OPCODE_END to
the nearby OPCODE_END implementation. With that gone, we can move on
to the rest of the pipeline.
|
| |
| |
| |
| |
| |
| | |
Just emit the URB write at END time. Subroutine code that sits after
OPCODE_END won't be executed since we've ended the thread at the point
that the URB write is done.
|
| |
| |
| |
| |
| | |
Otherwise, we may not get the FFTID set up which would break freeing
of resources.
|
| |
| |
| |
| |
| |
| |
| | |
The hope is to later take advantage of the reduced constant usage to
free up regs. This only covers the GLSL path at the moment, because
the brw_wm_emit path doesn't get the information as to whether a float
value is a constant or a uniform.
|
| |
| |
| |
| |
| | |
I keep finding the desire to force this path to debug it instead of
cooking up goofy-looking testcases to do so.
|
| |
| |
| |
| | |
Tested with piglit glsl-fs-sqrt-branch, fp-cmp.vpfp.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes a pretty big performance regression caused by commit
3475e88442c16fb2b50b903fe246b3ebe49da226.
When the user does not request a stencil buffer it's important that we
don't use a depth/stencil format (or at least make it our last choice).
If the user calls glClear(GL_DEPTH_BUFFER_BIT) when we have a combined
depth/stencil buffer, that causes us to hit the clear_with_quad() path
which can be much, much slower than calling pipe_context::clear().
Also, try to use a shallower depth format before a deeper one.
|