summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Remove _mesa_lookup_enum_by_name().Eric Anholt2013-09-232-34/+0
| | | | | | | | It's been unused for a long time. I stopped digging through git history as of 2009. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/gen4: Fix fragment program rectangle texture shadow compares.Eric Anholt2013-09-211-4/+4
| | | | | | | | | | | | | | The rescale_texcoord(), if it does something, will return just the GLSL-sized coordinate, leaving out the 3rd and 4th components where we were storing our projected shadow compare and the texture projector. Deref the shadow compare before using the shared rescale-the-coordinate code to fix the problem. Fixes piglit tex-shadow2drect.shader_test and txp-shadow2drect.shader_test Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69525 NOTE: This is a candidate for stable branches. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen7.5: Fix missing Shader Channel Select entries on HaswellAbdiel Janulgue2013-09-211-0/+7
| | | | | | | | | | | Probably non-intentional, but the SURFACE_STATE setup refactoring for buffer surfaces had missed the scs bits when creating constant surface states. Fixes broken GLB 2.5 on Haswell where the knight's textures are missing Signed-off-by: Abdiel Janulgue <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965, mesa: Use the new DECLARE_R[Z]ALLOC_CXX_OPERATORS macros.Kenneth Graunke2013-09-217-122/+12
| | | | | | | | | | | | | | | | These classes declared a placement new operator, but didn't declare a delete operator. Switching to the macro gives them a delete operator, which probably is a good idea anyway. This also eliminates a lot of boilerplate. v2: Properly use RZALLOC in Mesa IR/TGSI translators. Caught by Eric and Chad. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: Silence GCC warning 'comparison between signed and unsigned integer ↵Ian Romanick2013-09-191-1/+1
| | | | | | | | | expressions' Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* mesa: Fix broken call to print_table_statsIan Romanick2013-09-191-1/+3
| | | | | | | | | | The function takes a parameter, but none was given. Also, in the non-GET_DEBUG case, silence the unused parameter warning. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* mesa: Allow several ARB_geometry_shader4 queries in OpenGL 3.2Ian Romanick2013-09-192-4/+10
| | | | | | | | | | | | GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS, GL_MAX_GEOMETRY_OUTPUT_VERTICES, GL_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS, and GL_MAX_GEOMETRY_UNIFORM_COMPONENTS all have the same enum value and meaning as their _ARB counterparts. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* mesa: Expose MAX_GEOMETRY_{INPUT,OUTPUT}_COMPONENTS on OpenGL 3.2Ian Romanick2013-09-191-1/+3
| | | | | | | | | | | | | | | The comment '# GL 3.0 / GLES3' was incorrect. The MAX_VERTEX_OUTPUT_COMPONENTS and MAX_FRAGMENT_INPUT_COMPONENTS queries were added in OpenGL 3.2 (with geometry shaders) and OpenGL ES 3.0. This just fixes that comment. v2: Add the GEOMETRY queries in the existing '# GL 3.2' section since they have nothing to do with GLES3. Suggested by Paul. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* mesa: Get GL_MAX_FRAGMENT_INPUT_COMPONENTS from ↵Ian Romanick2013-09-192-2/+1
| | | | | | | | | | | | FragmentProgram.MaxInputComponents In OpenGL ES 3.0 the minimum-maximum for GL_MAX_VERTEX_OUTPUT_VECTORS is 16, but the minimum-maximum for GL_MAX_FRAGMENT_INTPUT_VECTORS is 15. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* mesa: Get GL_MAX_VERTEX_OUTPUT_COMPONENTS from VertexProgram.MaxOutputComponentsIan Romanick2013-09-192-2/+1
| | | | | | | | | | In OpenGL ES 3.0 the minimum-maximum for GL_MAX_VERTEX_OUTPUT_VECTORS is 16, but the minimum-maximum for GL_MAX_FRAGMENT_INTPUT_VECTORS is 15. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i915: Set VertexProgram.MaxOutputComponents and ↵Ian Romanick2013-09-191-0/+2
| | | | | | | | | | | | FragmentProgram.MaxInputComponents This was the only remaining place in Mesa that sets MaxVaryings without also setting these values. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Set *Program.Max{Input,Output}ComponentsIan Romanick2013-09-191-1/+6
| | | | | | | | | Now that MaxVaryings is > 16, VertexProgram.MaxOutputComponents, GeometryProgram.MaxInputComponents, GeometryProgram.MaxOutputComponents, and FragmentProgram.MaxInputComponents also need to be set. Signed-off-by: Ian Romanick <[email protected]> Cc: Paul Berry <[email protected]>
* mesa: Set default values for Max{Input,Output}Components in init_program_limitsIan Romanick2013-09-191-0/+6
| | | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* mesa: Remove gl_constants::MaxVaryingComponentsIan Romanick2013-09-191-1/+0
| | | | | | | | | | There are no longer any users. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Paul Berry <[email protected]> Cc: Zack Rusin <[email protected]>
* mesa: Use correct data for MAX_{VERTEX,GEOMETRY}_VARYING_COMPONENTS_ARB queriesIan Romanick2013-09-192-3/+6
| | | | | | | | | | | | | | | | | | | | | Previously gl_constants::MaxVaryingComponents was used. Now gl_constants::VertexProgram::MaxOutputs and gl_constants::GeometryProgram::MaxOutputs are used. This means that st_extensions.c had to be updated to set these fields instead of MaxVaryingComponents. It was previously the only place that set MaxVaryingComponents. I believe that the structure is allocated by calloc, so the value should be initialized to zero in non-Gallium drivers before and after my change. Right now nobody enables GL_ARB_geometry_shader4, so it's pretty much dead code anyway. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Paul Berry <[email protected]> Cc: Zack Rusin <[email protected]>
* mesa: Track per-stage shader input and output limits independentlyIan Romanick2013-09-191-0/+24
| | | | | | | | | | | | | | | | | | | | | | | In OpenGL 3.2 these are independently queryable. In addition, the spec has different minimum-maximums for various values. GL_MAX_VERTEX_OUTPUT_COMPONENTS is 64, but GL_MAX_GEOMETRY_OUTPUT_COMPONENTS (and GL_MAX_FRAGMENT_INPUT_COMPONENTS) is 128. In OpenGL ES 3.0 these are also independently queryable. The spec has different minimum-maximums for various values. GL_MAX_VERTEX_OUTPUT_VECTORS is 16, but GL_MAX_FRAGMENT_INTPUT_VECTORS is 15. None of these values are used yet. I have just added space to the structures. Future patches will add users and eventually remove some old fields. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Paul Berry <[email protected]> Cc: Zack Rusin <[email protected]>
* mesa: Support GL_MAX_VERTEX_OUTPUT_COMPONENTS query with ES3Ian Romanick2013-09-192-0/+2
| | | | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Paul Berry <[email protected]> Cc: "9.1 9.2" <[email protected]>
* i965: Refactor Gen4-6 SURFACE_STATE setup for buffer surfaces.Kenneth Graunke2013-09-191-61/+39
| | | | | | | | | | | | | | This was an embarassingly large amount of copy and pasted code, and it wasn't particularly simple code either. By factoring it out into a helper function, we consolidate the complexity. v2: Properly NULL-check bo. Caught by Eric Anholt. v3: Do the subtraction by 1 in gen7_emit_buffer_surface_state, rather than making callers do it. This makes the buffer_size parameter the actual size of the buffer. Suggested by Paul Berry. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Refactor Gen7+ SURFACE_STATE setup for buffer surfaces.Kenneth Graunke2013-09-191-86/+60
| | | | | | | | | | | | | | This was an embarassingly large amount of copy and pasted code, and it wasn't particularly simple code either. By factoring it out into a helper function, we consolidate the complexity. v2: Properly NULL-check bo. Caught by Eric Anholt. v3: Do the subtraction by 1 in gen7_emit_buffer_surface_state, rather than making callers do it. This makes the buffer_size parameter the actual size of the buffer. Suggested by Paul Berry. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Fix off by one errors in texture buffer size calculations.Kenneth Graunke2013-09-192-2/+2
| | | | | | | | | The value that's split into width/height/depth needs to be the size of the buffer minus one. This makes it consistent with the constant buffer and shader time SURFACE_STATE setup code. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Fix writemask != 0 assertions on Sandybridge.Kenneth Graunke2013-09-191-2/+4
| | | | | | | | | | | | | | | | | | | This fixes myriads of regressions since commit 169f9c030c16d1247a3a7629 ("i965: Add an assertion that writemask != NULL for non-ARFs."). On Sandybridge, our control flow handling (such as brw_IF) does: brw_set_dest(p, insn, brw_imm_w(0)); insn->bits1.branch_gen6.jump_count = 0; This results in a IMM destination with zero for the writemask. IMM destinations are rather bizarre, but the code has been working for ages, so I'm loathe to change it. Fixes glxgears on Sandybridge. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Fix brw_gs_prog_data_compare to actually check field members.Kenneth Graunke2013-09-191-1/+1
| | | | | | | | | | | &a and &b are the address of the local stack variables, not the actual structures. Instead of comparing the fields of a and b, we compared ...some stack memory. Not a candidate for stable since GS code doesn't exist in 9.2. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Fix brw_vs_prog_data_compare to actually check field members.Kenneth Graunke2013-09-191-1/+1
| | | | | | | | | | | | | &a and &b are the address of the local stack variables, not the actual structures. Instead of comparing the fields of a and b, we compared ...some stack memory. Caught by Valgrind on Piglit's glsl-lod-bias test (among many others). Signed-off-by: Kenneth Graunke <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68233 Reviewed-by: Chad Versace <[email protected]> Cc: [email protected]
* i965: Move binding table code to a new file, brw_binding_tables.c.Kenneth Graunke2013-09-196-187/+243
| | | | | | | | | | | | The code to upload the binding tables for each stage was scattered across brw_{vs,gs,wm}_surface_state.c and brw_misc_state.c, which also contain a lot of code to populate individual SURFACE_STATE structures. This patch brings all the binding table upload code together, and splits it out from the code which fills in SURFACE_STATE entries. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Use brw_upload_binding_table() for the pixel shader as well.Kenneth Graunke2013-09-191-18/+5
| | | | | | | | | | | This is not quite the same: brw_upload_binding_table() also has code to early-return if there are no entries, while the existing code did not. The PS binding table is unlikely to be empty since it will have at least one color buffer. If it ever is empty, early returning seems wise. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Generalize brw_vec4_upload_binding_table() beyond vec4 stages.Kenneth Graunke2013-09-193-16/+19
| | | | | | | | | | | | | | Instead of passing in a brw_vec4_prog_data structure, we can simply pass the one field it needs: the number of entries in the binding table. We also need to pass in the shader time surface index rather than hardcoding SURF_INDEX_VEC4_SHADER_TIME. Since the resulting function is stage-agnostic, this patch removes "vec4_" from the name. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Convert loop to memcpy in brw_vec4_upload_binding_table().Kenneth Graunke2013-09-191-9/+6
| | | | | | | This is probably more efficient. At any rate, it's less code. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Update comments in brw_vec4_upload_binding_table().Kenneth Graunke2013-09-191-6/+1
| | | | | | | | | | The first comment was a bit stale; there are more kinds of surfaces than textures and pull constants. The second was a leftover "to do" comment for something I already did. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Rename brw_{fs,vec4}_emit.cpp to brw_{fs,vec4}_generator.cpp.Kenneth Graunke2013-09-183-4/+4
| | | | | | | | | | | | | | | | | | The previous names were really confusing to talk about: - brw_fs_visitor() contained methods named emit_whatever(). - brw_fs_generator() contained methods named generate_whatever(), but lived in brw_fs_emit.cpp. So when someone said "the emit layer", or "emit code", we weren't sure whether they meant the visitor's emit() functions or the generator in brw_fs_emit.cpp. By renaming these files, the method names, class names, and file names all match, which is much less confusing. Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Paul Berry <[email protected]> Acked-by: Eric Anholt <[email protected]>
* i965: Lower ldexp.Matt Turner2013-09-171-1/+2
| | | | | v2: Drop frexp lowering. Reviewed-by: Paul Berry <[email protected]>
* glsl: Add support for ldexp.Matt Turner2013-09-175-0/+10
| | | | | v2: Drop frexp. Rebase on builtins rewrite. Reviewed-by: Paul Berry <[email protected]>
* i965: Add some missing bits to {mesa,brw,cache}_bits[].Paul Berry2013-09-172-0/+14
| | | | | | | | | | | | | These data structures are used for debug output, so it wasn't hurting anything that there were missing bits. But it's good to keep things up to date. This patch also adds static asserts so that the {brw,cache}_bits[] arrays are the proper size, so that we don't forget to add to them in the future. Unfortunately there's no convenient way to assert that mesa_bits[] is the proper size. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gs: Implement basic gl_PrimitiveIDIn functionality.Paul Berry2013-09-174-0/+11
| | | | | | | | | | | | | | | | | If the geometry shader refers to the built-in variable gl_PrimitiveIDIn, we need to set a bit in 3DSTATE_GS to tell the hardware to dispatch primitive ID to r1, and we need to leave room for it when allocating registers. Note: this feature doesn't yet work properly when software primitive restart is in use (the primitive ID counter will incorrectly reset with each primitive restart, since software primitive restart works by performing multiple draw calls). I plan to address that in a future patch series. Fixes piglit test "spec/glsl-1.50/execution/geometry/primitive-id-in". Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gs: New gs primitive types are supported by HW primitive restart.Paul Berry2013-09-171-0/+4
| | | | | | | | | | When we previously implemented primitive restart, we didn't add cases to brw_primitive_restart.c's can_cut_index_handle_prims() for the primitive types that are introduced with geometry shaders. It turns out that all of the new primitive types are supported by hardware primitive restart. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gs: Add new primitive types.Paul Berry2013-09-172-3/+7
| | | | | | | | As part of its support for geometry shaders, GL 3.2 introduces four new primitive types: GL_LINES_ADJACENCY, GL_LINE_STRIP_ADJACENCY, GL_TRIANGLES_ADJACENCY, and GL_TRIANGLE_STRIP_ADJACENCY. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Remove MIPLAYOUT_BELOW from Gen4-6 constant buffer surface state.Kenneth Graunke2013-09-171-1/+0
| | | | | | | | | | Specifying a miptree layout makes no sense for constant buffers. This has no functional change since BRW_SURFACE_MIPMAPLAYOUT_BELOW is just a #define for 0. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Use gen7_upload_constant_state for 3DSTATE_CONSTANT_PS as well.Kenneth Graunke2013-09-161-27/+1
| | | | | | | Now we use gen7_upload_constant_state() for all three shader stages. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Set brw_stage_state::push_const_size for PS constants.Kenneth Graunke2013-09-161-1/+6
| | | | | | | | | This paves the way for using gen7_upload_constant_state for PS data. The formula is copied from gen7_wm_state.c. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Introduce a prog_data temporary in gen6_upload_wm_push_constants.Kenneth Graunke2013-09-161-8/+8
| | | | | | | This saves a bit of typing and shortens a few lines. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/gen6+: Support 128 varying components.Paul Berry2013-09-161-0/+3
| | | | | | | | | | | | | | | | GL 3.2 requires us to support 128 varying components for geometry shader outputs and fragment shader inputs, and 64 varying components otherwise. But there's no hardware limitation that restricts us to 64 varying components, and core Mesa doesn't currently allow different stages to have different maximum values, so just go ahead and enable 128 varying components for all stages. This gets us better test coverage anyway. Even though we are only working on GL 3.2 support for gen7 right now, gen6 also supports 128 varying components, so go ahead and switch it on there too. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/ff_gs: Generate URB writes using a loop.Paul Berry2013-09-161-23/+38
| | | | | | | | | | | | | Previously we only ever did 1 URB write, since the maximum number of varyings we support is small enough to fit in 1 URB write (when using BRW_URB_SWIZZLE_NONE, which is what the pre-Gen7 GS always uses). But we're about to increase the number of varying components we support from 64 to 128. With 128 varyings, the most URB writes we'll have to do is 2, but it's just as easy to write a general-purpose loop. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen6: Fix assertions on VS/GS URB size.Paul Berry2013-09-161-2/+2
| | | | | | | | | The "{VS,GS} URB Entry Allocation Size" fields of 3DSTATE_URB allow values in the range 0-4, but they are U8-1 fields, so the range of possible allocation sizes is 1-5. We were erroneously prohibiting a size of 5. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vec4: Generate URB writes using a loop.Paul Berry2013-09-161-31/+21
| | | | | | | | | Previously we only ever did 1 or 2 URB writes, since the maximum number of varyings we support is small enough to fit in 2 URB writes. But GL 3.2 requires the geometry shader to support 128 output varying components, and this could require up to 3 URB writes. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: When >64 input components, order them to match prev pipeline stage.Paul Berry2013-09-162-7/+45
| | | | | | | | | | | | | Since the SF/SBE stage is only capable of performing arbitrary reorderings of 16 varying slots, we can't arrange the fragment shader inputs in an arbitrary order if there are more than 16 input varying slots in use. We need to make sure that slots 16-31 match the corresponding outputs of the previous pipeline stage. The easiest way to accomplish this is to just make all varying slots match up with the previous pipeline stage. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Simplify computation of key.input_slots_valid during precompile.Paul Berry2013-09-161-11/+1
| | | | | | | | | | | The for loop was rather silly. In addition to checking brw->gen < 6 on each loop iteration, it took pains to exclude bits from fp->Base.InputsRead that don't correspond to fragment shader inputs. But those bits would never have been set in the first place, since the only bits that are ever set in fp->Base.InputsRead are fragment shader inputs. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gs: Stop storing an input VUE map in the GS program key.Paul Berry2013-09-163-5/+8
| | | | | | | | | | | | | Now that the vertex shader output VUE map is determined solely by a 64-bit bitfield, we don't have to store it in its entirety in the geometry shader program key; instead, we can just store the bitfield, and let the geometry shader infer the VUE map at compile time. This dramatically reduces the size of the geometry shader program key, which we want to keep small since it gets recomputed whenever the active program changes. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen6+: Remove VUE map dependency on userclip_active.Paul Berry2013-09-163-17/+26
| | | | | | | | | | | | | | | | | | | | | | | | Previously, on Gen6+, we laid out the vertex (or geometry) shader VUE map differently depending whether user clipping was active. If it was active, we put the clip distances in slots 2 and 3 (where the clipper expects them); if it was inactive, we assigned them in the order of the gl_varying_slot enum. This made for unnecessary recompiles, since turning clipping on/off for a shader that used gl_ClipDistance might rearrange the varyings. It also required extra bookkeeping, since it required the user clipping flag to be provided to brw_compute_vue_map() as a parameter. With this patch, we always put clip distances at in slots 2 and 3 if they are written to. do_vs_prog() and do_gs_prog() are responsible for ensuring that clip distances are written to when user clipping is enabled (as do_vs_prog() previously did for gen4-5). This makes the only input to brw_compute_vue_map() a bitfield of which varyings the shader writes to, a fact that we'll take advantage of in forthcoming patches. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Stop wasting input attribute space on gl_FragCoord and gl_FrontFacing.Paul Berry2013-09-163-9/+11
| | | | | | | | | | | | | | | | | | Previously, if a fragment shader accessed gl_FragCoord or gl_FrontFacing, we would assign them their own slots in the fragment shader input attribute array, using up space that could be made available to real varyings. This was not strictly necessary (since these values are not true varyings, and are instead computed from other data available in the FS payload). But we had to do it anyway because the SF/SBE setup code assumed that every 1 bit in the gl_program::InputsRead bitfield corresponded to a genuine varying variable. Now that the SF/SBE code consults brw_wm_prog_data and only sets up the attributes that the fragment shader actually needs, we don't have to do this anymore. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/sf: Consult brw_wm_prog_data when setting up SF/SBE state.Paul Berry2013-09-162-23/+35
| | | | | | | | | | | | | | | | | | | | Previously, the SF/SBE setup code delivered varying inputs to the FS in the order in which they appear in the gl_program::InputsRead bitfield, since that's what the FS expects. When we add support for more than 64 varying components, this will no longer always be the case, because the Gen6+ SF/SBE stage is only capable of performing arbitrary reorderings of 16 varying slots. So, when there are more than 16 vec4's worth of varying inputs, the FS will have to adjust the order its input varyings in order to partially match the order of outputs from the geometry or vertex shader. To allow extra flexibility in the ordering of FS varyings, this patch causes the SF/SBE to deliver varying inputs to the FS in exactly the order that the FS requests, by consulting brw_wm_prog_data::urb_setup and brw_wm_prog_data::num_varying_inputs. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/sf: Consolidate common code for setting up gen6-7 attribute overrides.Paul Berry2013-09-163-129/+97
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 02:59:29 +0000