aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/brw_curbe.c
Commit message (Collapse)AuthorAgeFilesLines
* i965: Drop trailing whitespace from the rest of the driver.Kenneth Graunke2013-12-051-9/+9
| | | | | | | Performed via: $ for file in *; do sed -i 's/ *//g'; done Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Delete intel_context entirely.Kenneth Graunke2013-07-091-3/+2
| | | | | | | | | | This makes brw_context inherit directly from gl_context; that was the only thing left in intel_context. Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chris Forbes <[email protected]> Acked-by: Paul Berry <[email protected]> Acked-by: Anuj Phogat <[email protected]>
* i965: Move intel_context::bufmgr to brw_context.Kenneth Graunke2013-07-091-1/+1
| | | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chris Forbes <[email protected]> Acked-by: Paul Berry <[email protected]> Acked-by: Anuj Phogat <[email protected]>
* i965: Pass brw_context to functions rather than intel_context.Kenneth Graunke2013-07-091-2/+0
| | | | | | | | | | | | | | This makes brw_context available in every function that used intel_context. This makes it possible to start migrating fields from intel_context to brw_context. Surprisingly, this actually removes some code, as functions that use OUT_BATCH don't need to declare "intel"; they just use "brw." Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chris Forbes <[email protected]> Acked-by: Paul Berry <[email protected]> Acked-by: Anuj Phogat <[email protected]>
* i965/vs: split brw_vs_prog_data into generic and VS-specific parts.Paul Berry2013-04-111-3/+3
| | | | | | | | | | | This will allow the generic parts to be re-used for geometry shaders. Reviewed-by: Jordan Justen <[email protected]> v2: Put urb_read_length and urb_entry_size in the generic struct. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Remove some stale comments about the brw_constant_buffer atom.Eric Anholt2013-02-111-6/+0
| | | | | | | These have been wrong since f428255bde93a452a7cdd48fba21839c99beb6cb back in 2009! Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Update comment about clipper constants.Kenneth Graunke2012-11-011-9/+1
| | | | | | | The old VS backend doesn't exist, but I believe these still need to be delivered to the clipper thread. Reviewed-by: Eric Anholt <[email protected]>
* i965/vs: Remove support for the old parameter layout.Kenneth Graunke2012-11-011-19/+2
| | | | | | Only the old backend used it. Reviewed-by: Eric Anholt <[email protected]>
* i965: Remove unused param conversion code.Eric Anholt2012-07-251-2/+1
| | | | | | | | Ever since ctx->NativeIntegers was set, the conversion flag has been PARAM_NO_CONVERT. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen4: Move CURBE offset calculation to emit() time.Eric Anholt2011-10-291-1/+1
| | | | | | | This is consumed by the unit state. Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Paul Berry <[email protected]>
* i965/gen4: Fold push constant prepare()/emit() together.Eric Anholt2011-10-291-13/+9
| | | | | | | | While other units need to know about our constant buffer offsets, nothing else cared about which particular BO other than the emit() half. Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Paul Berry <[email protected]>
* i965: Remove the validated BO list, now that it's unused.Eric Anholt2011-10-291-2/+0
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Paul Berry <[email protected]>
* mesa: Create _mesa_bitcount_64() to replace i965's brw_count_bits()Paul Berry2011-10-061-1/+1
| | | | | | | | | | | | | | | | The i965 driver already had a function to count bits in a 64-bit uint (brw_count_bits()), but it was buggy (it only counted the bottom 32 bits) and it was clumsy (it had a strange and broken fallback for non-GCC-like compilers, which fortunately was never used). Since Mesa already has a _mesa_bitcount() function, it seems better to just create a _mesa_bitcount_64() function rather than special-case this in the i965 driver. This patch creates the new _mesa_bitcount_64() function and rewrites all of the old brw_count_bits() calls to refer to it. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965 Gen6: Implement gl_ClipVertex.Paul Berry2011-10-051-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements proper support for gl_ClipVertex by causing the new VS backend to populate the clip distance VUE slots using VERT_RESULT_CLIP_VERTEX when appropriate, and by using the untransformed clip planes in ctx->Transform.EyeUserPlane rather than the transformed clip planes in ctx->Transform._ClipUserPlane when a GLSL-based vertex shader is in use. When not using a GLSL-based vertex shader, we use ctx->Transform._ClipUserPlane (which is what we used prior to this patch). This ensures that clipping is still performed correctly for fixed function and ARB vertex programs. A new function, brw_select_clip_planes() is used to determine whether to use _ClipUserPlane or EyeUserPlane, so that the logic for making this decision is shared between the new and old vertex shaders. Fixes the following Piglit tests on i965 Gen6: - vs-clip-vertex-const-accept - vs-clip-vertex-const-reject - vs-clip-vertex-different-from-position - vs-clip-vertex-equal-to-position - vs-clip-vertex-homogeneity - vs-clip-based-on-position - vs-clip-based-on-position-homogeneity - clip-plane-transformation clipvert_pos - clip-plane-transformation pos_clipvert - clip-plane-transformation pos Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965 new VS: don't share clip plane constants in pre-GEN6Paul Berry2011-09-281-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | In pre-GEN6, when using clip planes, both the vertex shader and the clipper need access to the client-supplied clip planes, since the vertex shader needs them to set the clip flags, and the clipper needs them to determine where to insert new vertices. With the old VS backend, we used a clever optimization to avoid placing duplicate copies of these planes in the CURBE: we used the same block of memory for both the clipper and vertex shader constants, with the clip planes at the front of it, and then we instructed the clipper to read just the initial part of this block containing the clip planes. This optimization was tricky, of dubious value, and not completely working in the new VS backend, so I've removed it. Now, when using the new VS backend, separate parts of the CURBE are used for the clipper and the vertex shader. Note that this doesn't affect the number of push constants available to the vertex shader, it simply causes the CURBE to occupy a few more bytes of URB memory. The old VS backend is unaffected. GEN6+, which does clipping entirely in hardware, is also unaffected. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Remove bogus assertion on MAX_CLIP_PLANES.Paul Berry2011-09-201-1/+0
| | | | | | | | | This patch removes the assertion "MAX_CLIP_PLANES == 6" from the i965 driver. This assertion is unnecessary; nothing in the driver requires MAX_CLIP_PLANES to be 6. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Use native integer uniforms when the new VS backend is in use.Eric Anholt2011-08-301-2/+1
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vs: Start adding support for uniformsEric Anholt2011-08-161-10/+17
| | | | There's no clever packing here, no pull constants, and no array support.
* i965: Move repeat-instruction-suppression to batchbuffer coreChris Wilson2011-02-211-9/+11
| | | | | | | | Move the tracking of the last emitted instructions into the core batchbuffer routines and take advantage of the shadow batch copy to avoid extra memory allocations and copies. Signed-off-by: Chris Wilson <[email protected]>
* i965: Drop push-mode reladdr constant loading and always use constant_map.Eric Anholt2010-12-081-15/+7
| | | | | | | | This eases the gen6 implementation, which can only handle up to 32 registers of constants, while likely not penalizing real apps using reladdr since all of those I've seen also end up hitting the pull constant buffer. On gen6, the constant map means that simple NV VPs fit under the 32-reg limit and now succeed. Fixes around 10 testcases.
* i965: Make FS uniforms be the actual type of the uniform at upload time.Eric Anholt2010-10-271-2/+4
| | | | | | | | This fixes some insanity that would otherwise be required for GLSL 1.30 bit ops or gen6 integer uniform operations in general, at the cost of upload-time pain. Given that we only have that pain because mesa's mangling our integer uniforms to be floats, this something that should be fixed outside of the shader codegen.
* Drop GLcontext typedef and use struct gl_context insteadKristian Høgsberg2010-10-131-2/+2
|
* Merge branch 'shader-file-reorg'Brian Paul2010-06-231-3/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Move all GL entrypoint functions and files into src/mesa/main/ This includes the ARB vp/vp, NV vp/fp, ATI fragshader and GLSL bits that were in src/mesa/shader/ 2. Move src/mesa/shader/slang/ to src/mesa/slang/ to reduce the tree depth 3. Rename src/mesa/shader/ to src/mesa/program/ since all the remaining files are concerned with GPU programs. 4. Misc code refactoring. In particular, I got rid of most of the GLSL-related ctx->Driver hook functions. None of the drivers used them. Conflicts: src/mesa/drivers/dri/i965/brw_context.c
| * mesa: rename src/mesa/shader/ to src/mesa/program/Brian Paul2010-06-101-3/+3
| |
* | i965: Warning fixes from the i965-streaming merge.Eric Anholt2010-06-111-2/+0
| |
* | i965: Split constant buffer setup from its surface state/binding state.Eric Anholt2010-06-111-10/+0
|/ | | | This was bothering me when redoing the binding tables.
* i965: Avoid calloc/free in the CURBE upload process.Eric Anholt2010-06-091-15/+9
| | | | | | | In exchange we end up with an extra memcpy, but that seems better than calloc/free. Each buffer is 4k maximum, and on the i965-streaming branch this allocation was showing up as the top entry in brw_validate_state profiling for cairo-gl.
* intel: Change dri_bo_* to drm_intel_bo* to consistently use new API.Eric Anholt2010-06-081-3/+3
| | | | | The slightly less mechanical change of converting the emit_reloc calls will follow.
* intel: Remove non-kernel-exec-fencing support.Eric Anholt2010-03-041-3/+2
| | | | | | | Shaves 60k off the driver from removing the broken spans code. This means we now require 2.6.29, which seems fair given that it's a year old and we've removed support for non-KMS already in the last release of 2D.
* Replace the _mesa_*printf() wrappers with the plain libc versionsKristian Høgsberg2010-02-191-13/+13
|
* Replace _mesa_malloc, _mesa_calloc and _mesa_free with plain libc versionsKristian Høgsberg2010-02-191-3/+3
|
* i965: Keep the CURBE BO mapped and memcpy instead of subdataing.Eric Anholt2010-02-061-4/+7
| | | | | | For the tiny bis of data we generally upload through the CURBEs, the overhead of the kernel's pagetable trickery is actually rather high. This improves cairo-gl gnome-terminal-vim performance by 3.8%.
* i965: Reset the "need new CURBE BO" flag when we make a new CURBE bo.Eric Anholt2010-02-061-0/+1
| | | | Improves cairo-gl gnome-terminal-vim times by 11%.
* i965: Upload as many VS constants as possible through the push constants.Eric Anholt2010-01-191-7/+18
| | | | | | | The pull constants require sending out to an overworked shared unit and waiting for a response, while push constants are nicely loaded in for us at thread dispatch time. By putting things we access in every VS invocation there, ETQW performance improved by 2.5% +/- 1.6% (n=6).
* intel: Drop batchbuffer cliprect_mode trackingKristian Høgsberg2010-01-041-1/+1
|
* i965: Flag BRW_NEW_CONTEXT on some context state.Eric Anholt2009-11-131-1/+1
| | | | | | Fixing this is a prereq for avoiding flagging all state at new batch time. Eliminating that still causes problems, though (notably glean logicOp fails on my GM965).
* i965: Load NV program matrices when required.Eric Anholt2009-09-241-0/+3
|
* i965: Support PROGRAM_ENV_PARAMs in brw_vs_emit.cEric Anholt2009-08-291-0/+3
|
* i965: Split WM constant buffer update from other WM surfaces.Eric Anholt2009-05-061-52/+0
| | | | | | | | 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.
* i965: Disentangle VS constant surface state from WM surface state.Eric Anholt2009-05-061-15/+0
| | | | | Also, only create VS surface state if there's a VS constant buffer to be uploaded, and set the contents of the buffer at the same time as creation.
* Merge branch 'const-buffer-changes'Brian Paul2009-05-011-14/+8
|\ | | | | | | | | | | | | | | Conflicts: src/mesa/drivers/dri/i965/brw_curbe.c src/mesa/drivers/dri/i965/brw_vs_emit.c src/mesa/drivers/dri/i965/brw_wm_glsl.c
| * i965: #include prog_print.h to silence warningBrian Paul2009-04-271-0/+1
| |
| * i965: only upload constant buffer data when we actually need the const bufferBrian Paul2009-04-271-2/+4
| | | | | | | | | | | | | | | | | | 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)
| * i965: updates to some debug codeBrian Paul2009-04-221-6/+6
| |
| * i965: use new _NEW_PROGRAM_CONSTANTS flag instead of dynamic flagsBrian Paul2009-04-221-8/+1
| |
* | i965: only upload constant buffer data when we actually need the const bufferBrian Paul2009-04-271-2/+4
| | | | | | | | | | | | | | 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
* | i965: use drm_intel_gem_bo_map/unmap_gtt() when possible, otherwise ↵Brian Paul2009-04-241-5/+9
| | | | | | | | | | | | dri_bo_subdata() This wraps up the unfinished business from commit a9a363f8298e9d534e60e3d2869f8677138a1e7e
* | i965: revert part of commit 4f4907d69f9020ce17aef21b6431d2dd65e01982Brian Paul2009-04-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | The drm_intel_gem_bo_map_gtt() call that replaced dri_bo_map() is producing errors like: intel_bufmgr_gem.c:689: Error preparing buffer map 39 (vp_const_buffer): Invalid argument . and returning NULL, causing a segfault in the memcpy(). Just reverting until we can get to the root issue...
* | intel: Take advantage of GL_READ_ONLY_ARB to map to GEM bo_map write flag.Eric Anholt2009-04-231-2/+2
|/ | | | | This is a CPU win in general, but in particular reduces the pain of Mesa's calculation of min/max indices in DrawElements (wtf?).
* i965: updated CURBE allocation codeBrian Paul2009-04-171-5/+9
| | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-11 15:44:12 +0000