summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* st/mesa: report correct precision information for low/medium/high intsIlia Mirkin2016-03-201-0/+7
| | | | | | | | | | | | | | | | | When we have native integers, these have full precision. Whether they're low/medium/high isn't piped through the TGSI yet, but eventually those might have differing precisions. For now they're just 32-bit ints. Fixes the following dEQP tests: dEQP-GLES3.functional.state_query.shader.precision_vertex_highp_int dEQP-GLES3.functional.state_query.shader.precision_fragment_highp_int which expected highp ints to have full 32-bit precision, not the default 23-bit float precision. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Dave Airlie <[email protected]>
* st/mesa: only minify depth for 3d targetsIlia Mirkin2016-03-201-1/+4
| | | | | | | | | | | | | | | | We make sure that that image depth matches the level's depth before copying it into place. However we should only be minifying the first level's depth for 3d textures - array textures have the same depth for all levels. This fixes tests such as dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.* and I suspect account for a number of other odd situations I've run into where level > 0 of array textures was messed up. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Dave Airlie <[email protected]> Cc: "11.1 11.2" <[email protected]>
* st/mesa: set TGSI property NEXT_SHADERMarek Olšák2016-03-191-0/+36
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: Disallow GL_FRAMEBUFFER_ATTACHMENT_OBJECT_NAME on winsys FBO.Kenneth Graunke2016-03-191-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | Fixes: dEQP-GLES3.functional.negative_api.state.get_framebuffer_attachment_parameteriv Apparently, GL_FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is not allowed when GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is GL_FRAMEBUFFER_DEFAULT, and is expected to result in a GL_INVALID_ENUM error. No GL specification actually defines what GL_FRAMEBUFFER_DEFAULT means. It probably means the window system FBO. It also doesn't mention the behavior of any queries for that type. Various ARB folks seem fairly confused about it too. For now, just do something vaguely like what dEQP expects. I think we probably need to check the visual bits against 0 for the attachment, but we haven't been doing that thusfar, and given how confusingly this is specified, I can't imagine anyone relying on it. v2: Improve comments, move error condition above the _mesa_get_fb0_attachment call, add forgotten "return" (all suggested/caught by Jordan Justen). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* mesa: Do proper format error checks for GenerateMipmap in ES 3.x.Kenneth Graunke2016-03-181-0/+14
| | | | | | | | | | | | | | | | | | | | | | | According to the OpenGL ES 3.2 spec's description of GenerateMipmap: "An INVALID_OPERATION error is generated if the levelbase array was not specified with an unsized internal format from table 8.3 or a sized internal format that is both color-renderable and texture-filterable according to table 8.10." Similar text exists in the ES 3.0 specification as well. Our existing rules are pretty close, but miss a few things. The OpenGL specification actually doesn't have any text about internal format checking - our existing code comes from a Khronos bug report. The ES 3.x spec provides a clearer description. Fixes dEQP-GLES3.functional.negative_api.texture.generatemipmap and dEQP-GLES2.functional.negative_api.texture.generatemipmap_zero_level _array_compressed. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* mesa: Add color renderable/texture filterable format info for ES 3.x.Kenneth Graunke2016-03-182-0/+90
| | | | | | | | | | | | OpenGL ES 3.x contains a table of sized internal formats and their required properties. In particular, each format is marked as "Color Renderable" or "Texture Filterable". This patch introduces two functions that can be used to query the information from that table. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Stop XY clipping point and line primitives.Kenneth Graunke2016-03-181-1/+7
| | | | | | | | | | | | | | | | | | | | | | | Wide points and lines are not supposed to be clipped by the viewport. Rather, they should be rendered, and any fragments outside of the viewport should be discarded. The traditional use case for this behavior is rendering moving wide point particles. When the center of the point approaches the viewport edge, clipping would make it pop out of view early. Fixes: - dEQP-GLES2.functional.clipping.point.wide_point_clip - dEQP-GLES3.functional.clipping.point.wide_point_clip - dEQP-GLES3.functional.clipping.point.wide_point_clip_viewport_center - dEQP-GLES3.functional.clipping.point.wide_point_clip_viewport_corner - dEQP-GLES3.functional.clipping.line.wide_line_clip_viewport_center - dEQP-GLES3.functional.clipping.line.wide_line_clip_viewport_corner Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94453 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94454 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Scissor to the viewport when rendering points/lines.Kenneth Graunke2016-03-182-5/+8
| | | | | | | | | | | | | | We're about to start allowing wide points/lines whose vertices are outside the viewport past the clipper. This scissoring hack ensures that any fragments generated are still restricted to the viewport. It is not necessary on Gen8+ as those platforms already discard fragments which are outside the viewport. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94453 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94454 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Include the viewport in the scissor rectangle.Kenneth Graunke2016-03-181-4/+4
| | | | | | | | | | We'll need to use scissoring to restrict fragments to the viewport soon. It seems harmless to include it generally, so let's do that. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94453 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94454 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Introduce an is_drawing_lines() helper.Kenneth Graunke2016-03-181-0/+30
| | | | | | | | | Similar to is_drawing_points(). v2: Account for isoline tessellation output topology. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Move is_drawing_points to brw_state.h.Kenneth Graunke2016-03-182-24/+24
| | | | | | | | | I need to use this in multiple source files. v2: Rebase on TES output domain fix. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Fix gl_TessLevelOuter[] for isolines.Kenneth Graunke2016-03-182-6/+22
| | | | | | | | | | | | | | | | | | | | | | | Thanks to James Legg for finding this! From the ARB_tessellation_shader spec: "The number of isolines generated is derived from the first outer tessellation level; the number of segments in each isoline is derived from the second outer tessellation level." According to the PRM, "TF.LineDensity determines # lines" while "TF.LineDetail determines # segments". Line Density is stored at DWord 6, while Line Detail is at DWord 7. So, they're not reversed like they are for triangles and quads. Fixes Piglit's spec/arb_tessellation_shader/execution/isoline, and about 24 dEQP isoline tests (with GL_EXT_tessellation_shader hacked on - it's not normally enabled). Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94524 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Decode non-normalized coordinates bit in SAMPLER_STATE.Kenneth Graunke2016-03-181-2/+3
| | | | | | | We weren't printing this for some reason. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]>
* i965: Account for TES in is_drawing_points().Kenneth Graunke2016-03-181-1/+8
| | | | | | | | | | | | | Now that we implement tessellation shaders, the TES might be the last stage enabled. If it's outputting points, then the primitive type reaching the SF is points. We need to account for this. Caught by Ilia Mirkin. v2: Update dirty bit comment above caller (caught by Iago) Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* st/mesa: clean up st_translate_texture_target()Brian Paul2016-03-181-25/+44
| | | | | | Reformat code. Improve assertion. Reviewed-by: Charmaine Lee <[email protected]>
* st/mesa: simplify drawpixels shader code with tgsi transform helper functionsBrian Paul2016-03-181-64/+18
| | | | Reviewed-by: Charmaine Lee <[email protected]>
* st/mesa: simplify bitmap shader code with tgsi transform helper functionsBrian Paul2016-03-181-37/+8
| | | | Reviewed-by: Charmaine Lee <[email protected]>
* mesa: remove remaining tabs in prog_parameter.cTimothy Arceri2016-03-181-8/+8
| | | | Acked-by: Matt Turner <[email protected]>
* mesa: inline _mesa_add_unnamed_constant()Timothy Arceri2016-03-182-24/+6
| | | | Reviewed-by: Matt Turner <[email protected]>
* mesa: simplify and inline _mesa_lookup_parameter_index()Timothy Arceri2016-03-183-41/+18
| | | | | | The function has only one user and strings are always null terminated. Reviewed-by: Matt Turner <[email protected]>
* mesa: make _mesa_lookup_parameter_constant staticTimothy Arceri2016-03-182-100/+94
| | | | | | This is not used outside of prog_parameter.c Reviewed-by: Matt Turner <[email protected]>
* mesa: remove unused functionTimothy Arceri2016-03-181-6/+0
| | | | Reviewed-by: Matt Turner <[email protected]>
* st/mesa: honour sized internal formats in st_choose_format (v2)Nicolai Hähnle2016-03-171-21/+6
| | | | | | | | | | | | | | | | | | | | | The bitcasting which is possible with shader images (and texture views?) requires that when the user specifies a sized internal format for a texture, we really allocate that format. To this end: (1) find_exact_format should ignore sized internal formats and (2) some of the entries in the mapping table corresponding to sized internal formats are reordered to use an RGBA format instead of a BGRA one. This fixes arb_shader_image_load_store-bitcast in the (work in progress) ARB_shader_image_load_store implementation for radeonsi. v2: don't change the mapping of GL_RGB10: the change caused a regression because it preferred a format with an alpha channel, and GL_RGB10 is not among the supported formats for shader images Reviewed-by: Marek Olšák <[email protected]>
* nir: add a bit_size parameter to nir_ssa_dest_initConnor Abbott2016-03-172-7/+10
| | | | | | | | | | | | | | | | | | | | | | v2: Squash multiple commits addressing the new parameter in different files so we don't break the build (Iago) v3: Fix tgsi (Samuel) v4: Fix nir_clone.c (Samuel) v5: Fix vc4 and freedreno (Iago) v6 (Sam) - Fix build errors in nir_lower_indirect_derefs - Use helper to get type size from nir_alu_type. Signed-off-by: Iago Toral Quiroga <[email protected]> Signed-off-by: Samuel Iglesias Gonsalvez <[email protected]> Tested-by: Rob Clark <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* nir: rename nir_const_value fields to include bitsize informationIago Toral Quiroga2016-03-176-63/+63
| | | | | Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* nir: update opcode definitions for different bit sizesConnor Abbott2016-03-171-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some opcodes need explicit bitsizes, and sometimes we need to use the double version when constant folding. v2: fix output type for u2f (Iago) v3: do not change vecN opcodes to be float. The next commit will add infrastructure to enable 64-bit integer constant folding so this is isn't really necessary. Also, that created problems with source modifiers in some cases (Iago) v4 (Jason): - do not change bcsel to work in terms of floats - leave ldexp generic Squashed changes to handle different bit sizes when constant folding since otherwise we would break the build. v2: - Use the bit-size information from the opcode information if defined (Iago) - Use helpers to get type size and base type of nir_alu_type enum (Sam) - Do not fallback to sized types to guess bit-size information. (Jason) Squashed changes in i965 and gallium/nir drivers to support sized types. These functions should only see sized types, but we can't make that change until we make sure that nir uses the sized versions in all the relevant places. A later commit will address this. Signed-off-by: Iago Toral Quiroga <[email protected]> Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965/nir: fix check to resolve booleans to work with sized nir_alu_typeSamuel Iglesias Gonsálvez2016-03-171-1/+1
| | | | | | | | | | As nir_alu_type has now embedded the data size, the check for the instruction's output type (to see if a boolean resolve is required) should ignore the data size part. Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965/nir: Lower nir compute shader shared variablesJordan Justen2016-03-173-0/+11
| | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Skip execution size adjustment for instructions of width 4Iago Toral Quiroga2016-03-171-1/+13
| | | | | | | | | | | | | | | | | | | | This code in brw_set_dest adjusts the execution size of any instruction with a dst.width < 8. However, we don't want to do this with instructions operating on doubles, since these will have a width of 4, but still need an execution size of 8 (for SIMD8). Unfortunately, we can't just check the size of the operands involved to detect if we are doing an operation on doubles, because we can have instructions that do operations on double operands interpreted as UD, operating on any of its 2 32-bit components. Previous commits have made it so we never emit instructions with a horizontal width of 4 that don't have the correct execution size set for gen6+, so we can skip it in this case, avoiding the conflicts with fp64 requirements. Expanding the same fix to other hardware generations requires many more changes but since we are not targetting fp64 support on them wer don't really care for now. Reviewed-by: Topi Pohjolainen <[email protected]>
* i965/vec4/gen6: fix exec_size for MOV with a width of 4 in generate_gs_ff_sync()Samuel Iglesias Gonsalvez2016-03-171-1/+3
| | | | | Signed-off-by: Samuel Iglesias Gonsalvez <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* i965/vec4/gen6: fix exec_size for instructions with destination width of 4Samuel Iglesias Gonsalvez2016-03-171-0/+6
| | | | | Signed-off-by: Samuel Iglesias Gonsalvez <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* i965/vec4/gen6: fix exec_size for instructions with width of 4 in ↵Samuel Iglesias Gonsalvez2016-03-171-0/+3
| | | | | | | generate_gs_svb_write() Signed-off-by: Samuel Iglesias Gonsalvez <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* i965/gs/gen6: fix execsize for instructions with width of 4 in ↵Samuel Iglesias Gonsalvez2016-03-171-1/+10
| | | | | | | | | | gen6_sol_program() v2: - Add assert (Topi). Signed-off-by: Samuel Iglesias Gonsalvez <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* i965: set correct execsize for MOVS with a width of 4 in brw_find_live_channelIago Toral Quiroga2016-03-171-0/+3
| | | | Reviewed-by: Topi Pohjolainen <[email protected]>
* i965/eu: set execution size for SEND message in brw_send_indirect_messageIago Toral Quiroga2016-03-171-0/+3
| | | | Reviewed-by: Topi Pohjolainen <[email protected]>
* i965/fs: Set exec size for gen7 pull const loadsIago Toral Quiroga2016-03-171-0/+1
| | | | | | | | | | v2 (Topi): - No need to set the execsize for the indirect send message, the next patch will handle that. - Set the execution size explicitly instead of taking it from the width of the dst that we set before. Reviewed-by: Topi Pohjolainen <[email protected]>
* i965/eu: set correct execution size in brw_NOPIago Toral Quiroga2016-03-171-2/+3
| | | | | | | v2: NOP should have an execsize of 1 (Matt) Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* meta: Don't use integer handles for shaders or programs.Kenneth Graunke2016-03-167-147/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we gave our internal clear/blit shaders actual GL handles and stored them in the shader/program hash table. We used ordinary GL API entrypoints to work with them. We thought this shouldn't be a problem because GL doesn't allow applications to invent their own names for shaders or programs. GL allocates all names via glCreateShader and glCreateProgram. However, having them in the hash table is a bit risky: if a broken application guesses the name of our shaders or programs, it could alter them, potentially screwing up future meta operations. Also, test cases can observe the programs in the hash table. Running a single dEQP process that executes the following test list: dEQP-GLES3.functional.negative_api.buffer.clear dEQP-GLES3.functional.negative_api.shader.compile_shader dEQP-GLES3.functional.negative_api.shader.delete_shader would result in the last two tests breaking. The compile_shader test calls glCompileShader(9) straight away, and since it hasn't even created any shaders or programs, it expects to get a GL_INVALID_VALUE error because there's no such name. However, because the clear test ran first, it created Meta programs, so an object named "9" did exist. This patch reworks Meta to work with gl_shader and gl_shader_program pointers directly. These internal programs have bogus names, and are never stored in the hash tables, so they're invisible to applications. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94485 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* mesa: Expose compile_shader() and link_program() beyond the file.Kenneth Graunke2016-03-162-10/+16
| | | | | | | | This will allow me to use them directly from Meta, bypassing the versions that work with GL integer handles. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: Make link_program() take a gl_shader_program, not a GLuint.Kenneth Graunke2016-03-161-6/+4
| | | | | | | | In half the callers, we already have a pointer, and don't need to look it up again. This will also help with upcoming meta work. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: Make compile_shader() take a gl_shader, not a GLuint.Kenneth Graunke2016-03-161-9/+6
| | | | | | | | In half the callers, we already have a pointer, and don't need to look it up again. This will also help with upcoming meta work. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* meta: Use the _mesa_meta_compile_and_link_program helper more places.Kenneth Graunke2016-03-162-40/+8
| | | | | | | Less boilerplate. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* meta: Use ARB_explicit_attrib_location in the rest of the meta shaders.Kenneth Graunke2016-03-163-19/+17
| | | | | | | | | | | | | | | | | This is cleaner than using glBindAttribLocation(). Not all drivers support the extension, but I don't think those drivers use GLSL in the first place. Apparently some Meta shaders already use GL_ARB_explicit_attrib_location, so I think it should be okay. Honestly, I'm not sure how the old code worked anyway - we bound the attribute location for "texcoords", while all the shaders capitalized or spelled it differently. v2: Convert another instance in brw_meta_fast_clear.c. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* mesa: Ignore glPointSize when GL_POINT_SIZE_ARRAY_OES is enabledPlamena Manolova2016-03-151-0/+2
| | | | | | | | | | When a user defines a point size array and enables it, the point size value set via glPointSize should be ignored. To achieve this, we can simply toggle ctx->VertexProgram.PointSizeEnabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42187 Signed-off-by: Plamena Manolova <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* st/mesa: set image access flags in st_bind_imagesNicolai Hähnle2016-03-141-0/+15
| | | | | Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* st/glsl_to_tgsi: set FS_EARLY_DEPTH_STENCIL when requiredNicolai Hähnle2016-03-141-0/+3
| | | | | Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* st/glsl_to_tgsi: set memory access type on image intrinsicsNicolai Hähnle2016-03-141-0/+7
| | | | | | | | This is required to preserve the image variable's coherent/restrict/volatile qualifiers in TGSI. Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* st/glsl_to_tgsi: provide Texture and Format information for image opsNicolai Hähnle2016-03-141-9/+15
| | | | | Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* get: reconcile aliasing enums for MaxCombinedShaderOutputResourcesNicolai Hähnle2016-03-142-2/+11
| | | | | | | | | | | The enums MAX_COMBINED_IMAGE_UNITS_AND_FRAGMENT_OUTPUTS and MAX_COMBINED_SHADER_OUTPUT_RESOURCES are equal and should therefore only appear once. Noticed while implementing ARB_shader_image_load_store without previously implementing SSBO. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Restrict inequality that can only hold equal in saturate propagation.Francisco Jerez2016-03-141-1/+1
| | | | | | | | | | Should have no functional change. The IP value of an instruction that reads src_var cannot possibly be after the end of the live interval of the variable it's reading from, by the definition of live interval. Might save future readers a momentary WTF while trying to understand this code. Reviewed-by: Matt Turner <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 14:00:08 +0000