summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* 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]>
* i965/sf: Use BRW_SF_URB_ENTRY_READ_OFFSET rather than hardcoded values.Paul Berry2013-09-164-4/+12
| | | | | | | | | We always program the SF unit to start reading the vertex URB entry at offset 1. In upcoming patches, we'll be adding FS code that relies on this. So consistently use the constant BRW_SF_URB_ENTRY_READ_OFFSET rather than hardcoding a 1. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Consult brw_wm_prog_data::num_varying_inputs when setting up WM state.Paul Berry2013-09-162-3/+5
| | | | | | | | | | | | | | | | | | | | | | | Previously, we assumed that the number of varying inputs consumed by the fragment shader was equal to the number of bits set in gl_program::InputsRead. However, we'll soon be making two changes that will cause that not to be true: - We'll stop wasting varying input space for gl_FragCoord and gl_FrontFacing, which aren't varyings. - For fragment shaders that have more than 16 varying inputs, we'll adjust the layout of the inputs to account for the fact that the SF/SBE pipeline stage can't reorder inputs beyond the first 16; if there are GS outputs that the FS doens't use (or vice versa) this may cause the number of FS varying inputs to change. So, instead of trying to guess the number of FS inputs from gl_program::InputsRead, simply read it from brw_wm_prog_data:num_varying_inputs, which is guaranteed to be correct since it's populated by fs_visitor::calculate_urb_setup(). Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Change brw_wm_prog_data::urb_read_length to num_varying_inputs.Paul Berry2013-09-163-5/+7
| | | | | | | | | | | | | | | | | | On gen4-5, the FS stage reads varying inputs from URB entries that were output by the SF thread, where each register stores the interpolation setup for two components of a vec4, therefore the FS urb_read_length is twice the number of FS input varyings. On gen6+, varying inputs are directly deposited in the FS payload by the SF/SBE fixed function logic, so urb_read_length is irrelevant. However, in future patches, it will be nice to be able to consult brw_wm_prog_data to determine how many varying inputs the FS expects (rather than inferring it from gl_program::InputsRead). So instead of storing urb_read_length, we simply store num_varying_inputs in brw_wm_prog_data. On gen4-5, we multiply this by 2 to recover the URB read length. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Expose "urb_setup" as part of brw_wm_prog_data.Paul Berry2013-09-164-8/+14
| | | | | | | | | | | | | | | | At the moment, for Gen6+, the FS assumes that all varying inputs are delivered to it in the order in which they appear in the gl_program::InputsRead bitfield, and the SF/SBE setup code ensures that they are delivered in this order. When we add support for more than 64 varying components, this will no longer always be possible, because the Gen6+ SF/SBE stage is only capable of performing arbitrary reorderings of 16 varying slots. To allow extra flexibility in the ordering of FS varyings, this patch causes the FS to advertise exactly what ordering it expects. Reviewed-by: Kenneth Graunke <[email protected]>
* st/mesa: don't dereference stObj->pt if NULLDave Airlie2013-09-161-1/+1
| | | | | | | | | | | It seems a user app can get us into this state, I trigger the fail running fbo-maxsize inside virgl, it fails to create the backing storage for the texture object, but then segfaults here when it should fail the completeness test. Cc: "9.2" <[email protected]> Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* i965: Use brw_stage_state for WM data as well.Kenneth Graunke2013-09-1313-93/+71
| | | | | | | | This gets the VS, GS, and PS all using the same data structure. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Increase the size of brw_stage_state::surf_offset.Kenneth Graunke2013-09-131-1/+1
| | | | | | | | | | Since BRW_MAX_WM_SURFACES is greater than BRW_MAX_VEC4_SURFACES, the existing array isn't large enough to be used by the WM. Increasing it will make it possible to share them. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Add comments to the new brw_state_state structure's fields.Kenneth Graunke2013-09-131-0/+10
| | | | | | | | | | These are largely based on the similar fields in brw->wm. v2: Add a better comment than "Scratch buffer". Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* mesa: Rename MESA_shader_integer_mix to EXT_shader_integer_mixIan Romanick2013-09-133-3/+3
| | | | | | | | | | | | | | Everyone at the Khronos meeting was as surprised that GLSL didn't already support this as we were. Several vendors said they'd ship it, but there didn't seem to be enough interest to put in the effort to make it ARB or KHR. v2: Fix a couple typos and rename the spec file to EXT_shader_integer_mix.spec. Suggested by Roland. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* mesa: Disallow relinking if a program is used by an active XFB object.Kenneth Graunke2013-09-123-7/+47
| | | | | | | | | | | | | | | | | Paused transform feedback objects may refer to a program other than the current program. If any active objects refer to a program, LinkProgram must reject the request to relink. The code to detect this is ugly since _mesa_HashWalk is awkward to use, but unfortunately we can't use hash_table_foreach since there's no way to get at the underlying struct hash_table (and even then, we'd need to handle locking somehow). Fixes the last subcase of Piglit's new ARB_transform_feedback2 api-errors test. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: Reject ResumeTransformFeedback if the wrong program is bound.Kenneth Graunke2013-09-121-0/+11
| | | | | | | | | | | This is actually a pretty important error condition: otherwise, you could set up transform feedback with one program, and resume it with a program that generates a completely different set of outputs. Fixes a subcase of Piglit's new ARB_transform_feedback2 api-errors test. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: Track the vertex program active at BeginTransformFeedback() time.Kenneth Graunke2013-09-122-0/+8
| | | | | | | | | | The next few patches will use this for API error checking. All of the drivers appear to CALLOC_STRUCT transform feedback objects, so this should be properly NULL initialized on creation. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: Disallow TransformFeedbackVaryings when active.Kenneth Graunke2013-09-121-0/+10
| | | | | | | Fixes a subcase of Piglit's new ARB_transform_feedback2 api-errors test. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* i965/gs: implement EndPrimitive() functionality in the visitor.Paul Berry2013-09-112-1/+241
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to GLSL, the shader may call EndPrimitive() at any point during its execution, causing the line or triangle strip currently being output to be terminated and a new strip to be begun. This is implemented in gen7 hardware by using one control data bit per vertex, to indicate whether EndPrimitive() was called after that vertex was emitted. In order to make this work without sacrificing too much efficiency, we accumulate 32 control data bits at a time in a GRF. When we have accumulated 32 bits (or when the shader terminates), we output them to the appropriate DWORD in the control data header and reset the accumulator to 0. We have to take special care to make sure that EndPrimitive() calls that occur prior to the first vertex have no effect. Since geometry shaders that output a large number of vertices are likely to be rare, an optimization kicks in if max_vertices <= 32. In this case, we know that we can wait until the end of shader execution before any control data bits need to be output. I've tried to write the code in such a way that in the future, we can easily adapt it to output stream ID bits (which are two bits/vertex instead of one). Fixes piglit tests "spec/glsl-1.50/glsl-1.50-geometry-end-primitive *". Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vec4: Add the ability to emit opcodes with just a dst register.Paul Berry2013-09-112-0/+8
| | | | | | | This is needed for GS_OPCODE_PREPARE_CHANNEL_MASKS. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gs: Add opcodes needed for EndPrimitive().Paul Berry2013-09-114-0/+120
| | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen7: Add the ability to send URB_WRITE_OWORD messages.Paul Berry2013-09-113-2/+16
| | | | | | | | | | | | | | | Previously, brw_urb_WRITE() would always generate a URB_WRITE_HWORD message, we always wanted to write data to the URB in pairs of varying slots or larger (an HWORD is 32 bytes, which is 2 varying slots). In order to support geometry shader EndPrimitive functionality, we'll need the ability to write to just a single OWORD (16 byte) slot, since we'll only be outputting 32 of the control data bits at a time. So this patch adds a flag that will cause brw_urb_WRITE to generate a URB_WRITE_OWORD message. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen7: Allow URB_WRITE channel masks to be used.Paul Berry2013-09-112-1/+7
| | | | | | | | | | | | | | Previously, brw_urb_WRITE() would unconditionally override the channel masks in the URB_WRITE message to 0xff (indicating that all channels should be written to the URB). In order to support geometry shader EndPrimitive functionality, we'll need the ability to set the channel masks programatically, so that we can output just 32 of the control data bits at a time. So this patch adds a flag that will prevent brw_urb_WRITE() from overriding them. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gs: Set control data header size/format appropriately for EndPrimitive().Paul Berry2013-09-117-15/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The gen7 geometry shader uses a "control data header" at the beginning of the output URB entry to store either (a) flag bits (1 bit/vertex) indicating whether EndPrimitive() was called after each vertex, or (b) stream ID bits (2 bits/vertex) indicating which stream each vertex should be sent to (when multiple transform feedback streams are in use). Fortunately, OpenGL only requires separate streams to be supported when the output type is points, and EndPrimitive() only has an effect when the output type is line_strip or triangle_strip, so it's not a problem that these two uses of the control data header are mutually exclusive. This patch modifies do_vec4_gs_prog() to determine the correct hardware settings for configuring the control data header, and modifies upload_gs_state() to propagate these settings to the hardware. In addition, it modifies do_vec4_gs_prog() to ensure that the output URB entry is large enough to contain both the output vertices *and* the control data header. Finally, it modifies vec4_gs_visitor so that it accounts for the size of the control data header when computing the offset within the URB where output vertex data should be stored. Reviewed-by: Ian Romanick <[email protected]> v2: Fixed incorrect handling of IVB/HSW differences. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: During linking, record whether a GS uses EndPrimitive().Paul Berry2013-09-112-0/+3
| | | | | | | | | This information will be useful in the i965 back end, since we can save some compilation effort if we know from the outset that the shader never calls EndPrimitive(). Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* 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]>
* st/dri: do not create a new context for msaa copyMaarten Lankhorst2013-09-111-1/+1
| | | | | | | | | | | | | | | | Commit b77316ad7594f st/dri: always copy new DRI front and back buffers to corresponding MSAA buffers introduced creating a pipe_context for every call to validate, which is not required because the callers have a context anyway. Only exception is egl_g3d_create_pbuffer_from_client_buffer, can someone test if it still works with NULL passed as context for validate? From examining the code I believe it does, but I didn't thoroughly test it. Signed-off-by: Maarten Lankhorst <[email protected]> Cc: 9.2 <[email protected]> Reviewed-by: Marek Olšák <[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]>
* mesa: Properly set the fog scale (gl_Fog.scale) to +INF when fog start and ↵Henri Verbeet2013-09-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | end are equal. This was originally introduced by commit ba47aabc9868b410cdfe3bc8b6d25a44a598cba2, but unfortunately the commit message doesn't go into much detail about why +INF would be a problem here. A similar issue exists for STATE_FOG_PARAMS_OPTIMIZED, but allowing infinity there would potentially introduce NaNs where they shouldn't exist, depending on the values of fog end and the fog coord. Since STATE_FOG_PARAMS_OPTIMIZED is only used for fixed function (including ARB_fragment_program with fog option), and the calculation there probably isn't very stable to begin with when fog start and end are close together, it seems best to just leave it alone. This fixes piglit glsl-fs-fogscale, and a couple of Wine D3D tests. No piglit regressions on Cayman. Signed-off-by: Henri Verbeet <[email protected]> Tested-by: Brian Paul <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Use correct enum conversion function.Vinson Lee2013-09-101-1/+1
| | | | | | | Fixes "Mixing enum types" defect reported by Coverity. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Ensure gl_sync_object is fully initialized.Vinson Lee2013-09-101-1/+1
| | | | | | | | | | | | 278372b47e4db8a022d57f60302eec74819e9341 added the uninitialized pointer field gl_sync_object:Label. A free of this pointer, added in commit 6d8dd59cf53d2f47b817d79204a52bb3a46e8c77, resulted in a crash. This patch fixes piglit ARB_sync regressions with swrast introduced by 6d8dd59cf53d2f47b817d79204a52bb3a46e8c77. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Brian Paul <[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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 05:07:40 +0000