summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
* i965/gs: Add a state atom to set up geometry shader state.Paul Berry2013-09-116-33/+156
| | | | | | | | | | | | v2: Do not attempt to share the code that uploads 3DSTATE_BINDING_TABLE_POINTERS_GS, 3DSTATE_SAMPLER_STATE_POINTERS_GS, or 3DSTATE_GS with VS. Reviewed-by: Ian Romanick <[email protected]> v3: Add _NEW_TRANSFORM to gen7_gs_state. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen7: Extract a function for setting up a shader stage's constants.Paul Berry2013-09-112-25/+42
| | | | | | | | This will allow us to reuse some code when setting up the geometry shader stage. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add an assertion that writemask != NULL for non-ARFs.Kenneth Graunke2013-09-101-0/+2
| | | | | | | | | | | | | | | | We've observed GPU hangs on Ivybridge from the following instruction: mov(8) g115<1>.F 0D { align16 WE_normal NoDDChk 1Q }; There should be no reason to ever set the writemask on a destination register to zero, except for perhaps the ARF NULL register. This patch adds an assertion to enforce this for non-ARF registers. Excluding ARFs is conservative yet should still catch the majority of mistakes. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965/vec4: Only zero out unused message components when there are any.Kenneth Graunke2013-09-101-2/+4
| | | | | | | | | | | | | | | | Otherwise, coordinates with four components would result in a MOV with a destination writemask that has no channels enabled: mov(8) g115<1>.F 0D { align16 WE_normal NoDDChk 1Q }; At best, this is stupid: we emit code that shouldn't do anything. Worse, it apparently causes GPU hangs (observable with Chris's textureGather test on CubeArrays.) Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Cc: [email protected]
* i965/vec4: Simplify the computation of coord_mask and zero_mask.Kenneth Graunke2013-09-101-5/+2
| | | | | | | | | We can easily compute these without loops, resulting in simpler and shorter code. Signed-off-by: Kenneth Graunke <[email protected]> Suggested-by: Ian Romanick <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* Revert "i965/vec4: Only zero out unused message components when there are any."Kenneth Graunke2013-09-091-4/+2
| | | | | | This reverts commit 6c3db2167c64ecf2366862f15f8e2d4a91f1028c, which I accidentally pushed along with other code. A better version of the fix will be committed later.
* i965: Allow immediates to be folded into logical and shift instructions.Matt Turner2013-09-092-0/+22
| | | | | | | | These instructions will be used with immediate arguments in the upcoming ldexp lowering pass and frexp implementation. v2: Add vec4 support as well. Reviewed-by: Paul Berry <[email protected]>
* i965: Enable MESA_shader_integer_mix.Matt Turner2013-09-091-0/+1
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Add support for ir_triop_csel.Matt Turner2013-09-093-0/+13
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Pass _mesa_glsl_parse_state into matching_signature and such.Kenneth Graunke2013-09-092-2/+2
| | | | | | | | | | | | | | | | | | | | | | | During compilation, we'll use this to determine built-in availability. The plan is to have a single shader containing every built-in in every version of the language, but filter out the ones that aren't actually available to the shader being compiled. At link time, we don't actually need this filtering capability: we've already imported prototypes for every built-in that the shader actually calls, and they're flagged as is_builtin(). The linker doesn't import any additional prototypes, so it won't pull in any unavailable built-ins. When resolving prototypes to function definitions, the linker ensures the values of is_builtin() match, which means that a shader can't trick the linker into importing the body of an unavailable built-in by defining a suspiciously similar prototype. In other words, during linking, we can just pass in NULL. It will work out fine. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/vec4: Only zero out unused message components when there are any.Kenneth Graunke2013-09-091-2/+4
| | | | | | | | | | | | | | | Otherwise, coordinates with four components would result in a MOV with a destination writemask that has no channels enabled: mov(8) g115<1>.F 0D { align16 WE_normal NoDDChk 1Q }; At best, this is stupid: we emit code that shouldn't do anything. Worse, it apparently causes GPU hangs (observable with Chris's textureGather test on CubeArrays.) Signed-off-by: Kenneth Graunke <[email protected]> Cc: Chris Forbes <[email protected]> Cc: [email protected]
* i965: Enable AMD_seamless_cubemap_per_textureIan Romanick2013-09-083-2/+3
| | | | | | | | | | | | | | | | The change is very small. Do seamless filtering if either the context enable is set or the sampler enable is set. The AMD_seamless_cubemap_per_texture says: "If TEXTURE_CUBE_MAP_SEAMLESS_ARB is emabled (sic) globally or the value of the texture's TEXTURE_CUBE_MAP_SEAMLESS_ARB parameter is TRUE, seamless cube map sampling is enabled..." Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* gallium, intel: Implements new __DRI_IMAGE_USE_LINEAR and PIPE_BIND_LINEAR ↵Axel Davy2013-09-062-0/+6
| | | | | | flags to enforce no tiling. Signed-off-by: Axel Davy <[email protected]>
* i965: Remove never used DPA2 opcode.Matt Turner2013-09-051-1/+0
| | | | | | | | | | | DPA2 is listed in the "Defeatured Instructions" section of the 965 PRM, Volume 4: "The following instructions are removed from Gen4 implementation mainly due to implementation cost/schedule reasons. They are candidates for future generations." Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Remove never used RSR and RSL opcodes.Matt Turner2013-09-054-8/+0
| | | | | | | | | | | RSR and RSL are listed in the "Defeatured Instructions" section of the 965 PRM, Volume 4: "The following instructions are removed from Gen4 implementation mainly due to implementation cost/schedule reasons. They are candidates for future generations." Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen7.5: Fix lower bound on number of VS URB entries.Paul Berry2013-09-054-4/+13
| | | | | | | | | | | | Haswell GT2 and GT3 require the number of vertex shader URB entries to be at least 64, not 32. At the moment, we always meet this requirement automatically, because in the absence of a geometry shader, we assign all available URB space to the vertex shader. But when we turn on support for geometry shaders, this lower limit will become important. Reviewed-by: Chad Versace <[email protected]>
* i965/vs: Move vs-specific code out of brw_vec4_visitor.cpp.Paul Berry2013-09-053-192/+226
| | | | | | | | | | | This patch creates a new file brw_vec4_vs_visitor.cpp, to contain code that is specific to the vertex shader. Now the organization of vertex shader and geometry shader visitor code is symmetric: vs-specific code is in brw_vec4_vs_visitor.cpp, gs-specific code is in brw_vec4_gs_visitor.cpp, and code shared between vs and gs is in brw_vec4_visitor.cpp. Acked-by: Kenneth Graunke <[email protected]>
* i965/vec4: Make with_writemask() non-static.Paul Berry2013-09-052-1/+4
| | | | | | | This will allow it to be shared between brw_vec4_visitor.cpp and brw_vec4_vs_visitor.cpp (which will be created in the next patch). Acked-by: Kenneth Graunke <[email protected]>
* i965/vs: Move vs-specific code out of brw_vec4.h.Paul Berry2013-09-052-32/+38
| | | | | | | Now brw_vec4.h contains only code that is shared between the vertex and geometry shaders. Acked-by: Kenneth Graunke <[email protected]>
* i965/gs: Don't assign gl_Layer its own slot in the VUE map.Paul Berry2013-09-051-0/+5
| | | | Reviewed-by: Chad Versace <[email protected]>
* mesa: Implement GL_DEBUG_OUTPUTTimothy Arceri2013-09-041-0/+2
| | | | | | Signed-off-by: Timothy Arceri <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965: Rename "prim" parameter to "prims" where it's an array.Kenneth Graunke2013-09-033-18/+18
| | | | | | | | | | | | | Some drawing functions take a single _mesa_prim object, while others take an array of primitives. Both kinds of functions used a parameter called "prim" (the singular form), which was confusing. Using the plural form, "prims," clearly communicates that the parameter is an array of primitives. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Actually check every primitive for cut index support.Kenneth Graunke2013-09-031-2/+2
| | | | | | | | | | | | can_cut_index_handle_prims() was passed an array of _mesa_prim objects and a count, and ran a loop for that many iterations. However, it treated the array like a pointer, repeatedly checking the first element. This patch makes it actually check every primitive. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Use the proper element of the prim array in brw_try_draw_prims.Kenneth Graunke2013-09-011-4/+4
| | | | | | | | | | | | | | | | | | The VBO module actually calls us with an array of _mesa_prim objects. For example, it may break up a DrawArrays() call into multiple primitives when primitive restart is enabled. Previously, we treated prim like a pointer, always accessing element 0. This worked because all of the primitive objects in a single draw call have the same value for num_instances and basevertex. However, accessing an array as a pointer and using the wrong object's fields is misleading. For stylistic reasons alone, we should use the right object. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Combine brw_emit_prim and gen7_emit_prim.Kenneth Graunke2013-09-011-63/+18
| | | | | | | | | | | | | | These functions have almost identical code; the only difference is that a few of the bits moved around. Adding a few trivial conditionals allows the same function to work on all generations, and the resulting code is still quite readable. v2: Comment that the workaround flush is only necessary on SNB (requested by Paul Berry). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Remove unused ATTRIB_BIT_DWORDS define.Kenneth Graunke2013-09-011-7/+0
| | | | | Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Gen4: Zero out extra coordinates when using shadow compareChris Forbes2013-09-011-1/+7
| | | | | | | | Fixes broken rendering if these MRFs contained anything other than zero. NOTE: This is a candidate for stable branches. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gs: Implement support for geometry shader samplers.Paul Berry2013-08-313-0/+30
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gs: add geometry shader support to brw_texture_surfaces.Paul Berry2013-08-311-0/+7
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gs: generalize brw_texture_surfaces in preparation for gs.Paul Berry2013-08-311-31/+33
| | | | | | | | | | | There is a slight functionality change. Previously we would compute a common value for num_samplers for all stages, and populate that many entries in each stage's surf_offset table regardless of how many samplers each stage used. Now we only populate the number of entries in the surf_offset table corresponding to the number of samplers actually used by the stage. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Modify signature to update_texture_surface functions.Paul Berry2013-08-313-22/+17
| | | | | | | | | | | | Previously these functions would accept a pointer to the binding table and an index indicating which entry in the binding table should be updated. Now they merely take a pointer to the binding table entry to be updated. This will make it easier to generalize brw_texture_surfaces to support geometry shaders. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vs: generalize gen6_vs_push_constants in preparation for GS.Paul Berry2013-08-312-16/+36
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gs: make the state atom for compiling Gen7 geometry shaders.Paul Berry2013-08-3112-6/+401
| | | | | | Reviewed-by: Kenneth Graunke <[email protected]> v2: Use "unsigned" rather than "GLuint".
* i965/gs: Implement support for geometry shader surfaces.Paul Berry2013-08-315-0/+131
| | | | | | | | | | | | | | This patch implements pull constant upload, binding table upload, and surface setup for geometry shaders, by re-using vertex shader code that was generalized in previous patches. Based on work by Eric Anholt <[email protected]>. v2: Update ditry bits for brw_gs_ubo_surfaces to account for commit 77d8fbc (mesa: add & use a new driver flag for UBO updates instead of _NEW_BUFFER_OBJECT). Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vs: generalize brw_vs_binding_table in preparation for GS.Paul Berry2013-08-312-13/+35
| | | | | | | v2: Use GLbitfield instead of GLbitfield64 in brw_vec4_upload_binding_table. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: generalize brw_vs_pull_constants in preparation for GS.Paul Berry2013-08-312-26/+51
| | | | | | | v2: Use GLbitfield instead of GLbitfield64 in brw_upload_vec4_pull_constants. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Make sure constants re-sent after constant buffer reallocation.Paul Berry2013-08-317-5/+24
| | | | | | | | | | | | | | | | | | | | The hardware requires that after constant buffers for a stage are allocated using a 3DSTATE_PUSH_CONSTANT_ALLOC_{VS,HS,DS,GS,PS} command, and prior to execution of a 3DPRIMITIVE, the corresponding stage's constant buffers must be reprogrammed using a 3DSTATE_CONSTANT_{VS,HS,DS,GS,PS} command. Previously we didn't need to worry about this, because we only programmed 3DSTATE_PUSH_CONSTANT_ALLOC_{VS,HS,DS,GS,PS} once on startup (or, previous to that, whenever BRW_NEW_CONTEXT was flagged). But now that we reallocate the constant buffers whenever geometry shaders are switched on and off, we need to make sure the constant buffers are reprogrammed. We do this by adding a new bit, BRW_NEW_PUSH_CONSTANT_ALLOCATION, to brw->state.dirty.brw. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gs: Allocate push constant space for use by GS.Paul Berry2013-08-316-22/+68
| | | | | | | | | | | | | | | | | | Previously, we would always use the same push constant allocation regardless of what shader programs were being run: the available push constant space was split into 2 equal size partitions, one for the vertex shader, and one for the fragment shader. Now that we are adding geometry shader support, we need to do something smarter. This patch adjusts things so that when a geometry shader is in use, we split the available push constant space into 3 nearly-equal size partitions instead of 2. Since the push constant allocation is now affected by GL state, it can no longer be set up by brw_upload_initial_gpu_state(); instead it must be set up by a state atom. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen7: Emit CS stall after 3DSTATE_PUSH_CONSTANT_ALLOC_PS.Paul Berry2013-08-311-0/+30
| | | | | | | | | This is required by the internal hardware docs and the PRM. Probably the reason we were getting away with not doing it was because we only emitted 3DSTATE_PUSH_CONSTANT_ALLOC_PS during startup. However that's going to change with the introduction of geometry shaders. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gs: Allocate URB space for use by GS.Paul Berry2013-08-313-35/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we gave all of the URB space (other than the small amount that is used for push constants) to the vertex shader. However, when a geometry shader is active, we need to divide it up between the vertex and geometry shaders. The size of the URB entries for the vertex and geometry shaders can vary dramatically from one shader to the next. So it doesn't make sense to simply split the available space in two. In particular: - On Ivy Bridge GT1, this would not leave enough space for the worst case geometry shader, which requires 64k of URB space. - Due to hardware-imposed limits on the maximum number of URB entries, sometimes a given shader stage will only be capable of using a small amount of URB space. When this happens, it may make sense to allocate substantially less than half of the available space to that stage. Our algorithm for dividing space between the two stages is to first compute (a) the minimum amount of URB space that each stage needs in order to function properly, and (b) the amount of additional URB space that each stage "wants" (i.e. that it would be capable of making use of). If the total amount of space available is not enough to satisfy needs + wants, then each stage's "wants" amount is scaled back by the same factor in order to fit. When only a vertex shader is active, this algorithm produces equivalent results to the old algorithm (if the vertex shader stage can make use of all the available URB space, we assign all the space to it; if it can't, we let it use as much as it can). In the future, when we need to support tessellation control and tessellation evaluation pipeline stages, it should be straightforward to expand this algorithm to cover them. v2: Use "unsigned" rather than "GLuint". Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Make CACHE_NEW_GS_PROG.Paul Berry2013-08-311-0/+2
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/gs: Create brw_context::gs structure to track GS program state.Paul Berry2013-08-311-0/+5
| | | | | | | v2: Change name from "vec4_gs" to simply "gs". Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Move data from brw->vs into a base class if gs will also need it.Paul Berry2013-08-3112-85/+108
| | | | | | | | | This paves the way for sharing the code that will set up the vertex and geometry shader pipeline state. v2: Rename the base class to brw_stage_state. Reviewed-by: Chad Versace <[email protected]>
* i965/gs: Update defines related to GS surface organization.Paul Berry2013-08-318-29/+29
| | | | | | | | | | | | | | | | Defines that previously referred to VS now refer to VEC4, since they will be shared by the user-programmable vertex shader and geometry shader stages. Defines that previously referred to the Gen6 geometry shader stage (which is only used for transform feedback) are now renamed to explicitly refer to Gen6, to avoid confusion with the Gen7 user-programmable geometry shader stage. Based on work by Eric Anholt <[email protected]>. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Move vec4 register allocation data structures to brw->vec4.Paul Berry2013-08-312-29/+33
| | | | | | | | This will avoid confusion when we add geometry shaders, since these data structures will be shared by vertex and geometry shaders. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Rename user-defined gs structs from vec4_gs to gs.Paul Berry2013-08-313-9/+9
| | | | | | | | | Now that the name "gs" is no longer used to refer to the legacy fixed function geometry shaders, we can use it to refer to user-defined geometry shaders. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: rename legacy gs structs and functions to ff_gs.Paul Berry2013-08-3114-146/+156
| | | | | | | | "ff" is for "fixed function". This frees up the name "gs" to refer to user-defined geometry shaders. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/fs: Detect GRF sources in split_virtual_grfs send-from-GRF code.Kenneth Graunke2013-08-301-1/+5
| | | | | | | | | | | | | | | | | It is incorrect to assume that src[0] of a SEND-from-GRF opcode is the GRF. For example, FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD uses src[1] for the GRF. To be safe, loop over all the source registers and mark any GRFs. We probably won't ever have more than one, but it's simpler to just check all three rather than attempting to bail early. Not observed to fix anything yet, but likely to. Parallels the bug fix in the previous commit, which actually does fix known failures. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Cc: [email protected]
* i965/vs: Detect GRF sources in split_virtual_grfs send-from-GRF code.Kenneth Graunke2013-08-301-2/+6
| | | | | | | | | | | | | | | | | | | | It is incorrect to assume that src[0] of a SEND-from-GRF opcode is the GRF. VS_OPCODE_PULL_CONSTANT_LOAD_GEN7 uses an IMM as src[0], and stores the GRF as src[1]. To be safe, loop over all the source registers and mark any GRFs. We probably won't ever have more than one, but it's simpler to just check all three rather than attempting to bail early. Fixes assertion failures in Unigine Sanctuary since we started making register allocation rely on split_virtual_grfs working. (The register classes were actually sufficient, we were just interpreting an IMM as a virtual GRF number.) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68637 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Cc: [email protected]
* i965: Switch gen4-6 to using the sampler's base level for GL BASE_LEVEL.Eric Anholt2013-08-302-23/+12
| | | | | | | | Thanks to Ken for trawling through my neglected public branches and finding the bug in this change (inside a megacommit) that made me abandon this work. Reviewed-by: Kenneth Graunke <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-29 10:52:10 +0000