summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'mesa_7_5_branch'Brian Paul2009-05-184-11/+31
|\ | | | | | | | | | | | | Conflicts: Makefile src/mesa/main/version.h
| * st/mesa: fix incorrect src/dst stride params to _mesa_generate_mipmap_level()Brian Paul2009-05-181-2/+6
| | | | | | | | The stride needs to be in texels, not bytes.
| * mesa: comments for _mesa_generate_mipmap_level()Brian Paul2009-05-181-0/+3
| |
| * st: fix incorrect target parameter to screen->is_format_supported()Brian Paul2009-05-181-1/+1
| | | | | | | | We were passing a GL texture target instead of a pipe_texture_target enum.
| * mesa: bump version to 7.5-rc2mesa_7_5_rc2Brian Paul2009-05-151-1/+1
| |
| * r300: Make sure to drop current hardware state reference to texture objects.Michel Dänzer2009-05-142-8/+21
| | | | | | | | Fixes potential texture object leaks.
* | intel: Don't complain on falling back from PBO fastpaths.Eric Anholt2009-05-151-3/+3
| | | | | | | | | | | | Instead, stash the debug info under the handy debug flag. Bug #20053
* | mesa: Mark FBOs with compressed color attachments as FBO-incomplete.Eric Anholt2009-05-151-0/+5
| | | | | | | | | | | | | | | | Both EXT_fbo and ARB_fbo agree on this. Fixes a segfault in the metaops mipmap generation in Intel for SGIS_generate_mipmap of S3TC textures in Regnum Online. Bug #21654.
* | i915: Fix 945 cube map layout for the small mipmaps along the bottom.Steinar H. Gunderson2009-05-151-2/+14
| | | | | | | | Bug #21691.
* | i915: Use Stencil.Enabled instead of Stencil._Enabled in DrawBuffers.Eric Anholt2009-05-151-1/+1
| | | | | | | | | | | | | | | | The _Enabled field isn't updated at the point that DrawBuffers is called, and the Driver.Enable() function does the testing for stencil buffer presence anyway. bug #21608 for Radeon
* | i915: Only use the new 945 cube layout for compressed textures.Eric Anholt2009-05-151-1/+4
| | | | | | | | | | | | | | | | | | The docs actually explain this, but not in a terribly clear manner. This nearly fixes the piglit cubemap testcase, except that something's going wrong with the nearest filtering at 2x2 sizes in the testcase. Looks good by visual inspection, though. Bug #21692
* | i965: Fix varying payload reg assignment for the non-GLSL-instructions path.Eric Anholt2009-05-141-8/+10
| | | | | | | | I don't have a testcase for this, but it seems clearly wrong.
* | i965: Fix register allocation of GLSL fp inputs.Eric Anholt2009-05-144-13/+27
| | | | | | | | | | | | | | | | | | Before, if the VP output something that is in the attributes coming into the WM but which isn't used by the WM, then WM would end up reading subsequent varyings from the wrong places. This was visible with a GLSL demo using gl_PointSize in the VS and a varying in the WM, as point size is in the VUE but not used by the WM. There is now a regression test in piglit, glsl-unused-varying.
* | intel: Use FRONT_AND_BACK for StencilOp as well.Eric Anholt2009-05-141-1/+2
| |
* | intel: Use GL_FRONT_AND_BACK for stencil clearing.Eric Anholt2009-05-141-1/+2
| | | | | | | | | | This comes from a radeon-rewrite fallback fix, but may also fix stencil clear failure when the polygon winding mode is flipped.
* | i965: fix 1D texture borders with GL_CLAMP_TO_BORDERRobert Ellison2009-05-141-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | With 1D textures, GL_TEXTURE_WRAP_T should be ignored (only GL_TEXTURE_WRAP_S should be respected). But the i965 hardware seems to follow the value of GL_TEXTURE_WRAP_T even when sampling 1D textures. This fix forces GL_TEXTURE_WRAP_T to be GL_REPEAT whenever 1D textures are used; this allows the texture to be sampled correctly, avoiding "imaginary" border elements in the T direction. This bug was demonstrated in the Piglit tex1d-2dborder test. With this fix, that test passes.
* | i965: send all warnings through _mesa_warning()Robert Ellison2009-05-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | One warning message: drm_i915_getparam: -22 was still being sent to fprintf(). This causes all Piglit tests to fail, even with MESA_DEBUG=0. Using _mesa_warning() to emit the message allows the general Mesa controls for messages like this to be applied.
* | Merge branch 'mesa_7_5_branch'Brian Paul2009-05-131-1/+2
|\|
| * intel: added null ptr checkBrian Paul2009-05-131-1/+2
| | | | | | | | Fixes segfault in context tear-down when glClear was never called.
* | intel: enable GL_APPLE_vertex_array_objectBrian Paul2009-05-131-0/+2
| | | | | | | | No special driver changes are needed for this extension.
* | st/mesa: enable GL_APPLE_vertex_array_object for gallium driversBrian Paul2009-05-132-0/+7
| |
* | Merge branch 'mesa_7_5_branch'Brian Paul2009-05-134-29/+76
|\| | | | | | | | | | | | | | | Conflicts: src/mesa/main/arrayobj.c src/mesa/main/arrayobj.h src/mesa/main/context.c
| * intel: create a private gl_array_object for intel_clear_tris(), fix bug 21638Brian Paul2009-05-133-29/+75
| | | | | | | | | | | | | | | | | | gl_array_object encapsulates a set of vertex arrays (see the GL_APPLE_vertex_array_object extension). Create a private gl_array_object for drawing the quad for intel_clear_tris() so we don't have to worry about the user's vertex array state. This fixes the no-op glClear bug #21638 and removes the need to call _mesa_PushClientAttrib() and _mesa_PopClientAttrib().
| * mesa: delete array objects before buffer objects during context tear-downBrian Paul2009-05-131-1/+2
| | | | | | | | The former may point to the later.
| * mesa: clean-up vertex array object VBO unbinding and delete/refcountingBrian Paul2009-05-131-31/+33
| | | | | | | | | | | | Don't really delete vertex array objects until the refcount hits zero. At that time, unbind any pointers to VBOs. (cherry picked from commit 32b851c80792623195069d7a41a5808cff3b2f6f)
| * mesa: reference counting for gl_array_objectBrian Paul2009-05-134-13/+84
| | | | | | | | | | | | Every kind of object that can be shared by multiple contexts should be refcounted. (cherry picked from commit 1030bf0ded2a88a5e27f7a4d393c11cfde3d3c5a)
| * Test either GL_FRONT_LEFT or GL_FRONT for front-buffer renderingIan Romanick2009-05-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | For non-stereo visuals, which is all we support, we treat GL_FRONT_LEFT as GL_FRONT. However, they are technically different, and they have different enum values. Test for either one to determine if we're in front-buffer rendering mode. This fix was suggested by Pierre Willenbrock. Signed-off-by: Ian Romanick <[email protected]> (cherry picked from commit 2085cf24628be7cd297ab0f9ef5ce02bd5a006e2)
* | i965: enable additional code in emit_fb_write()Brian Paul2009-05-121-11/+10
| | | | | | | | Not 100% sure this is right, but the invalid assertion is fixed...
* | i965: increase BRW_EU_MAX_INSNBrian Paul2009-05-121-1/+1
| |
* | i965: commentBrian Paul2009-05-121-0/+4
| |
* | intel: Skip the DRI2 renderbuffer update when doing Viewport on an FBO.Eric Anholt2009-05-121-1/+1
| |
* | intel: Map write-only buffer objects through the GTT when possible.Eric Anholt2009-05-122-2/+15
| | | | | | | | | | This looks to be a win of a few percent in cairogears with new vbo code, thanks to not polluting caches.
* | i915: Fix driver after HW glGenerateMipmap commit.Eric Anholt2009-05-121-0/+1
| |
* | swrast: update/restore the opt_sample_rgb/rgba_2d() functionsBrian Paul2009-05-121-15/+9
| |
* | Merge branch 'mesa_7_5_branch'Brian Paul2009-05-112-6/+17
|\| | | | | | | | | | | | | Conflicts: Makefile src/mesa/main/version.h
| * st: do proper refcounting for framebuffer surfacesBrian Paul2009-05-112-6/+17
| |
| * mesa: Fixed a texture memory leakBrian Paul2009-05-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The current texture for any particular texture unit is given an additional reference in update_texture_state(); but if the context is closed before that texture can be released (which is quite frequent in normal use, unless a program unbinds and deletes the texture and renders without it to force a call to update_texture_state(), the memory is lost. This affects general Mesa; but the i965 is particularly affected because it allocates a considerable amount of additional memory for each allocated texture. (cherry picked from master, commit c230767d6956b63a2b101acb48f98823bb5dd31a)
| * mesa: set version to 7.5-rc1Brian Paul2009-05-081-1/+1
| |
| * mesa/st: keep surface_copy arguments positiveKeith Whitwell2009-05-082-3/+68
| | | | | | | | | | | | | | The src/dest x,y, and w,h arguments of the pipe->surface_copy function are unsigned and the drivers aren't expecting negative (or extremly-large unsigned) values as inputs. Trim the requests at the state-tracker level before passing down.
| * mesa/st: remove redundant call to st_finish in CopyTexSubImageKeith Whitwell2009-05-081-3/+0
| | | | | | | | | | Rendering should already have been flushed, any synchronization will be done by the driver or memory manager.
| * mesa/st: cope with non-ibo index data in st_draw_feedback.cKeith Whitwell2009-05-081-8/+15
| | | | | | | | | | | | Previously only non-indexed or indicies-in-a-vbo cases were handled in this code. This change adds the missing regular indices-in-memory case.
| * mesa: Make _mesa_share_state thread safe.José Fonseca2009-05-081-2/+9
| |
| * mesa: more complete fix for transform_invarient glitchesKeith Whitwell2009-05-086-11/+153
| | | | | | | | | | | | Add a new flag mvp_with_dp4 in the context, and use that to switch both ffvertex.c and programopt.c vertex transformation code to either DP4 or MUL/MAD implementations.
| * mesa/main: set PREFER_DP4 to match position_invarient codeKeith Whitwell2009-05-081-1/+1
| | | | | | | | | | | | | | | | This is a quick fix for z fighting in quake4 caused by the mismatch between vertex transformation here and in the position_invarient code. Full fix would be to make this driver-tunable and adjust both position_invarient and ffvertex_prog.c code to respect driver preferences.
* | mesa: updated comments for _mesa_generate_mipmap()Brian Paul2009-05-111-2/+5
| |
* | i965: handle extended swizzle terms (0,1) in get_src_reg()Brian Paul2009-05-111-0/+8
| | | | | | | | Fixes failed assertion in progs/glsl/twoside.c (but still wrong rendering).
* | mesa: better handling/printing of driver-specific opcodes, register filesBrian Paul2009-05-112-4/+14
| | | | | | | | | | Drivers such as i965 define extra instruction opcodes and register files. Improve the program printing code to handle those opcodes/files better.
* | i965: improve debug loggingRobert Ellison2009-05-083-14/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looking for memory leaks that were causing crashes in my environment in a situation where valgrind would not work, I ended up improving the i965 debug traces so I could better see where the memory was being allocated and where it was going, in the regions and miptrees code, and in the state caches. These traces were specific enough that external scripts could determine what elements were not being released, and where the memory leaks were. I also ended up creating my own backtrace code in intel_regions.c, to determine exactly where regions were being allocated and for what, since valgrind wasn't working. Because it was useful, I left it in, but disabled and compiled out. It can be activated by changing a flag at the top of the file.
* | i965: fix memory leak in context/renderbuffer region managementRobert Ellison2009-05-081-4/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A temporary change to the intelMakeCurrent() function to make it work with frame buffer objects causes the static regions associated with the context (the front_region, back_region, and depth_region) to take on an additional reference, with no corresponding release. This causes a memory leak if a program repeatedly creates and destroys contexts. The fix is the corresponding hack, to unreference these regions when the context is deleted, but only if the framebuffer objects are still present and the same regions are still referenced within. Both sets of code have comment blocks referring to each other.
* | i965: fix segfault on low memory conditionsRobert Ellison2009-05-081-0/+7
| | | | | | | | | | | | | | When out of memory (in at least one case, triggered by a longrunning memory leak), this code will segfault and crash. By checking for the out-of-memory condition, the system can continue, and will report the out-of-memory error later, a much preferable outcome.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 22:35:08 +0000