summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Delete VAO _MaxElement code and index buffer bounds checking.Kenneth Graunke2014-09-1915-206/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fredrik's implementation of ARB_vertex_attrib_binding introduced new gl_vertex_attrib_array and gl_vertex_buffer_binding structures, and converted Mesa's older gl_client_array to be derived state. Ultimately, we'd like to drop gl_client_array and use those structures directly. One hitch is that gl_client_array::_MaxElement doesn't correspond to either structure (unlike every other field), so we'd have to figure out where to store it. The _MaxElement computation uses values from both structures, so it doesn't really belong in either place. We could put it in the VAO, but we'd have to pass it around everywhere. It turns out that it's only used when ctx->Const.CheckArrayBounds is set, which is only set by the (rarely used) classic swrast driver. It appears that drivers/x11 used to set it as well, which was intended to avoid segmentation faults on out-of-bounds memory access in the X server (probably for indirect GLX clients). However, ajax deleted that code in 2010 (commit 1ccef926be46dce3b6b5c76e812e2fae4e205ce7). The bounds checking apparently doesn't actually work, either. Non-VBO attributes arbitrarily set _MaxElement to 2 * 1000 * 1000 * 1000. vbo_save_draw and vbo_exec_draw remark /* ??? */ when setting it, and the i965 code contains a comment noting that _MaxElement is often bogus. Given that the code is complex, rarely used, and dubiously functional, it doesn't seem worth maintaining going forward. This patch drops it. This will probably mean the classic swrast driver may begin crashing on out of bounds vertex buffer access in some cases, but I believe that is allowed by OpenGL (and probably happened for non-VBO accesses anyway). There do not appear to be any Piglit regressions, either. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Acked-by: Roland Scheidegger <[email protected]>
* mesa: fix prog_optimize.c assertions triggered by SWZ opcodeBrian Paul2014-09-181-5/+4
| | | | | | | | | | | | | The SWZ instruction can have swizzle terms >4 (SWIZZLE_ZERO, SWIZZLE_ONE). These swizzle terms caused a few assertions to fail. This started happening after the commit "mesa: Actually use the Mesa IR optimizer for ARB programs." when replaying some apitrace files. A new piglit test (tests/asmparsertest/shaders/ARBfp1.0/swz-08.txt) exercises this. Cc: "10.3" <[email protected]> Reviewed-by: Charmaine Lee <[email protected]>
* st/mesa: Fix handling of 8888 SNORM and SRGB formats for big-endianRichard Sandiford2014-09-171-16/+36
| | | | | | | | | | | MESA_FORMAT_x8y8z8w8 puts the x channel in the least significant part of the containing 32-bit integer, which is equivalent to PIPE_FORMAT_xyzw8888. PIPE_FORMAT_x8y8z8w8 puts the x channel first in memory. This patch fixes up the mesa<->gallium mapping accordingly. Signed-off-by: Richard Sandiford <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* st/mesa: Fix handling of LA and RG formats for big-endianRichard Sandiford2014-09-171-16/+48
| | | | | | | | | | | | MESA_FORMAT_LnAn puts the luminance in the least significant part of the containing integer, which is equivalent to PIPE_FORMAT_LAnn. PIPE_FORMAT_LnAn puts the luminance first in memory. This patch fixes up the mesa<->gallium mapping accordingly. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* mesa: Add MESA_FORMAT_{A8R8G8B8, X8R8G8B8, X8B8G8R8}_SRGB (v2)Richard Sandiford2014-09-179-0/+164
| | | | | | | | | | | | This means that each 8888 SRGB format has a reversed counterpart, which is necessary for handling big-endian mesa<->gallium mappings. v2: fix missing i965 additions. (Jason) fix 127->255 max alpha for SRGB formats. (Jason) v1: Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Richard Sandiford <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* mesa: Add MESA_FORMAT_A8L8_{SNORM,SRGB}Richard Sandiford2014-09-179-0/+111
| | | | | | | | | | | | | The associated UNORM format already existed. This means that each LnAn format has a reversed counterpart, which is necessary for handling big-endian mesa<->gallium mappings. [airlied: rebased onto current master] Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* mesa: fix SRGB alpha channel value in pack_float_R8G8B8X8_SRGBDave Airlie2014-09-171-1/+1
| | | | | | | | | Jason pointed out the bug on review adding new formats, but the existing format also appears to have the bug, so use 255 as the max, these are SRGB no SNORM. Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* swrast: Fix handling of MESA_FORMAT_L8A8_SRGB for big-endianRichard Sandiford2014-09-171-3/+3
| | | | | | | | | | | | Luminance is the least-significant byte of the uint16, rather than the lowest byte in memory. Other parts of mesa already handle this correctly for big-endian, and swrast already handles other MESA_FORMAT_x8y8 formats correctly. This case was just an odd-one-out. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Brian Paul <[email protected]> Cc: <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* mesa: Tweak unpack name for MESA_FORMAT_R8G8B8X8_SNORMRichard Sandiford2014-09-171-2/+2
| | | | | | | | | | | MESA_FORMAT_R8G8B8X8_SNORM used a function called unpack_X8B8G8R8_SNORM while MESA_FORMAT_R8G8B8X8_SRGB used a function called unpack_R8G8B8X8_SRGB. This patch renames the SNORM function to have the same order as the MESA_FORMAT name, like the SRGB function does. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* mesa: Fix alpha component in unpack_R8G8B8X8_SRGB.Richard Sandiford2014-09-171-1/+1
| | | | | | | | | | | The function was using the "X" component as the alpha channel, rather than setting alpha to 1.0. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Cc: <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* util: move shared rgtc code to util (v2)Dave Airlie2014-09-172-478/+19
| | | | | | | | | | | This was being shared using a ../../ get out of gallium into mesa, and I swore when I did it I'd fix things when we got a util dir, we did, so I have. v2: move RGTC_DEBUG define Reviewed-by: Jason Ekstrand <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* i965/vec4: slightly improve insn dumping with no srcsChris Forbes2014-09-171-1/+4
| | | | | | | Previously, we would get a trailing ', ' which looked strange. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: add support for RGBA dma_buf imports.Gwenole Beauchesne2014-09-161-0/+6
| | | | | | | | | This allows for importing foreign buffers in RGB32 native endian byte order, i.e. DRM_FORMAT_XBGR8888, and DRM_FORMAT_ABGR8888. Signed-off-by: Gwenole Beauchesne <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Cc: "10.3" <[email protected]>
* i965: Mark delta_x/y as BAD_FILE if remapped away completely.Kenneth Graunke2014-09-162-5/+15
| | | | | | | | | | | | | | | | | | | | | | | Commit afe3d1556f6b77031f7025309511a0eea2a3e8df (i965: Stop doing remapping of "special" regs.) stopped remapping delta_x/delta_y, and additionally stopped considering them always-live. We later realized delta_x was used in register allocaiton, so we actually needed to remap it, which was fixed in commit 23d782067ae834ad53522b46638ea21c62e94ca3 (i965/fs: Keep track of the register that hold delta_x/delta_y.). However, that commit didn't restore the "always consider it live" part. If all the code using delta_x was eliminated, fs_visitor::delta_x would be left pointing at its old register number. Later code in register allocation would handle that register number specially...even though it wasn't actually delta_x. To combat this, set delta_x/y to BAD_FILE if they're eliminated, and check for that. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83127 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Cc: "10.3" <[email protected]>
* st_glsl_to_tgsi: init have_sqrt field.Dave Airlie2014-09-161-0/+1
| | | | | | Coverity reported this. Signed-off-by: Dave Airlie <[email protected]>
* mesa: move i, j var decls into SWIZZLE_CONVERT_LOOP() macroBrian Paul2014-09-151-36/+38
| | | | | | | Put macro code in do {} while loop and put semicolons on macro calls so auto indentation works properly. Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: break up _mesa_swizzle_and_convert() to reduce compile timeBrian Paul2014-09-151-480/+550
| | | | | | | This reduces gcc -O3 compile time to 1/4 of what it was on my system. Reduces MSVC release build time too. Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: check that uniform exists in glUniform* functionsTapani Pälli2014-09-151-8/+8
| | | | | | | | | | | | | Remap table for uniforms may contain empty entries when using explicit uniform locations. If no active/inactive variable exists with given location, remap table contains NULL. v2: move remap table bounds check before existence check (Ian Romanick) Signed-off-by: Tapani Pälli <[email protected]> Tested-by: Erik Faye-Lund <[email protected]> (v1) Reviewed-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83574
* nouveau: check for mesa context init failureIlia Mirkin2014-09-131-2/+2
| | | | | | Reported by Coverity Signed-off-by: Ilia Mirkin <[email protected]>
* nouveau: avoid leaking screen on initialization failIlia Mirkin2014-09-131-2/+5
| | | | | | Reported by Coverity Signed-off-by: Ilia Mirkin <[email protected]>
* nouveau: change internal variables to avoid conflicts with macro argsIlia Mirkin2014-09-131-10/+10
| | | | | | | Reported by Coverity Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.2 10.3" <[email protected]>
* i965/vec4: Make type_size() return 0 for samplers.Kenneth Graunke2014-09-121-3/+3
| | | | | | | | | | | | | | The FS backend has always used 0, and the VS backend has always used 1. I think 1 is just working around other problems, and is incorrect. Samplers are baked in; nothing uses the UNIFORM register we would create, and we shouldn't upload any constant values for them. Fixes ES3-CTS.shaders.struct.uniform.sampler_array_vertex. Signed-off-by: Kenneth Graunke <[email protected]> Cc: [email protected] Reviewed-by: Ian Romanick <[email protected]> Tested-by: Ian Romanick <[email protected]>
* i965: Skip allocating UNIFORM file storage for uniforms of size 0.Kenneth Graunke2014-09-122-6/+6
| | | | | | | | | | | | | | | | | | | | | Samplers take up zero slots and therefore don't exist in the params array, nor are they included in stage_prog_data->nr_params. There's no need to store their size in param_size, as it's only used for dealing with arrays of "real" uniforms (ones uploaded as shader constants). We run into all kinds of problems trying to refer to the uniform storage for variables that don't have uniform storage. For one, we may use some other variable's index, or access out of bounds in arrays. In the FS backend, our extra 2 * MaxSamplerImageUnits params for texture rectangle rescaling paper over a lot of problems. In the VS backend, we claim samplers take up a slot, which also papers over problems. Instead, just skip allocating storage for variables that don't have any. Signed-off-by: Kenneth Graunke <[email protected]> Cc: [email protected] Reviewed-by: Ian Romanick <[email protected]> Tested-by: Ian Romanick <[email protected]>
* i965: Separate gl_InstanceID and gl_VertexID uploading.Kenneth Graunke2014-09-125-16/+42
| | | | | | | | | | | | | | | | We always uploaded them together, mostly out of laziness - both required an additional vertex element. However, gl_VertexID now also requires an additional vertex buffer for storing gl_BaseVertex; for non-indirect draws this also means uploading (a small amount of) data. This is extra overhead we don't need if the shader only uses gl_InstanceID. In particular, our clear shaders currently use gl_InstanceID for doing layered clears, but don't need gl_VertexID. Signed-off-by: Kenneth Graunke <[email protected]> Cc: "10.3" <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Tested-by: Ian Romanick <[email protected]>
* i965: Fix reference counting in new basevertex upload code.Kenneth Graunke2014-09-121-0/+3
| | | | | | | | | | | | | | | | | | | | In the non-indirect draw case, we call intel_upload_data to upload gl_BaseVertex. It makes brw->draw.draw_params_bo point to the upload buffer, and increments the upload BO reference count. So, we need to unreference it when making brw->draw.draw_params_bo point at something else, or else we'll retain a reference to stale upload buffers and hold on to them forever. This also means that the indirect case should increment the reference count on the indirect draw buffer when making brw->draw.draw_params_bo point at it. That way, both paths increment the reference count, so we can safely unreference it every time. Signed-off-by: Kenneth Graunke <[email protected]> Cc: "10.3" <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Tested-by: Ian Romanick <[email protected]>
* mesa: fix _mesa_free_pipeline_data() use-after-free bugBrian Paul2014-09-121-2/+2
| | | | | | | | | | | | | Unreference the ctx->_Shader object before we delete all the pipeline objects in the hash table. Before, ctx->_Shader could point to freed memory when _mesa_reference_pipeline_object(ctx, &ctx->_Shader, NULL) was called. Fixes crash when exiting the piglit rendezvous_by_location test on Windows. Cc: [email protected] Reviewed-by: Ian Romanick <[email protected]>
* ra: assert against unsigned underflow in q_totalConnor Abbott2014-09-121-0/+1
| | | | | | | | q_total should never go below 0 (which is why it's defined as unsigned), and if it does, then something is seriously wrong. Signed-off-by: Connor Abbott <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* ra: note a restriction in the interfence graph APIConnor Abbott2014-09-121-1/+4
| | | | | | | | | As noted in the previous commit, this was introduced in 567e2769b81863b6dffdac3826a6b729ce6ea37c ("ra: make the p, q test more efficient"), but I forgot to mention it. Signed-off-by: Connor Abbott <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa/st: add ARB_texture_view supportIlia Mirkin2014-09-126-18/+105
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* nouveau: only enable stencil func if the visual has stencil bitsIlia Mirkin2014-09-122-2/+2
| | | | | | | The _Enabled property already has the relevant information. Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.2 10.3" <[email protected]>
* nouveau: only enable the depth test if there actually is a depth bufferIlia Mirkin2014-09-125-4/+9
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.2 10.3" <[email protected]>
* i965/vec4: Only examine virtual_grf_end for GRF sourcesIan Romanick2014-09-111-8/+12
| | | | | | | | | | | | | If the source is not a GRF, it could have a register >= virtual_grf_count. Accessing virtual_grf_end with such a register would lead to out-of-bounds access. Make sure the source is a GRF before accessing virtual_grf_end. Fixes Valgrind complaints while compiling some shaders. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: [email protected]
* st/mesa: handle failed context creation for core profileBrian Paul2014-09-112-34/+53
| | | | | | | | | | | | If the glx/wgl state tracker requested a core profile but the gallium driver did not support some feature of GL 3.1 or later, we were setting ctx->Version=0 and then failing the assertion in _mesa_initialize_exec_table(). With this change we check for ctx->Version=0 and tear down the context and return NULL from st_create_context(). Reviewed-by: Marek Olšák <[email protected]>
* i965: Implement GL_PRIMITIVES_GENERATED with non-zero streams.Iago Toral Quiroga2014-09-111-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far we have been using CL_INVOCATION_COUNT to resolve this query but this is no good with streams, as only stream 0 reaches the clipping stage. From ARB_transform_feedback3: "When a generated primitive query for a vertex stream is active, the primitives-generated count is incremented every time a primitive emitted to that stream reaches the Discarding Rasterization stage (see Section 3.x) right before rasterization. This counter is incremented whether or not transform feedback is active." Unfortunately, we don't have any registers that provide the number of primitives written to a specific stream other than the ones that track the number of primitives written to transform feedback in the SOL stage, so we can't implement this exactly as specified. In the past we implemented this feature by activating the SOL unit even if transform feeback was disabled, but making it so that all buffers were disabled and it only recorded statistics, which gave us the right semantics (see 3178d2474ae5bdd1102fb3d76a60d1d63c961ff5). Unfortunately, this came with a significant performance impact and had to be reverted. This new take does not intend to implement the exact semantics required by the spec, but improves what we have now, since now we return the primitive count for stream 0 in all cases. With this patch we use GEN7_SO_PRIM_STORAGE_NEEDED to resolve GL_PRIMITIVES_GENERATED queries for non-zero streams. This would return the number of primitives written to transform feedback for each stream instead. Since non-zero streams are only useful in combination with transform feedback this should not be too bad, and the only case that I think we would not be supporting would be the one in which we want to use both GL_PRIMITIVES_GENERATED and GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN on the same non-zero stream to detect buffer overflow. This patch also fixes the following piglit test: arb_gpu_shader5-xfb-streams-without-invocations This test uses both GL_PRIMITIVES_GENERATED and GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries on non-zero streams, but it does never hit the overflow case, so both queries are always expected to return the same value. Reviewed-by: Kenneth Graunke <[email protected]> Cc: "10.3" <[email protected]>
* mesa: fix UNCLAMPED_FLOAT_TO_UBYTE() macro for MSVCBrian Paul2014-09-101-4/+4
| | | | | | | | | | MSVC replaces the "F" in "255.0F" with the macro argument which leads to an error. s/F/FLT/ to avoid that. It turns out we weren't using this macro at all on MSVC until the recent "mesa: Drop USE_IEEE define." change. Reviewed-by: Roland Scheidegger <[email protected]>
* mesa: trim down some #includesBrian Paul2014-09-107-12/+2
|
* i965: Disable guardband clipping in the smaller-than-viewport case.Kenneth Graunke2014-09-101-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | Apparently guardband clipping doesn't work like we thought: objects entirely outside fthe guardband are trivially rejected, regardless of their relation to the viewport. Normally, the guardband is larger than the viewport, so this is not a problem. However, when the viewport is larger than the guardband, this means that we would discard primitives which were wholly outside of the guardband, but still visible. We always program the guardband to 8K x 8K to enforce the restriction that the screenspace bounding box of a single triangle must be no more than 8K x 8K. So, if the viewport is larger than that, we need to disable guardband clipping. Fixes ES3 conformance tests: - framebuffer_blit_functionality_negative_height_blit - framebuffer_blit_functionality_negative_width_blit - framebuffer_blit_functionality_negative_dimensions_blit - framebuffer_blit_functionality_magnifying_blit - framebuffer_blit_functionality_multisampled_to_singlesampled_blit v2: Mention the acronym expansion for TA/TR/MC in the comments. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* i965: Request lowering gl_VertexIDIan Romanick2014-09-101-0/+1
| | | | | | | | | | | | | Fixes the (new) piglit tests gles-3.0-drawarrays-vertexid, gl-3.0-multidrawarrays-vertexid, and gl-3.2-basevertex-vertexid. Fixes gles3conform failure in: ES3-CTS.gtf.GL3Tests.transform_feedback.transform_feedback_vertex_id Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80247 Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Expose gl_BaseVertex via a vertex attribute.Kenneth Graunke2014-09-103-20/+65
| | | | | | | | | | | | | | | | | | | Now that we have the data available, we need to expose it to the shaders. We can reuse the same vertex element that we use for gl_VertexID, but we need to back it by an actual vertex buffer. A hardware restriction requires that vertex attributes coming from a buffer (STORE_SRC) must come before any other types (i.e. STORE_0). So, we have to make gl_BaseVertex be the .x component of the vertex attribute. This means moving gl_VertexID to a different component. I chose to move gl_VertexID and gl_InstanceID to the .z and .w components, respectively, to make room for gl_BaseInstance in the .y component (which would also come from a buffer, and therefore be STORE_SRC). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Refactor Gen4-7 VERTEX_BUFFER_STATE emission into a helper.Kenneth Graunke2014-09-101-30/+47
| | | | | | | | | We'll need to emit another VERTEX_BUFFER_STATE for gl_BaseVertex; pulling this into a helper function will save us from having to deal with cross-generation differences in that code. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Make gl_BaseVertex available in a buffer object.Kenneth Graunke2014-09-103-0/+31
| | | | | | | | | | | This will be used for GL_ARB_shader_draw_parameters, as well as fixing gl_VertexID, which is supposed to include gl_BaseVertex's value. For indirect draws, we simply point at the indirect buffer; for normal draws, we upload the value via the upload buffer. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Calculate start/base_vertex_location after preparing vertices.Kenneth Graunke2014-09-106-12/+34
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Handle SYSTEM_VALUE_VERTEX_ID_ZERO_BASEIan Romanick2014-09-101-0/+1
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Fix glGetActiveAttribute for gl_VertexID when lowered.Kenneth Graunke2014-09-101-1/+13
| | | | | | | | | | | | | The lower_vertex_id pass converts uses of the gl_VertexID system value to the gl_BaseVertex and gl_VertexIDMESA system values. Since gl_VertexID is no longer accessed, it would not be considered active. Of course, it should be, since the shader uses gl_VertexID. v2: Move the var->name dereference past the var != NULL check. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: Replace string comparisons with SYSTEM_VALUE enum checks.Kenneth Graunke2014-09-101-2/+2
| | | | | | | This is more efficient. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Add a lowering pass for gl_VertexIDIan Romanick2014-09-102-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | Converts gl_VertexID to (gl_VertexIDMESA + gl_BaseVertex). gl_VertexIDMESA is backed by SYSTEM_VALUE_VERTEX_ID_ZERO_BASE, and gl_BaseVertex is backed by SYSTEM_VALUE_BASE_VERTEX. v2: Put the enum in struct gl_constants and propoerly resolve the scope in C++ code. Fix suggested by Marek. v3: Reabase on Matt's foreach_in_list changes (was using foreach_list). v4 (Ken): Use a systemvalue instead of a uniform because STATE_BASE_VERTEX has been removed. v5: Use a boolean to select lowering, and only allow one lowering method. Suggested by Ken. v6 (Ken): Replace strcmp against literal "gl_BaseVertex"/"gl_VertexID" with SYSTEM_VALUE enum checks, for efficiency. v7: Rebase on context constant initialization work. Signed-off-by: Ian Romanick <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* mesa: Add SYSTEM_VALUE_BASE_VERTEXIan Romanick2014-09-102-1/+15
| | | | | | | | | This system value represents the basevertex value passed to glDrawElementsBaseVertex and related functions. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa: Add SYSTEM_VALUE_VERTEX_ID_ZERO_BASEIan Romanick2014-09-102-0/+13
| | | | | | | | | | | | There exists hardware, such as i965, that does not implement the OpenGL semantic for gl_VertexID. Instead, that hardware does not include the value of basevertex in the gl_VertexID value. SYSTEM_VALUE_VERTEX_ID_ZERO_BASE is the system value that represents this semantic. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa: Document SYSTEM_VALUE_VERTEX_ID and SYSTEM_VALUE_INSTANCE_IDIan Romanick2014-09-101-0/+57
| | | | | | | | | v2: Additions to the documentation for SYSTEM_VALUE_VERTEX_ID. Quote the GL_ARB_shader_draw_parameters spec and mention DirectX SV_VertexID. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* ir_to_mesa: Stop converting uniform booleans.Kenneth Graunke2014-09-091-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Excess conversions considered harmful. Recently Matt reworked the boolean uniform handling to use the value of UniformBooleanTrue, rather than integer 1, when uploading uniforms: mesa: Upload boolean uniforms using UniformBooleanTrue. glsl: Use UniformBooleanTrue value for uniform initializers. Marek then set the default to 1.0f for drivers without native integer support: mesa: set UniformBooleanTrue = 1.0f by default However, ir_to_mesa was assuming a value of integer 1, and arranging for it to be converted to 1.0f on upload. Since Marek's commit, we were uploading 1.0f = 0x3f800000 which was being interpreted as the integer value 1065353216 and converted to float as 1.06535322E9, which broke assumptions in ir_to_mesa that "true" was exactly 1.0f. +13 Piglits on classic swrast (fs-bool-less-compare-true, {vs,fs}-op-not-bool-using-if, glsl-1.20/execution/uniform-initializer). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83573 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 16:34:33 +0000