- Mar 26, 2007
-
-
Brian Paul authored
-
Brian Paul authored
-
Michel Dänzer authored
Since the recent renderbuffer refcounting fixes it's no longer sufficient to just remove the old renderbuffer from the framebuffer and then add the new one because the former may decrease the reference count to 0 and delete the old renderbuffer.
-
Brian Paul authored
-
Brian Paul authored
-
Ben Skeggs authored
-
- Mar 25, 2007
-
-
Brian Paul authored
-
Brian Paul authored
-
Haihao Xiang authored
values for nr of entries) should meet the requirement.
-
Haihao Xiang authored
-
Nicolai Hähnle authored
-
Nicolai Hähnle authored
-
Nicolai Hähnle authored
The texture_rectangle fix introduced a bug where every texture instruction caused a new indirection.
-
- Mar 24, 2007
-
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
-
Brian Paul authored
-
Dave Airlie authored
Still crashes out on scissor regs
-
Nicolai Hähnle authored
R300 hardware takes texcoords in the range 0..1 even for rectangle textures. Previously, the necessary texcoord conversion was applied to the texture coordinate during vertex processing in a render stage. This is obviously wrong when fragment programs are used, which can calculate arbitrary coordinates for TEX instructions. Therefore, we now inject an appropriate MUL instruction before a TEX that reference a rectangle texture.
-
Nicolai Hähnle authored
There used to be an assertion when a fragment program accesses an incomplete texture image. Work around this assertion. Note: I am unsure whether this workaround produces the desired result (0,0,0,1) on all hardware.
-
Brian Paul authored
-
Brian Paul authored
When computing render_inputs_bitset, omit primary color if we have a fragment program and it doesn't need FRAG_ATTRIB_COL0. Silences valgrind warnings.
-
Brian Paul authored
-
Brian Paul authored
-
Nicolai Hähnle authored
When no textures were enabled, a KIL instruction triggered an assertion in r300_setup_rs_unit.
-
Nicolai Hähnle authored
-
Ben Skeggs authored
-
Brian Paul authored
Nicolai writes: When the pixmap pixel format has no alpha channel, the x11 driver (software rendering) adds a wrapped alpha channel on request. During SwapBuffers, this alpha channel is not copied from back to front, which means that the front buffer doesn't really contain the contents that the back buffer previously contained. A subsequent glReadPixels from the front buffer will return an incorrect result. The following patch attempts to fix this.
-
- Mar 23, 2007
-
-
Brian Paul authored
-
Brian Paul authored
IR_LOOP now has two children: the body code, and the tail code. Tail code is the "i++" part of a for-loop, or the expression at the end of a "do {} while(expr);" loop. "continue" translates into: "execute tail code; CONT;" Also, the test for infinite do/while loops was incorrect.
-
Brian Paul authored
-
Brian Paul authored
ctx->Shader.EmitCondCodes determines if we use condition codes. If not, IF statement uses first operand's X component as the condition. Added OPCODE_BRK0, OPCODE_BRK1, OPCODE_CONT0, OPCODE_CONT1 to handle the common cases of conditional break/continue.
-
Brian Paul authored
-
Brian Paul authored
-
Nicolai Hähnle authored
-
- Mar 22, 2007
-
-
Brian Paul authored
-
Brian Paul authored
Previously, comparing vec2, vec3, vec4 was broken. Added IR_EQUAL, IR_NOTEQUAL nodes/operators to compute boolean equality/inequality vs. IR_SEQUAL/IR_SNEQUAL which work component-wise. Use IR_EQUAL/IR_NOTEQUAL for the == and != operators. To compute vec4 equality, use SNE, DP4, SEQ instruction sequence.
-