| Age | Commit message (Collapse) | Author |
|---|
|
This will avoid clflushing entire buffers for small acesses, such as those
commonly used by regression tests.
|
|
|
|
Didn't hurt 915, but needed for 965.
|
|
This lets us avoid duplicated code for doing so, including the depthstencil
paths that aren't covered by SpanRenderStart/Finish. Those paths were
missing the span funcs setup, leading to a null dereference in the fbotexture
demo.
|
|
Bump the driver date and insert the string "GEM". When running tests,
this make it much easier to know that the right driver is being used.
|
|
|
|
Those functions rely on being able to treat the GET_PTR returned value as an
array indexed by x, but that's not the case for our tiling.
Bug #16387
|
|
|
|
|
|
The dri_bo_map()s that follow will take care of idling the hardware as needed.
|
|
We have something similar in the X Server that covers X Server rendering, this
is the equivalent here for rendering to the front buffer. If we cared about
avoiding this at glFlush time, we could only do this when some actual
frontbuffer rendering had occurred.
Bug #16392.
|
|
Apparently in Y mode we get bit 6 ^ bit 9. The reflect demo in 'd' mode now
displays correctly.
|
|
The boolean that the server gives us for whether the region is tiled was
getting used as the enum for what tiling mode. Instead, guess the correct
tiling in screen setup.
Also, fix the Y-tiling pitch setup. The pitch to the next tile in Y is
32 scanlines, not 8.
|
|
It turns out that it's not just deviceID dependent, and there's some additional
undefined factor that determines the bit 6 swizzling. It's now controllable
with swizzle_mode=[012] until we get a response on how to automatically detect.
|
|
This was broken in the merge of 965 blit support. It tried to lock only
when things were already locked.
|
|
Most of these were to ensure that caches got synchronized between 2d (or meta)
rendering and later use of the target as a source, such as for texture
miptree setup. Those are replaced with intel_batchbuffer_emit_mi_flush(),
which just drops an MI_FLUSH. Most of the remainder were to ensure that
REFERENCES_CLIPRECTS batchbuffers got flushed before the lock was dropped.
Those are now replaced by automatically flushing those when dropping the lock.
|
|
|
|
Nothing would get drawn as the negative coordinates broke the rectangle
intersection code that used unsigned ints. Tested with copypix demo and
sliding the copy to the upper left.
|
|
This disables the textured copy implementation on 965, which didn't appear
to work (mesa copypix demo, disable the blit path, move so that regions don't
overlap and textured is used, and you get garbage). If we resurrect this for
i965, I'd rather it used the 915-style metaops instead. Current metaops code
left in place so that whoever picks it up has a reference.
|
|
|
|
Mesa demos tend to leave blending on but in GL_ONE/GL_ZERO, or
GL_SRC_ALPHA/GL_ONE_MINUS_SRC_ALPHA with a source alpha of 1.0.
|
|
Both had some useful bits for the other.
|
|
|
|
|
|
Taken from commit bad6e175cf59cce630c37d73f6e71f3a4de50ae6.
|
|
This matches 965.
|
|
This lets GEM use pwrite, for an additional 4% or so speedup.
|
|
|
|
|
|
Since the asm_subdirs target does not actually create a file, make will
always consider that it needs to be rebuilt. If libmesa.a and libglapi.a
have asm_subdirs as a prerequisite, then they will always need to be
rebuilt, too. The correct order will be preserved by the default target,
though.
This should fix #16358.
|
|
If `make install' is run without running `make' first, the $(LIB_DIR)
will not be created. This also changes the mkdir a little bit so that it
isn't run if necessary and added `-p' so that it is immune to races.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Brian Paul <brian.paul@tungstengraphics.com>
|
|
Signed-off-by: Brian Paul <brian.paul@tungstengraphics.com>
|
|
Add #include "glheader.h" for definition of __builtin_expect for compilers
that don't support it.
Signed-off-by: Brian Paul <brian.paul@tungstengraphics.com>
|
|
See bug 14289
|
|
|
|
This is just a hack. After we convert the 3D texcoord into a face plus 2D
texcoord we need to recompute the partial derivatives and mipmap LOD.
But we don't have the info to do that. Adjusting the original mipmap
level by -1 seems to give somewhat better results than before though.
|
|
|
