summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
* intel: no-op the intel_finish_render_texture() functionBrian Paul2009-02-261-13/+10
| | | | It doesn't have to do anything. See comments for more details.
* intel: check texture formats in intel_validate_framebuffer()Brian Paul2009-02-261-0/+29
| | | | | | | | | We can't render into any texture format; only certain formats. Check that render-to-texture's format is renderable in the intel_validate_framebuffer() There seems to be a bug somewhere that causes rendering to rgb565 textures to be corrupted so disallow that for now. This will be revisted.
* intel: updated comment, some debug code (disabled)Brian Paul2009-02-261-3/+12
|
* i965: rename draw_regions -> color_regionsroot2009-02-264-20/+20
| | | | Be a little more specific about what these are.
* i965: add missing init for region->widthBrian Paul2009-02-261-1/+2
| | | | | This doesn't seem to really effect anything but seeing width=0 in drawing regions was confusing.
* mesa: replace old prog_instruction::Sampler field with Aux fieldBrian Paul2009-02-263-10/+9
| | | | | | The i965 driver needs an extra instruction field for color output information. It was using the Sampler field for this. Use the Aux field instead. This will probaby be revisited at some point...
* i965: whitespace/indentation fixesBrian Paul2009-02-261-28/+24
|
* intel: Revert disable of accelerated Bitmap, which slipped in with spans stuff.Eric Anholt2009-02-261-2/+2
|
* i965: fix for RHW workaroundXiang, Haihao2009-02-262-43/+99
| | | | | | It is possible that an object whose vertices all are outside of a view plane is passed to clip thread due to the RHW workaround. This object should be rejected by clip thread. Fix bug #19879
* intel: Disable creating DRI2 FBconfigs with depth size != color size.Eric Anholt2009-02-261-1/+22
| | | | | | | | | | While it's a nice idea to be able to allow clients to choose a smaller (or bigger for 16bpp screens!) depth size, right now DRI2 hands back a buffer with a size that matches the drawable, rather than being based off of the visual. This led to problems in readback as parts of the driver disagreed on what format the depth buffer was really in. Fixes the remainder of bug #19447.
* intel: Add span code for z24 without stencil.Eric Anholt2009-02-261-2/+22
| | | | | | | | It seems that in this case the Mesa code is handing us x8z24 values instead of z24s8 values, so we need to not do the rotation. Fixes half of OGLconform depthrange.c. Bug #19447.
* intel: make template wrappers for the spans templates.Eric Anholt2009-02-254-189/+165
| | | | | This is insanity, but so is copying the same blocks containing the actual interesting code in the file three times each for the different tile formats.
* intel: Fix up x8r8g8b8 renderbuffer format so that alpha=1 spans code happens.Eric Anholt2009-02-252-1/+17
| | | | | | | | I was lured into a false sense of security by the fact that the spans code was already there, and a bunch of tests didn't catch the problem. oglconform's mask.c did, though. Bug #19970.
* i965: Rename CMD_CONST_BUFFER_STATE to the CS_URB_STATE used in the docs.Eric Anholt2009-02-256-13/+14
|
* R300: Add support for RS600 chipsAlex Deucher2009-02-252-2/+12
|
* i965: fix line stipple fallback for GL_LINE_STRIP primitivesRobert Ellison2009-02-231-1/+1
| | | | | | | | | | When doing line stipple, the stipple count resets on each line segment, unless the primitive is a GL_LINE_LOOP or a GL_LINE_STRIP. The existing code correctly identifies the need for a software fallback to handle conformant line stipple on GL_LINE_LOOP primitives, but neglects to make the same assessment on GL_LINE_STRIP primitives. This fixes it so they match.
* mesa: fix _glxapi_get_proc_address() for mangled namesTom Fogal2009-02-231-0/+5
|
* mesa: move a bunch of compiler-related stuff into new compiler.h headerBrian Paul2009-02-221-0/+1
| | | | This trims down and cleans up imports.h and glheader.h quite a bit.
* texmem: fix typo from brianp's changes.Dave Airlie2009-02-221-1/+1
| | | | Reported by cjb via tinderbox on irc
* mesa: use an array for current texture objectsBrian Paul2009-02-216-21/+21
| | | | Use loops to consolidate lots of texture object code.
* mesa: re-org texgen stateBrian Paul2009-02-212-31/+35
| | | | New gl_texgen struct allows quite a bit of code reduction.
* intel: Fix intelSetTexBuffer miptree leak.Kristian Høgsberg2009-02-211-2/+7
| | | | The intelImage also holds a reference to the miptree, so unref that as well.
* intel: tell libdrm whether we want a cpu-ready or gpu-ready BO for regions.Eric Anholt2009-02-217-13/+27
| | | | | | | | | | This lets us avoid allocing new buffers for renderbuffers, finalized miptrees, and PBO-uploaded textures when there's an unreferenced but still active one cached, while also avoiding CPU waits for batchbuffers and CPU-uploaded textures. The size of BOs allocated for a desktop running current GL cairogears on i915 is cut in half with this. Note that this means we require libdrm 2.4.5.
* i965: Fix render target read domains.Eric Anholt2009-02-211-2/+1
| | | | | | | | | | | We were asking for something illegal (write_domain != 0 && read_domains != write_domain) because at the time of writing the region surfaces were used for texturing occasionally as well, and we weren't really clear on the model GEM was going to use. This reliably triggered a kernel bug with domain handling, resulting in oglconform mustpass.c failure. Of course, it only became visible after 01bc4d441fd6821ad9fc20d5e9544e4e587e4ff0 cleaned up some gratuitous flushing.
* i965: use the new prog_instruction::TexShadow fieldBrian Paul2009-02-205-6/+11
| | | | | GLSL shadow() sampler calls are properly propogated down to the driver now. The glean glsl1 shadow() tests work (except for the alpha channel).
* i965: check depth_mode in translate_tex_format() for MESA_FORMAT_S8_Z24Brian Paul2009-02-201-1/+9
| | | | | Note that I24X8 vs. A24X8 vs. L24X8 doesn't seem to make any difference for texture/shadow compare, however.
* i965: separate emit_op() and emit_tex_op() functionsBrian Paul2009-02-201-50/+63
|
* i965: update comment, use const qualifierBrian Paul2009-02-201-4/+2
|
* i965: var renaming, clean-upBrian Paul2009-02-201-13/+11
|
* i965: added commentBrian Paul2009-02-201-1/+1
|
* intel: fix datatype typo, s/GLboolean/GLuint/Brian Paul2009-02-201-1/+1
| | | | Fixes mysterious failures in glean glsl1 test.
* i965: additional debug outputBrian Paul2009-02-201-0/+8
|
* glsl: added --params option to stand-alone GLSL compilerBrian Paul2009-02-171-0/+8
| | | | Prints program parameter info
* intel: Fix tri clear to do FBO color attachments as well.Eric Anholt2009-02-171-8/+25
| | | | | This is a 2% win in fbo_firecube, and would avoid a sw fallback for masked clears.
* i965: Fix fallback on stencil drawing to fbo when the visual lacks stencil.Eric Anholt2009-02-171-2/+2
| | | | Noticed this with the fbotexture demo.
* intel: Clean up several 965 memory leaks on context destroy.Eric Anholt2009-02-175-2/+8
|
* i965: tell GLSL compiler to emit code using condition codesBrian Paul2009-02-161-0/+3
| | | | | | The default for EmitCondCodes got flipped when gallium-0.2 was merged. This fixes GLSL if/else/endif regressions. Drivers that use GLSL should always explicitly set the flag to be safe.
* r300: Redirect constant TEX coordinatesNicolai Haehnle2009-02-142-0/+32
| | | | | | | | | | | | | R3xx/R5xx fragment program texture constants must come from a hardware register instead of the constant file, so we redirect if necessary during the native rewrite phase. The symptoms of this bug started appearing when the Mesa fixed function texenvprogram code started using STATE_CURRENT_ATTRIB constants for texture coordinates when the corresponding attributes were constant across all vertices. Signed-off-by: Nicolai Haehnle <[email protected]>
* i965: rewrite the code for handling shader subroutine callsBrian Paul2009-02-136-64/+187
| | | | | | | | | | | | | | | | | | Previously, the prog_instruction::Data field was used to map original Mesa instructions to brw instructions in order to resolve subroutine calls. This was a rather tangled mess. Plus it's an obstacle to implementing dynamic allocation/growing of the instruction buffer (it's still a fixed size). Mesa's GLSL compiler emits a label for each subroutine and CAL instruction. Now we use those labels to patch the subroutine calls after code generation has been done. We just keep a list of all CAL instructions that needs patching and a list of all subroutine labels. It's a simple matter to resolve them. This also consolidates some redundant post-emit code between brw_vs_emit.c and brw_wm_glsl.c and removes some loops that cleared the prog_instruction::Data fields at the end. Plus, a bunch of new comments.
* i965: add missing break for OPCODE_RET caseBrian Paul2009-02-131-0/+1
| | | | This doesn't effect correctness, but we were emitting an extraneous ADD.
* i965: the return value of translate_insn() is never used. Make it void.Brian Paul2009-02-131-4/+3
|
* i965: minor clean-upsBrian Paul2009-02-131-27/+26
|
* i965: code clean-ups, comments, and minor refactoringBrian Paul2009-02-132-37/+65
|
* i965: updated commentsBrian Paul2009-02-131-17/+37
|
* intel: turn on GL_ARB_shading_language_120Brian Paul2009-02-131-4/+0
| | | | | It's done in the Mesa GLSL compiler. The only part of it that might matter in drivers is the centroid sampling option for MSAA.
* i965: more reformatting/clean-upBrian Paul2009-02-131-12/+10
|
* i965: s/__inline/INLINE/Brian Paul2009-02-131-4/+4
|
* i965: formatting and indentation fixesBrian Paul2009-02-131-17/+16
|
* i965: fix inconsistant indentation in brw_wm.cBrian Paul2009-02-131-37/+39
|
* Fix an i965 assertion failure on glClear()Robert Ellison2009-02-111-1/+1
| | | | | | | | | | | | | | | | | | | | While running conform with render-to-texture: conform -d 33 -v 2 -t -direct the i965 driver failed this assertion: intel_clear.c:77: intel_clear_tris: Assertion `(mask & ~((1 << BUFFER_BACK_LEFT) | (1 << BUFFER_FRONT_LEFT) | (1 << BUFFER_DEPTH) | (1 << BUFFER_STENCIL))) == 0' failed. The problem is that intel_clear_tris() is called by intelClear() to clear any and all of the available color buffers, but intel_clear_tris() actually only handles the back left and front left color buffers; so the assertion fails as soon as you try to clear a non-standard color buffer. The fix is to have intelClear() only call intel_clear_tris() with buffers that intel_clear_tris() can support. intelClear() already backs down to _swrast_Clear() for all buffers that aren't handled explicitly.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-20 07:15:01 +0000