| Age | Commit message (Collapse) | Author |
|---|
|
|
|
See the conversation between myself and Tommy Schultz Lassen on mesa3d-dev.
|
|
|
|
|
|
|
|
|
|
This reverts commit 07ac2386f5c0ab9c2432d4b5e3490b1e13d033fc.
|
|
|
|
|
|
|
|
Apparently for back facing color to work you must set all 3 color bits; I guess
the hardware cannot handle them separately.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. Use more reasonable hither/yon clip planes to make better use of shallow
(16-bit) z buffers.
2. Use different colors on cube faces to help detect Z fighting if it occurs.
3. Report GL_DEPTH_BITS on start-up.
|
|
|
|
|
|
|
|
|
|
The previous procedure would often result in a GPU lockup.
|
|
This avoids superfluous waits for vblank timing out under some circumstances.
|
|
Not doing this could lead to double frees under rare circumstances.
|
|
width/height/depth == 0 is a legal texture size (no error generated).
Later, the texture will be considered incomplete, however, and texturing
will effectively be disabled.
See bug 11309.
|
|
|
|
|
|
|
|
Also, check if we're in RGB vs. CI mode. This fixes a problem with
incorrect rendering color seen with the redbook/polys demo.
|
|
The t_dd_tritemp.h code can emit GL_QUADS primitives. We need to catch
that case to determine if polygon stipple should be enabled.
Fixes bug reported by Carlos Diógenes on 4 July 2007.
|
|
|
|
|
|
|
|
|
|
|
|
of -I flags.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#11030)
|
|
|
|
|
|
Compiz for some reason looks like ass, everything with textures
looks like it has a 2x width/height multiplier on the texture coords...
|
