summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri
Commit message (Collapse)AuthorAgeFilesLines
* r300: fix vertex limitsMaciej Cencora2009-07-052-22/+7
| | | | | | | - don't limit vertex count if we are using indices - max indices count is 65535 not 65536 - remove some comments that don't apply anymore - remove unreachable code
* Merge branch 'mesa_7_5_branch'Jakob Bornecrantz2009-07-031-0/+1
|\ | | | | | | | | | | Conflicts: src/mesa/main/dlist.c src/mesa/vbo/vbo_save_api.c
| * intel: Also update stencil bits in intel_update_wrapper().Michel Dänzer2009-07-031-0/+1
| | | | | | | | | | Fixes assertion failure when binding depth/stencil texture to FBO stencil attachment.
| * i915: Fix assertion failure on remapping a non-BO-backed VBO.Eric Anholt2009-06-301-1/+4
| | | | | | | | | | | | Failure to set the obj->Pointer back to null tripped up the assertion. Bug #22428. (cherry picked from commit 57a06d3a48c9af1067ec05e3ad96c58f4b9b99be)
* | radeon: Wait for BO idle if necessary before mapping it.Michel Dänzer2009-07-031-0/+2
| | | | | | | | Fixes fighting between GPU and software rendering with TTM.
* | r300: Guard debugging output.Michel Dänzer2009-07-031-2/+3
| |
* | intel: Fall back on glBitmap with fog enabled.Eric Anholt2009-07-021-0/+6
| | | | | | | | | | | | | | We would have to build the program with the appropriate fog mode, and also supply the fog coordinate if appropriate. Bug #19413.
* | intel: Flush when mapping buffer objects so writes don't get reordered.Eric Anholt2009-07-022-0/+5
| | | | | | | | | | While GEM covers this for execution it knows about, it doesn't know about the batchbuffer we're preparing. Fixes piglit vbo-map-remap.c testcase.
* | intel: Fix leak of DRI option info due to using the wrong free routine.Eric Anholt2009-07-021-1/+1
| |
* | intel: Clean up leak of driver context structure on context destroy.Eric Anholt2009-07-021-1/+2
| |
* | intel: Init num_fences to clean up valgrind warning.Eric Anholt2009-07-021-1/+1
| | | | | | | | | | Valgrind doesn't know that a successful getparam sets the target of the pointer, so just set the value beforehand.
* | radeon/r200/r300: drop radeon renderbuffer private width/heightDave Airlie2009-07-025-15/+13
| | | | | | | | half stealing the code without taking the intel regions
* | radeon/r300: use base width/height.Dave Airlie2009-07-022-12/+13
| | | | | | | | I suspect this might break TFP in some way but it makes firecube run here
* | i965: fixes for JMPIXiang, Haihao2009-07-023-10/+14
| | | | | | | | | | | | | | 1. the data type of <src1> (JMPI offset) must be D 2. execution size must be 1 3. NoMask 4. instruction compression isn't allowed.
* | intel: Avoid pointer arithmetic on void *.Eric Anholt2009-06-301-1/+1
| | | | | | | | Bug #22000.
* | i965: Increase G4X default VS URB allocation to actually allow 32 threads.Eric Anholt2009-06-301-3/+14
| | | | | | | | | | This improves the performance of my GLSL demo by 30%. It also fixes the VS deadlock that ut2004 had, for reasons I can't explain. Bug #21330.
* | i965: first attempt at handling URB overflow when there's too many vs outputsBrian Paul2009-06-302-4/+49
| | | | | | | | | | | | | | | | | | | | | | If we can't fit all the VS outputs into the MRF, we need to overflow into temporary GRF registers, then use some MOVs and a second brw_urb_WRITE() instruction to place the overflow vertex results into the URB. This is hit when a vertex/fragment shader pair has a large number of varying variables (12 or more). There's still something broken here, but it seems close...
* | i965: use BRW_MAX_MRFBrian Paul2009-06-301-1/+1
| |
* | i965: use BRW_MAX_GRF, BRW_MAX_MRFBrian Paul2009-06-301-2/+3
| |
* | i965: move BRW_MAX_GRF, define BRW_MAX_MRFBrian Paul2009-06-302-6/+8
| |
* | i965: defined BRW_MAX_MRFBrian Paul2009-06-301-0/+3
| |
* | i965: comments and a new assertionBrian Paul2009-06-301-2/+4
| |
* | i915: Fix assertion failure on remapping a non-BO-backed VBO.Eric Anholt2009-06-301-1/+4
| | | | | | | | | | Failure to set the obj->Pointer back to null tripped up the assertion. Bug #22428.
* | intel: Enable EXT_gpu_program_parameters.Eric Anholt2009-06-291-0/+2
| | | | | | | | | | There doesn't appear to be any driver impact for enabling this, and tests/prog_parameter passes.
* | Merge branch 'mesa_7_5_branch'Brian Paul2009-06-291-1/+1
|\|
| * intel: added null ptr checkBrian Paul2009-06-291-1/+1
| | | | | | | | This fixes a segfault seen with piglit's fdo20701 test.
* | Revert "intel: Remove unneded pthread mutex in LOCK_HARDWARE."Eric Anholt2009-06-291-1/+8
| | | | | | | | | | | | | | | | | | | | | | This reverts commit de447afff26706e3bf8bdcd5cfb8b1daf49b4b21 but puts the lock under DRI1-only. From keithw: > It's there because the DRI1 code doesn't actually achieve the mutexing > which it looks as if it should. For multi-threaded applications it was > always possible to get two threads inside locked regions -- I have no > idea how, but it certainly was and presumably still is possible.
* | intel: Move note_unlock() implementation to the one place it's needed.Eric Anholt2009-06-296-26/+2
| |
* | intel: Remove unneded pthread mutex in LOCK_HARDWARE.Eric Anholt2009-06-291-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | This would cause LOCK_HARDWARE to mutex all contexts in this process on both DRI1 and DRI2. On DRI1, LOCK_HARDWARE already does it for all processes on the system. On DRI2, LOCK_HARDWARE doesn't, but there shouldn't be any state outside the context that needs any additional protection. Notably, the bufmgr is protected by its own mutex and not LOCK_HARDWARE. This code was originally introduced with the i915tex code dump, so it's not clear what it was there for.
* | intel: Make LOCK_HARDWARE recursive to avoid hand-rolling recursiveness.Eric Anholt2009-06-295-47/+19
| |
* | Revert "r200: make use of DMA buffers for Elts a lot better."Dave Airlie2009-06-293-19/+16
| | | | | | | | | | | | This reverts commit 0952645fe04a27968565ea4d913500c23b1b11e3. Need to revisit where this is going wrong
* | radeon: Always initialize front and back renderbuffers if presentNicolai Hähnle2009-06-271-2/+1
| | | | | | | | | | | | This fixes an assertion in glReadPixels from the front buffer. Signed-off-by: Nicolai Hähnle <[email protected]>
* | radeon: Update .gitignoreNicolai Hähnle2009-06-272-2/+25
| | | | | | | | | | | | | | Add all source files that are symlink'ed from common radeon code to the ignore list. Signed-off-by: Nicolai Hähnle <[email protected]>
* | Merge branch 'arb_vertex_array_object'Brian Paul2009-06-262-19/+47
|\ \
| * | intel: enable GL_ARB_vertex_array_object extensionBrian Paul2009-06-221-0/+2
| | |
| * | mesa: regenerated files related to GL_ARB_vertex_array_objectBrian Paul2009-06-191-19/+45
| | |
* | | Merge branch 'mesa_7_5_branch'Brian Paul2009-06-261-0/+11
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | Conflicts: Makefile src/gallium/drivers/softpipe/sp_screen.c src/mesa/main/version.h
| * | intel / DRI2: Additional flush of fake front-buffer to real front-bufferIan Romanick2009-06-261-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To maintain correctness, the server will copy the real front-buffer to a newly allocated fake front-buffer in DRI2GetBuffersWithFormat. However, if the DRI2GetBuffersWithFormat is triggered by glViewport, this will copy stale data into the new buffer. Fix this by flushing the current fake front-buffer to the real front-buffer in intel_viewport. Fixes bug #22288.
* | | i965: fix fetching constants from constant buffer in glsl pathRoland Scheidegger2009-06-264-17/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the driver used to overwrite grf0 then use implicit move by send instruction to move contents of grf0 to mrf1. However, we must not overwrite grf0 since it's still used later for fb write. Instead, do the move directly do mrf1 (we could use implicit move from another grf reg to mrf1 but since we need a mov to encode the data anyway it doesn't seem to make sense). I think the dp_READ/WRITE_16 functions may suffer from the same issue. While here also remove unnecessary msg_reg_nr parameter from the dataport functions since always message register 1 is used.
* | | r200: make use of DMA buffers for Elts a lot better.Dave Airlie2009-06-263-16/+19
| | | | | | | | | | | | | | | This allows us to return the unused portion of the dma buffer to the allocator instead of wasting nearly 16k a pop.
* | | r200: only emit unitneeded texturesDave Airlie2009-06-261-0/+2
| | |
* | | radeon: fix hw texture limitsRoland Scheidegger2009-06-253-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | still always enable max, but the right values this time. More work should probably be done for saner limits without mm, and/or dri conf option allow_large_textures (which is ignored) removed. 3D limit on r100 is pretty arbitrary as still handled by swrast anyway. Also fix r300 limits (except 3d I've no idea what the max is anyway so keep using mesa default).
* | | radeon/r200: add some hw texture limitsDave Airlie2009-06-252-2/+8
| | |
* | | radeon: fix stupidity in cs space check code.Dave Airlie2009-06-251-2/+6
| | | | | | | | | | | | This was already correct in the GEM code
* | | intel: fix additional merge conflicts missed in previous commitBrian Paul2009-06-242-18/+0
| | |
* | | Merge branch 'mesa_7_5_branch'Brian Paul2009-06-243-0/+21
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/mesa/drivers/dri/i915/i915_tex_layout.c src/mesa/drivers/dri/i965/brw_wm_glsl.c src/mesa/drivers/dri/intel/intel_buffer_objects.c src/mesa/drivers/dri/intel/intel_pixel_bitmap.c src/mesa/drivers/dri/intel/intel_pixel_draw.c src/mesa/main/enums.c src/mesa/main/texstate.c src/mesa/vbo/vbo_exec_array.c
| * | i965: handle OPCODE_SWZ in the glsl pathRoland Scheidegger2009-06-221-0/+1
| | | | | | | | | | | | | | | | | | | | | glsl compiler will not generate OPCODE_SWZ, and as a first step it would be translated away to a MOV anyway (why?), but later internally this opcode is generated (for EXT_texture_swizzling). (cherry picked from commit 4ef1f8e3b52a06fcf58f78c9c36738531b91dbac)
| * | intel: intel_texture_drawpixels() can't handle GL_DEPTH_STENCIL.Michel Dänzer2009-06-221-1/+1
| | | | | | | | | | | | | | | Fixes glean depthStencil test. (cherry picked from commit 3885b708fdbb7bbd5dd3a247c41fb9a75ee7c057)
| * | i965: added intelFlush() call in intel_get_tex_image()Brian Paul2009-06-221-0/+6
| | | | | | | | | | | | | | | Fixes the render-to-texture test in progs/tests/getteximage.c (cherry picked from commit a03b349153660e449daf4f56d750f1caef23b1a5)
| * | intel: Fix other metaops versus GL_COMPILE_AND_EXECUTE dlists.Eric Anholt2009-06-192-3/+3
| | | | | | | | | | | | | | | | | | Fixes oglconform zbfunc.c and pxtrans-cidraw.c, at least. (cherry picked from commit 405300bb190f516e16b704050abe3389b366ed27)