summaryrefslogtreecommitdiff
path: root/src/mesa/drivers/dri/i965/brw_context.h
AgeCommit message (Collapse)Author
2009-11-17Merge branch 'outputswritten64'Ian Romanick
Add a GLbitfield64 type and several macros to operate on 64-bit fields. The OutputsWritten field of gl_program is changed to use that type. This results in a fair amount of fallout in drivers that use programs. No changes are strictly necessary at this point as all bits used are below the 32-bit boundary. Fairly soon several bits will be added for clip distances written by a vertex shader. This will cause several bits used for varyings to be pushed above the 32-bit boundary. This will affect any drivers that support GLSL. At this point, only the i965 driver has been modified to support this eventuality. I did this as a "squash" merge. There were several places through the outputswritten64 branch where things were broken. I foresee this causing difficulties later for bisecting. The history is still available in the branch. Conflicts: src/mesa/drivers/dri/i965/brw_wm.h
2009-11-13i965: Remove an unused cache_item field.Eric Anholt
2009-11-13i965: Remove long dead structures for ffvertex_prog.c.Eric Anholt
2009-11-06i965: Always pass the size argument to brw_cache_data.Eric Anholt
This keeps the individual state files from having to export their structures for brw_state_cache initialization.
2009-10-29i965: define, use BRW_MAX_DRAW_BUFFERSBrian Paul
i965 might support more than 4 color draw buffers. But if not, this protects from breakage if the Mesa limit is raised.
2009-10-27Revert "i965: fix hacked Fallback usage in brw_prepare_vertices()"Brian Paul
This reverts commit 8810b8f67135185d1044746bb861fe2ff997626c. It turns out the i965 driver uses the intel->Fallback field as a boolean, not as a bitmask. The intelFallback() function is a no-op in the i965 driver. It would have been nice if there were some comments about this. I'll fix that next...
2009-10-22Merge branch 'mesa_7_6_branch'Brian Paul
2009-10-22i965: fix hacked Fallback usage in brw_prepare_vertices()Brian Paul
Setting intel->Fallback = 1 clobbered any fallback state that was already set. Not sure where this hack originated (the git history is a little convoluted). Define and use a new BRW_FALLBACK_DRAW bit instead. This shouldn't break anything and could potentially fix some bugs (but no specific ones are known).
2009-10-22i965: remove unused brw_context::tmp_fallback fieldBrian Paul
2009-10-22i965: remove unused BRW_FALLBACK_TEXTURE bitBrian Paul
The value was probably wrong too. It was the same as INTEL_FALLBACK_DRAW_BUFFER.
2009-09-28intel: Remove some dead metaops code.Eric Anholt
2009-09-09Merge branch 'mesa_7_5_branch' into mesa_7_6_branchBrian Paul
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
2009-09-08i965: fix incorrect test for vertex position attributeBrian Paul
2009-09-04i965: Calculate enabled[] and nr_enabled once and re-use the values.Eric Anholt
The code duplication bothered me. (cherry picked from commit 9b9cb30d128fc5f1ba77287696ecd508e640efde)
2009-08-26i965: keep track of which texture units the fragment shader accessesBrian Paul
We'll use this for debug/sanity checking.
2009-08-12i965: Avoid re-uploading the index buffer when we don't need to.Eric Anholt
No performance difference proven at 95% confidence with my GLSL demo (n=10).
2009-08-07i965: minor context commentsBrian Paul
2009-08-04i965: Hook up the disassembler for INTEL_DEBUG={wm,vs}.Eric Anholt
I was getting tired of doing the dance of INTEL_DEBUG=batch, copying it out, and running intel-gen4disasm on it.
2009-08-03i965: Calculate enabled[] and nr_enabled once and re-use the values.Eric Anholt
The code duplication bothered me.
2009-07-07i965: Remove BRW_NEW_INPUT_VARYINGEric Anholt
This state flag has been unused since the ffvertex_prog move to core.
2009-06-30i965: move BRW_MAX_GRF, define BRW_MAX_MRFBrian Paul
2009-06-30i965: defined BRW_MAX_MRFBrian Paul
2009-06-16i965: fix bugs in projective texture coordinatesBrian Paul
For the TXP instruction we check if the texcoord is really a 4-component atttibute which requires the divide by W step. This check involved the projtex_mask field. However, the projtex_mask field was being miscalculated because of some confusion between vertex program outputs and fragment program inputs. 1. Rework the size_masks calculation so we correctly set bits corresponding to fragment program input attributes. 2. Rename projtex_mask to proj_attrib_mask since we're interested in more than just texcoords (generic varying vars too). 3. Simply the indexing of the size_masks and proj_attrib_mask fields. 4. The tracker::active[] array was mis-dimensioned. Use MAX_PROGRAM_TEMPS instead of a magic number. 5. Update comments, add new assertions. With these changes the Lightsmark demo/benchmark renders correctly, until we eventually hit a GPU lockup...
2009-06-16Merge branch 'mesa_7_5_branch'Brian Paul
Conflicts: src/mesa/main/api_validate.c
2009-05-06i965: Split WM constant buffer update from other WM surfaces.Eric Anholt
This can avoid re-uploading constant data when it isn't necessary, and is a step towards not updating other surfaces just because constants change. It also brings the upload of the constant buffer next to the creation. This brings openarena performance up another 4%, to 91% of the Mesa 7.4 branch.
2009-04-27i965: only upload constant buffer data when we actually need the const bufferBrian Paul
Make the use_const_buffer field per-program and only call the code which updates the constant buffer's data if the flag is set. This should undo the perf regression from 20f3497e4b6756e330f7b3f54e8acaa1d6c92052 (cherry picked from master, commit dc9705d12d162ba6d087eb762e315de9f97bc456)
2009-04-27i965: only upload constant buffer data when we actually need the const bufferBrian Paul
Make the use_const_buffer field per-program and only call the code which updates the constant buffer's data if the flag is set. This should undo the perf regression from 20f3497e4b6756e330f7b3f54e8acaa1d6c92052
2009-04-22i965: define BRW_MAX_GRFBrian Paul
2009-04-22i965: checkpoint commit: use two state caches instead of oneBrian Paul
The new, second cache will only be used for surface-related items. Since we can create many surfaces the original, single cache could get filled quickly. When we cleared it, we had to regenerate shaders, etc. With two caches, we can avoid doing that.
2009-04-22i965: the brw_constant_buffer state atom is no longer dynamicBrian Paul
No more dynamic atoms so we can simplify the state validation code a little.
2009-04-17i965: updated CURBE allocation codeBrian Paul
Now that we have real constant buffers, the demands on the CURBE are lessened. When we use real VS/WM constant buffers we only use the CURBE for clip planes.
2009-04-14i965: checkpoint commit: VS constant buffersBrian Paul
Hook up a constant buffer, binding table, etc for the VS unit. This will allow using large constant buffers with vertex shaders. The new code is disabled at this time (use_const_buffer=FALSE).
2009-04-09i965: re-org of some of the new constant buffer codeBrian Paul
Plus, begin the new code for vertex shader const buffers.
2009-04-09i965: new SURF_INDEX_ macrosBrian Paul
Used to map drawables, textures and constant buffers to surface binding table indexes.
2009-04-03i965: check-point commit of new constant buffer supportBrian Paul
Currently, shader constants are stored in the GRF (loaded from the CURBE prior to shader execution). This severly limits the number of constants and temps that we can support. This new code will support (practically) unlimited size constant buffers and free up registers in the GRF. We allocate a new buffer object for the constants and read them with "Read" messages/instructions. When only a small number of constants are used, we can still use the old method. The code works for fragment shaders only (and is actually disabled) for now. Need to do the same thing for vertex shaders and need to add the necessary code-gen to fetch the constants which are referenced by the shader instructions.
2009-04-03i965: rename scratch_buffer -> scratch_bo to be consistant with other buffersBrian Paul
2009-03-10i965: added cast wrappers, commentsBrian Paul
2009-03-10i965: fix typos in commentsBrian Paul
2009-03-06i965: avoid unnecessary calls to brw_wm_is_glsl()Brian Paul
This function scans the shader to see if it has any GLSL features like conditionals and loops. Calling this during state validation is expensive. Just call it when the shader is given to the driver and save the result. There's some new/temporary assertions to be sure we don't get out of sync on this.
2009-03-05i965: Remove dead flushing code.Eric Anholt
2009-02-26i965: rename draw_regions -> color_regionsroot
Be a little more specific about what these are.
2009-02-25i965: Rename CMD_CONST_BUFFER_STATE to the CS_URB_STATE used in the docs.Eric Anholt
2009-02-20i965: added commentBrian Paul
2009-02-02i965: Remove brw->attribs now that we can just always look in the GLcontext.Eric Anholt
2009-02-02i965: Delete old metaops code now that there are no remaining consumers.Eric Anholt
2009-01-01i965: increase number of texture samplers to 16Brian Paul
This lets GLSL shaders use up to 16 samplers. Fixed function is still limited to 8 textures. Tested with progs/glsl/samplers.c
2008-12-03i965: Fix failure to upload new constant data when changing programs.Eric Anholt
This is fallout from the ffvertex_prog.c work. It doesn't call ProgramStringNotify, so we don't set param_state, so we wouldn't track when VP parameters changed, and constants wouldn't get uploaded. Instead, remove param_state entirely and just use the real value that we want to be tracking. Fixes rendering in openarena since BRW_NEW_BATCH got disentangled from BRW_NEW_INDICES. Bug #18822.
2008-11-28i965: Add a new state flag BRW_NEW_NR_SURFACES instead of CACHE_NEW_SURFACEEric Anholt
The CACHE_NEW_SURFACE bit always gets spammed since we get many different surface BOs per state emit, but the only consumer of it wanted to just know how many surfaces were enabled.
2008-11-28i965: Fix clashing enums for BRW_NEW_INDICES/VERTICES versus BATCH/DEPTH_BUFFER.Eric Anholt
Fixes upload of large amounts of state for every new primitive emit.
2008-11-28i965: Remove BRW_WM_LOCK dirty bit, introduced to work around lack of relocs.Eric Anholt
This was causing a prepare of wm state at every primitive emit.