aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/brw_draw.c
Commit message (Collapse)AuthorAgeFilesLines
* intel: Consistently use no_batch_wrap in intel_context struct.Eric Anholt2009-11-191-2/+2
|
* intel: Use PIPE_CONTROL on gen4 hardware for doing pipeline flushing.Eric Anholt2009-11-061-6/+2
| | | | | | This should do all the things that MI_FLUSH did, but it can be pipelined so that further rendering isn't blocked on the flush completion unless necessary.
* Merge branch 'mesa_7_6_branch'Brian Paul2009-09-091-0/+1
|\
| * Merge branch 'mesa_7_5_branch' into mesa_7_6_branchBrian Paul2009-09-091-0/+1
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: Makefile configs/default progs/glsl/Makefile src/gallium/auxiliary/util/u_simple_shaders.c src/gallium/state_trackers/glx/xlib/xm_api.c src/mesa/drivers/dri/i965/brw_draw_upload.c src/mesa/drivers/dri/i965/brw_vs_emit.c src/mesa/drivers/dri/intel/intel_context.h src/mesa/drivers/dri/intel/intel_pixel.c src/mesa/drivers/dri/intel/intel_pixel_read.c src/mesa/main/texenvprogram.c src/mesa/main/version.h
| | * i965: fix incorrect test for vertex position attributeBrian Paul2009-09-081-0/+1
| | |
* | | intel: Add support for ARB_draw_elements_base_vertex.Eric Anholt2009-09-081-1/+1
| | | | | | | | | | | | | | | On the 965, we just drop the value into the primitive packet. On non-945, we rely on the sw tnl code handling it.
* | | i965: #include clean-upsBrian Paul2009-09-081-7/+4
|/ /
* | i965: Avoid re-uploading the index buffer when we don't need to.Eric Anholt2009-08-121-0/+2
| | | | | | | | No performance difference proven at 95% confidence with my GLSL demo (n=10).
* | vbo: Avoid extra validation of DrawElements.Eric Anholt2009-08-121-38/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | This saves mapping the index buffer to get a bounds on the indices that drivers just drop on the floor in the VBO case (cache win), saves a bonus walk of the indices in the CheckArrayBounds case, and other miscellaneous validation. On intel it's a particularly a large win (50-100% in my app) because even though we let the indices stay in both CPU and GPU caches, we still end up waiting for the GPU to be done with the buffer before reading from it. Drivers that want the min/max_index fields must now check index_bounds_valid and use vbo_get_minmax_index before using them.
* | i965: Remove BRW_NEW_INPUT_VARYINGEric Anholt2009-07-071-7/+1
| | | | | | | | This state flag has been unused since the ffvertex_prog move to core.
* | intel: Move note_unlock() implementation to the one place it's needed.Eric Anholt2009-06-291-0/+2
|/
* intel: Add always_flush_batch driconf option for making small batchbuffers.Eric Anholt2009-03-051-0/+2
| | | | | This can improve debugging with INTEL_DEBUG=batch,sync by giving smaller batchbuffers.
* intel: Add always_flush_cache driconf option for debugging cache flush failure.Eric Anholt2009-03-051-0/+18
| | | | | I keep wanting to hack this knob in as a one-time thing, so it seemed useful to have all the time.
* i965: add software fallback for conformant 3D textures and GL_CLAMPRobert Ellison2009-03-041-5/+24
| | | | | | | | | | | | | | | | | The i965 hardware cannot do GL_CLAMP behavior on textures; an earlier commit forced a software fallback if strict conformance was required (i.e. the INTEL_STRICT_CONFORMANCE environment variable was set) and 2D textures were used, but it was somewhat flawed - it could trigger the software fallback even if 2D textures weren't enabled, as long as one texture unit was enabled. This fixes that, and adds software fallback for GL_CLAMP behavior with 1D and 3D textures. It also adds support for a particular setting of the INTEL_STRICT_CONFORMANCE environment variable, which forces software fallbacks to be taken *all* the time. This is helpful with debugging. The value is: export INTEL_STRICT_CONFORMANCE=2
* i965: texture fixes: bordered textures, fallback renderingRobert Ellison2009-02-271-3/+31
| | | | | | | | | | | | | | | | | | | | i965 doesn't natively support GL_CLAMP; it treats it like GL_CLAMP_TO_EDGE, which fails conformance tests. This fix adds a clause to the check_fallbacks() test to check whether GL_CLAMP is in use on any enabled 2D texture. If so, and if strict conformance is required (via INTEL_STRICT_CONFORMANCE), a software fallback is mandated. In addition, validate textures *before* checking for fallbacks, rather than after; otherwise, the texture state is never validated and can't be trusted. (In particular, if texturing is enabled and the sampler would access any level beyond level 0 of a texture, the sampler will segfault, because texture validation sets the firstLevel and lastLevel fields of a texture object so that the valid levels will be mapped and accessed correctly. If texture validation doesn't occur, only level 0 is accessed correctly, and that only because firstLevel and lastLevel happen to be set to 0.)
* 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.
* i965: Remove brw->attribs now that we can just always look in the GLcontext.Eric Anholt2009-02-021-9/+12
|
* i965: Delete old metaops code now that there are no remaining consumers.Eric Anholt2009-02-021-5/+2
|
* i965: Update state before checking for fallbacks in brw_try_draw_prims.Eric Anholt2008-12-151-2/+2
| | | | | | This got flipped around in 7855b2aef6bd9e9c2d73260b5cd166159b2525c6. Bug #18907. Thanks to idr for pointing me at a nicer testcase than blender.
* i965: Reduce fast-pathiness of brw_try_draw_prims, bringing in important checks.Eric Anholt2008-11-281-51/+52
| | | | | | | Later primitives, even if they caused a full state validate, wouldn't check that there was enough space in the batchbuffer, occasionally triggering the sanity check. We also skipped the aperture space check, even if it would mean bringing in new programs and associated state.
* i965: Upload state on primitive switch, don't just prepare it.Eric Anholt2008-11-121-0/+1
| | | | | This was a regression in 59b2c2adbbece27ccf54e58b598ea29cb3a5aa85 that broke blender, among other apps.
* i965: Fix check_aperture calls to cover everything needed for the prim at once.Eric Anholt2008-10-281-2/+30
| | | | | | | | Previously, since my check_aperture API change, we would check each piece of state against the batchbuffer individually, but not all the state against the batchbuffer at once. In addition to not being terribly useful in assuring success, it probably also increased CPU load by calling check_aperture many times per primitive.
* intel: Don't keep intel->pClipRects, and instead just calculate it when needed.Eric Anholt2008-10-281-13/+10
| | | | | | | This avoids issues with dereferencing stale cliprects around intel_draw_buffer time. Additionally, take advantage of cliprects staying constant for FBOs and DRI2, and emit cliprects in the batchbuffer instead of having to flush batch each time they change.
* i965: Add ARB_occlusion_query support.Eric Anholt2008-10-071-1/+1
|
* intel: Fix a number of memory leaks on context destroy.Eric Anholt2008-09-261-0/+10
|
* i965: Cope with batch getting flushed in the middle of batchbuffer emits.Eric Anholt2008-09-231-3/+6
| | | | | | | | | This isn't required for GEM (at least, yet), but the check_aperture code for non-GEM results in batch getting flushed during emit. brw_state_upload restarts state emits, but a bunch of the state emit functions were assuming that they would be called exactly once, after prepare and before new_batch. Bug #17179.
* mesa: added "main/" prefix to includes, remove some -I paths from ↵Brian Paul2008-09-181-5/+5
| | | | Makefile.template
* intel: track move of bo_exec from drivers to bufmgr.Eric Anholt2008-09-101-1/+0
|
* Revert "Revert "Merge branch 'drm-gem'""Dave Airlie2008-08-241-56/+16
| | | | This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
* Revert "Merge branch 'drm-gem'"Dave Airlie2008-08-241-16/+56
| | | | | | | | This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03. Conflicts: src/mesa/drivers/dri/i965/brw_wm_surface_state.c
* intel-gem: Update to new check_aperture API for classic mode.Eric Anholt2008-08-081-56/+16
| | | | | | To do this, I had to clean up some of 965 state upload stuff. We may end up over-emitting state in the aperture overflow case, but that should be rare, and I'd rather have the simplification of state management.
* i965: Check fallback before accounting for index/vertex buffer size. fix #16028.Xiang, Haihao2008-05-201-10/+8
|
* i965: Don't cast the result of brw_prepare_vertices to an unsigned value.Xiang, Haihao2008-05-051-1/+3
| | | | Negative value means other errors, not aperture overflow. fix bug #15752
* i965: initial attempt at fixing the aperture overflowDave Airlie2008-04-181-12/+47
| | | | | | | | | Makes state emission into a 2 phase, prepare sets things up and accounts the size of all referenced buffer objects. The emit stage then actually does the batchbuffer touching for emitting the objects. There is an assert in dri_emit_reloc if a reloc occurs for a buffer that hasn't been accounted yet.
* Revert "[i965] make stipple pattern continue across GL_LINE_LOOP and ↵Zou Nan hai2008-03-181-1/+1
| | | | | | | GL_LINE_STRIP" There is no information in GS to determinate when to reset line stipple count, still fallback to software This reverts commit 5a0314b431ab147c6156c3011f4cb54161ba4b25.
* [i965] make stipple pattern continue across GL_LINE_LOOP and GL_LINE_STRIPZou Nan hai2008-03-181-1/+1
|
* [965] Convert brw_draw_upload to managing dri_bos, not gl_buffer_objects.Eric Anholt2008-02-041-47/+5
| | | | | This helps us avoid a bunch of mess with gl_client_arrays that we filled with unused data and confused readers.
* i965: fix an assert fail in brw_new_batchZou Nan hai2008-01-151-2/+4
|
* [965] Force a new vertex upload buffer at new batch time.Eric Anholt2008-01-141-1/+1
| | | | | Otherwise, we could choose to upload into the temporary VBO that we just fired off to the hardware. Good for a 60% OA performance improvement.
* [intel] Add more cliprect modes to cover other meanings for batch emits.Eric Anholt2008-01-101-1/+3
| | | | | | | | | | | | | | | The previous change gave us only two modes, one which looped over the batch per cliprect (3d drawing) and one that didn't (state updeast). However, we really want 4: - Batch doesn't care about cliprects (state updates) - Batch needs DRAWING_RECTANGLE looping per cliprect (3d drawing) - Batch needs to be executed just once (region fills, copies, etc.) - Batch already includes cliprect handling, and must be flushed by unlock time (copybuffers, clears). All callers should now be fixed to use one of these states for any batchbuffer emits. Thanks to Keith Whitwell for pointing out the failure.
* [965] Allow more than one draw_prims per batchbuffer.Eric Anholt2008-01-091-7/+13
| | | | | | | | The comment about (vbo)_exec_api.c appeared to be stale, as the VBO code seems to only use non-named VBOs (not actual VBOs) or freshly-allocated VBO data. This brings a 2x speedup to openarena, because we can submit nearly-full batchbuffers instead of many 450-byte ones.
* [intel] Clean up cliprect handling in intel drivers.Eric Anholt2008-01-091-47/+5
| | | | | | | | | In particular, batch buffers are no longer flushed when switching from CLIPRECTS to NO_CLIPRECTS or vice versa, and 965 just uses DRM cliprect handling for primitives instead of trying to sneak in its own to avoid the DRM stuff. The disadvantage is that we will re-execute state updates per cliprect, but the advantage is that we will be able to accumulate larger batch buffers, which were proving to be a major overhead.
* [intel] Remove the dead intel->need_flush member.Eric Anholt2008-01-091-2/+1
|
* [intel] Merge intel_buffer_objects to shared.Eric Anholt2007-12-151-1/+3
| | | | | 965 gains fixed TTM typing of the buffer object buffers and unused PBO functions, and 915 gains buffer size == 0 fixes from 965.
* [intel] Move bufmgr back to context instead of screen, fixing glthreads.Eric Anholt2007-12-121-1/+1
| | | | | | | | Putting the bufmgr in the screen is not thread-safe since the emit_reloc changes. It also led to a significant performance hit from pthread usage for the attempted thread-safety (up to 12% of a cpu spent on refcounting protection in single-threaded 965). The motivation had been to allow multi-context bufmgr sharing in classic mode, but it wasn't worth the cost.
* [965] Convert the driver to dri_bufmgr interface and enable TTM.Eric Anholt2007-12-071-45/+19
| | | | | | | | | | | | | This is currently believed to work but be a significant performance loss. Performance recovery should be soon to follow. The dri_bo_fake_disable_backing_store() call was added to allow backing store disable like bufmgr_fake.c did, which is a significant performance win (though it's missing the no-fence-subdata part). This commit is a squash merge of the 965-ttm branch, which had some history I wanted to avoid pulling due to noisiness and brokenness at many points for git-bisecting.
* [965] Convert DBG macro to use FILE_DEBUG_FLAG like i915.Eric Anholt2007-11-191-1/+1
|
* [965] Remove AUB file support.Eric Anholt2007-09-271-6/+0
| | | | | This code existed to dump logs of hardware access to be replayed in simulation. Since we have real hardware now, it's not really needed.
* i965: flush batch buffer when getting the maximum. This makesXiang, Haihao2007-08-281-0/+6
| | | | some 3D programs such as pymol work well.
* include swrast_setup/swrast_setup.h to silence warningBrian2007-05-221-0/+1
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-30 07:45:31 +0000