summaryrefslogtreecommitdiffstats
path: root/src/mesa/vbo
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Add support for GL_ARB_base_instanceFredrik Höglund2012-06-195-11/+113
| | | | Reviewed-by: Brian Paul <[email protected]>
* vbo: use software primitive restart in the VBO moduleJordan Justen2012-05-171-6/+37
| | | | | | | | | | When PrimitiveRestartInSoftware is set, the VBO module will handle primitive restart scenarios before calling the vbo->draw_prims drawing function. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* vbo: add software primitive restart supportJordan Justen2012-05-172-0/+239
| | | | | | | | | | | vbo_sw_primitive_restart implements primitive restart in software by splitting primitive draws apart. This is based on similar support in mesa/state_tracker/st_draw.c. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: implement DEBUG_ALWAYS_FLUSH debug optionBrian Paul2012-05-112-0/+20
| | | | | | | | This flag has been around for a while but it wasn't actually used anywhere. Now, setting this flag causes a glFlush() to be issued after each drawing call (including glBegin/End, glDrawElements, glDrawArrays, glDrawPixels, glCopyPixels and glBitmap).
* mesa: fix glMaterial / dlist bugBrian Paul2012-05-113-58/+152
| | | | | | | | | | | | | When glColorMaterial() is used to latch glColor commands to a material attribute, glMaterial calls to change that material should become no-ops. This failed to work properly when the glMaterial call was inside a display list. This removes the Material function from the vbo_attrib_tmp.h template file. We have separate/different implementations for the "save" and "exec" cases now. NOTE: This is a candidate for the 8.0 branch.
* vbo: add some commentsBrian Paul2012-05-082-1/+7
|
* mesa: add gl_context::NewDriverState and use it for vertex arraysMarek Olšák2012-05-087-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The vbo module recomputes its states if _NEW_ARRAY is set, so it shouldn't use the same flag to notify the driver. Since we've run out of bits in NewState and NewState is for core Mesa anyway, we need to find another way. This patch is the first to start decoupling the state flags meant only for core Mesa and those only for drivers. The idea is to have two flag sets: - gl_context::NewState - used by core Mesa only - gl_context::NewDriverState - used by drivers only (the flags are defined by the driver and opaque to core Mesa) It makes perfect sense to use NewState|=_NEW_ARRAY to notify the vbo module that the user changed vertex arrays, and the vbo module in turn sets a driver-specific flag to notify the driver that it should update its vertex array bindings. The driver decides which bits of NewDriverState should be set and stores them in gl_context::DriverFlags. Then, Core Mesa can do this: ctx->NewDriverState |= ctx->DriverFlags.NewArray; This patch implements this behavior and adapts st/mesa. DriverFlags.NewArray is set to ST_NEW_VERTEX_ARRAYS. Core Mesa only sets NewDriverState. It's the driver's responsibility to read it whenever it wants and reset it to 0. Reviewed-by: Brian Paul <[email protected]>
* mesa: move gl_client_array*[] from vbo_draw_func into gl_contextMarek Olšák2012-05-088-17/+43
| | | | | | | | | | | | | | | | | | In the future we'd like to treat vertex arrays as a state and not as a parameter to the draw function. This is the first step towards that goal. Part of the goal is to avoid array re-validation for every draw call. This commit adds: const struct gl_client_array **gl_context::Array::_DrawArrays. The pointer is changed in: * vbo_draw_method * vbo_rebase_prims - unused by gallium * vbo_split_prims - unused by gallium * st_RasterPos Reviewed-by: Brian Paul <[email protected]>
* vbo: move vbo_draw_method into vbo_context.hMarek Olšák2012-05-085-40/+38
| | | | | | I'll need vbo_context in that function soon. Reviewed-by: Brian Paul <[email protected]>
* vbo: call UpdateState directly when notifying a driver about _NEW_ARRAYMarek Olšák2012-04-234-14/+5
| | | | | | | | Core Mesa doesn't need to know about this. This also removes the hack in recalculate_input_bindings. Reviewed-by: Brian Paul <[email protected]>
* vbo: do FLUSH_CURRENT before validating and updating stateMarek Olšák2012-04-231-10/+16
| | | | | | | | | | This fixes an assertion failure since: commit 81afdd20f3f574ce29559d8ad77df5c77652009e vbo: don't check twice whether it's valid to render FLUSH_CURRENT may set _NEW_CURRENT_ATTRIB. Reviewed-by: Brian Paul <[email protected]>
* vbo: remove vbo_context::mat_currvalMarek Olšák2012-04-195-12/+8
| | | | | Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Mathias Fröhlich <[email protected]>
* vbo: remove vbo_context::generic_currvalMarek Olšák2012-04-197-12/+16
| | | | | Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Mathias Fröhlich <[email protected]>
* vbo: remove vbo_context::legacy_currvalMarek Olšák2012-04-197-16/+14
| | | | | | | | | | | | It's not nice when you have several variables pointing to the same array and you wanna ask your editor "where is this used" and you only get an answer for one of the four currval, legacy_currval, generic_currval, mat_currval, which is quite useless, because you never see the whole picture. Let's get rid of the additional pointers. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Mathias Fröhlich <[email protected]>
* vbo: remove unused variables in vbo_contextMarek Olšák2012-04-191-4/+0
| | | | | Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Mathias Fröhlich <[email protected]>
* vbo: don't check twice whether it's valid to renderMarek Olšák2012-04-191-20/+0
| | | | | | | | It's already done in _mesa_validate_Draw* and it's not needed to do it again unless I am missing something. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Mathias Fröhlich <[email protected]>
* mesa: add _NEW_VARYING_VP_INPUTS for gl_context::varying_vp_inputsMarek Olšák2012-04-192-3/+3
| | | | | | | | | This is a frequently-updated state and _NEW_ARRAY already causes revalidation of the vbo module. It's kinda counter-productive to recompute arrays in the vbo module if _NEW_ARRAY is set and then set _NEW_ARRAY again. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Mathias Fröhlich <[email protected]>
* mesa,vbo: properly detect when vertex arrays need to be recalculatedMarek Olšák2012-04-193-39/+25
| | | | | | | | | | | | | | | | | | | This moves the RebindArrays flag into the vbo module, consolidates the code, and adds missing vbo_draw_method calls. Also with this change, the vertex arrays are not needlessly recalculated twice. The issue with the old code was: - If recalculate_input_bindings updates vp_varying_inputs, _NEW_ARRAY is set. - _mesa_update_state is called and the vp_varying_inputs change causes regeneration of the fixed-function shaders, which also sets _NEW_PROGRAM. - The occurence of either _NEW_ARRAY or _NEW_PROGRAM sets the recalculate_inputs flag to TRUE again. - The new code sets the flag to FALSE after the second _mesa_update_state, because there can't possibly be any change which would require recalculating the arrays. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Mathias Fröhlich <[email protected]>
* mesa: Fold error generation into _mesa_valid_prim_mode().Eric Anholt2012-03-191-2/+1
| | | | | | | | | | | | | We want to start emitting an INVALID_OPERATION from here for transform feedback. Note that this forced dlist.c to almost not use this function, since it wants different behavior during dlist compile. Just pull the non-TF, non-GS test out for compile, because: 1) TF doesn't matter in that case because there's no drawing. 2) I don't think we're going to see GSes and display lists in the same context, if we don't do GL_ARB_compatibility. Reviewed-by: Brian Paul <[email protected]>
* mesa/vbo: inline vbo_sizeof_ib_type.Dave Airlie2012-02-282-18/+16
| | | | | | | Can't see any reason this wouldn't be better off as an inline. Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* vbo: Eliminate short-circuiting in invalid-start case.Kenneth Graunke2012-02-171-5/+1
| | | | | | | | | | | Now that we have a index_range_invalid flag, we can just use that rather than calling vbo_validated_drawrangeelements directly and returning. NOTE: This is a candidate for release branches. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* vbo: Rework checking of 'end' against _MaxElement.Kenneth Graunke2012-02-171-11/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | This failed to take basevertex into account: If basevertex < 0: (end + basevertex) might actually be in-bounds while 'end' is not. We would have clamped in this case when we probably shouldn't. This could break application drawing. If basevertex > 0: 'end' might be in-bounds while (end + basevertex) might not. We would have failed to clamp in this place. There's a comment indicating the TNL module depends on max_index being in-bounds; if so, it would likely break horribly. Rather than trying to clamp correctly in the face of basevertex, simply delete the clamping code and indicate that we don't have a valid range. This causes _tnl_vbo_draw_prims to use vbo_get_minmax_indices() to compute the actual bounds, which is much safer. NOTE: This is a candidate for release branches. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* vbo: Ignore invalid element ranges which are outside VBO bounds.Kenneth Graunke2012-02-171-0/+25
| | | | | | | | | | | | | | | | | | | | | | | Some applications, such as Regnum Online, appear to pass invalid start/end values to glDrawRangeElements. In particular, the 'start' index sometimes exceeds the maximum array element. This is clearly invalid behavior, and although the spec isn't clear, seems to result in undefined, implementation-specific behavior. This patch takes the conservative approach and simply ignores the range, while issuing a warning indicating that the application is broken and should be fixed. NOTE: This is a candidate for release branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45214 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44701 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41152 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40361 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28138 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]> [v1] Reviewed-by: Roland Scheidegger <[email protected]>
* vbo: Remove pedantic warning about 'end' beind out of bounds.Kenneth Graunke2012-02-171-47/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The application supplied [start, end] range is merely a conservative hint of the ranges of index values inside the index buffer. There is no requirement that all vertices in the range [start, end] be referenced. Passing an 'end' value larger than the maximum legal index is perfectly acceptible; applications can legally pass 0xffffffff when they don't have a tighter bound readily available. Thus, the warning doesn't indicate a correctness issue; it could only indicate a performance issue. However, it does not even do that. glDrawRangeElements is designed to optimize non-VBO vertex data uploads by providing an upper bound on the size of buffers a driver would need to allocate. With VBOs, the data is already in an uploaded buffer, so the range doesn't help. The clincher is: we only know _MaxElement for VBOs. For user-space arrays, we just set it to 2,000,000,000 (see mesa/main/varray.h:63.) So we can only check this in the case where it is not useful. Many applications, including the Unigine demos, currently trigger this warning, which suggests the applications are buggy when they're actually fine. Eliminating the warning should confuse users less while not actually losing any benefit to application developers. NOTE: This is a candidate for release branches. Suggested-by: Jose Fonseca <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* vbo: unmap vertex store before executing listsBrian Paul2012-02-093-12/+40
| | | | | | | | | We don't want our VBOs mapped when we're drawing. This change checks if the vertex store VBO is mapped before we execute a list, unmaps it, then remaps it after drawing. This situation pops up when building a nested display list in GL_COMPILE_AND_EXECUTE mode. Reviewed-by: Eric Anholt <[email protected]>
* vbo: fix a building errorChih-Wei Huang2012-02-041-0/+2
| | | | | | Signed-off-by: Marek Olšák <[email protected]> NOTE: This is a candidate for the 8.0 branch.
* vbo: fix node_attrsz[] usage in vbo_bind_vertex_list()Brian Paul2012-02-011-2/+2
| | | | | | | | | | | | | The node_attrsz[] array is initially copied from the node->attrsz[] array but some values get rewritten. Thereafter, we need to use the node_attrsz[] values. Fixes a bug when replaying a display list that uses generic vertex array[16] (at least). NOTE: This is a candidate for the 8.0 branch. Reviewed-by: Ian Romanick <[email protected]>
* vbo: fix breakage from previous commitBrian Paul2012-01-111-1/+1
| | | | Don't know how that slipped by.
* vbo: fix void * arithmetic compilation error on MSVCBrian Paul2012-01-111-4/+5
| | | | | Also, call vbo_sizeof_ib_type() once and fix argument cast in MapBufferRange() call.
* vbo: introduce vbo_get_minmax_indices functionYuanhan Liu2012-01-122-11/+45
| | | | | | | | | | | | | | | | | | | | | | | Introduce vbo_get_minmax_indices() function to handle the min/max index computation for nr_prims(>= 1). The old code just compute the first prim's min/max index; this would results an error rendering if user called functions like glMultiDrawElements(). This patch servers as fixing this issue. As when nr_prims = 1, we can pass 1 to paramter nr_prims, thus I made vbo_get_minmax_index() static. v2: per Roland's suggestion, put the indices address compuation into vbo_get_minmax_index() instead. Also do comination if possible to reduce map/unmap count v3: per Brian's suggestion, use a pointer for start_prim to avoid structure copy per loop. Signed-off-by: Yuanhan Liu <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* vbo: introduce vbo_sizeof_ib_type() functionYuanhan Liu2011-12-302-33/+23
| | | | | | | | | | introduce vbo_sizeof_ib_type() function to return the index data type size. I see some place use switch(ib->type) to get the index data type, which is sort of duplicate. Signed-off-by: Yuanhan Liu <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* vbo: Clean up recalculate_input_bindings.Mathias Fröhlich2011-12-272-46/+17
| | | | | | | | | Now the gl_array_object's layout matches the one used in recalculate_input_bindings. Make use of this and remove the bind_array_obj function. Signed-off-by: Mathias Froehlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* vbo: signal _NEW_ARRAY when transitioning between glBegin/End, glDrawArraysBrian Paul2011-12-265-7/+49
| | | | | | | | | | | | | | | | | | | | | This fixes a regression seen with the isosurf demo when switching between glBegin/End and glDrawArrays (do it several times). The problem was the driver wasn't getting _NEW_ARRAY when the arrays were subtly changed: (vertex3f, normal3f) vs. (normal3f, vertex3f). This patch fixes that by signaling _NEW_ARRAY whenever we transition between glBegin/End and glDrawArrays mode and display lists. The patch also fixes up the initialization of the map_vp_none[] array to stop putting strange values in the last five elements of the array. v2: remove DRAW_ELEMENTS, don't distinguish between glDrawArrays and glDrawElements v3: add DRAW_DISPLAY_LIST for the display list case, just to be safe. Reviewed-by: Mathias Froehlich <[email protected]> Tested-by: Mathias Froehlich <[email protected]>
* mesa: Add count_tessellated_primitives() function.Paul Berry2011-12-202-0/+51
| | | | | | | | | | | This function computes the number of primitives that will be generated when the given drawing operation is performed. It accounts for the tessellation that is performed on line strips, line loops, triangle strips, triangle fans, quads, quad strips, and polygons, so it is suitable for implementing the primitive counters needed by transform feedback. Reviewed-by: Kenneth Graunke <[email protected]>
* vbo: add comment for map_vp_non[] arrayBrian Paul2011-12-161-0/+1
|
* mesa: implement DrawTransformFeedback from ARB_transform_feedback2Marek Olšák2011-12-158-11/+112
| | | | | | | | | | | | | | It's like DrawArrays, but the count is taken from a transform feedback object. This removes DrawTransformFeedback from dd_function_table and adds the same function to GLvertexformat (with the function parameters matching GL). The vbo_draw_func callback has a new parameter "struct gl_transform_feedback_object *tfb_vertcount". The rest of the code just validates states and forwards the transform feedback object into vbo_draw_func.
* vbo: remove unreachable _mesa_error() callBrian Paul2011-12-021-3/+0
| | | | | | | If mode is not GL_POINT/LINE/FILL we'll have already reported the error earlier in the function and returned so we can never get here. Reviewed-by: José Fonseca <[email protected]>
* mesa: Use VERT_ATTRIB_* indexed array in gl_array_object.Mathias Fröhlich2011-11-292-65/+35
| | | | | | | | | | | | Replace the distinct struct gl_client_array members in gl_array_object by an array of gl_client_arrays indexed by VERT_ATTRIB_*. Renumber the vertex attributes slightly to keep the old semantics of the distinct array members. Make use of the upper 32 bits in VERT_BIT_*. Update all occurances of the distinct struct members with the array equivalents. Signed-off-by: Mathias Froehlich <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Make gl_program::InputsRead 64 bits.Mathias Fröhlich2011-11-293-4/+4
| | | | | | | | | Make gl_program::InputsRead a 64 bits bitfield. Adapt the intel and radeon driver to handle a 64 bits InputsRead value. Signed-off-by: Mathias Froehlich <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* vbo: Use The VERT_{ATTRIB,BIT} defines.Mathias Fröhlich2011-11-297-70/+87
| | | | | | Signed-off-by: Mathias Froehlich <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: move ElementArrayBufferObj to gl_array_objectYuanhan Liu2011-11-292-23/+23
| | | | | | | | | | | | | | | According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at page 515, the element buffer object is listed in vertex array object. So, move the ElementArrayBufferObj inside gl_array_object to make element buffer object per-vao. This would fix most of(3 left) intel oglc vao test fail NOTE: this is a candidate for the 7.11 branch. Signed-off-by: Yuanhan Liu <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* vbo: fix !FEATURE_beginend buildChia-I Wu2011-11-251-0/+6
| | | | Fix a build error in GLES-only build.
* vbo: better handling of VBO allocation failuresBrian Paul2011-11-115-39/+125
| | | | | | | | | | | Previously, if we failed to allocate a VBO (either for display list compilation or immediate mode rendering) we'd eventually segfault when trying to map the non-existant buffer or in a glVertex/Color/etc call when we hit a null pointer. Now we don't try to map non-existant buffers and if we do fail to allocate a VBO we plug in no-op functions for glVertex/Color/etc so we don't segfault.
* mesa: replace api_noop.[ch] with vbo_noop.[ch]Brian Paul2011-11-112-0/+564
| | | | | | None of the code in api_noop.c was used anymore. The new vbo_noop.c functions are true no-ops. They'll be used to no-op glBegin/End functions when we run out of VBO memory.
* vbo: pull some code from api_noop.c into vbo moduleBrian Paul2011-11-112-16/+208
| | | | | | Only a handful of functions from api_noop.c are actually used by the VBO module. Move them to the VBO module. With this change, none of the code in api_noop.c is actually used anymore.
* mesa: Set the "Integer" field of gl_client_array properly.Paul Berry2011-11-021-0/+1
| | | | | | | | | | | This patch ensures that gl_client_array::Integer is properly set to GL_TRUE for vertex attributes specified using glVertexAttribIPointer, and to GL_FALSE for vertex attributes specified using glVertexAttribPointer, so that the vertex attributes can be interpreted properly by driver back-ends. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* vbo: Clean up unused variables in the vbo module.Mathias Froehlich2011-10-223-16/+1
| | | | | Remove some unused or unused but set variables from the vbo module.
* vbo: Redeclare bind_array() as non-static vbo_bind_array()Chad Versace2011-10-182-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is necessary because i965 will need to call vbo_bind_array() when cleaning up after a buffer resolve meta-op. Detailed Explanation -------------------- The vbo module tracks vertex attributes separately from the gl_context. Specifically, the vbo module maintins vertex attributes in vbo_exec_context::array::inputs, which is synchronized with gl_context::Array::ArrayObj::VertexAttrib by vbo_bind_array(). vbo_draw_arrays() calls vbo_bind_array() to perform the synchronization before calling the real draw call, vbo_context::draw_arrays. Intel hardware accomplishes buffer resolves with a meta-op. Frequently, that meta-op must be performed within glDraw* in the moment immediately before the draw occurs (The hardware designers hate us...). After performing the meta-op, but before calling vbo_bind_array(), the gl_context's vertex attributes will have been restored to their original state (that is, their state before the meta-op began), but the vbo module's vertex attribute are those used in the last meta-op. Therefore we must manually synchronize the two with vbo_bind_array() before continuing with the original draw command (that is, the one requested with glDraw*). See brw_predraw_resolve_buffers(), which will be added in a future commit. Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* mesa: Add dd_function_table::PrepareExecBeginChad Versace2011-10-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This hook allows the driver to prepare for a glBegin/glEnd. i965 will use the hook to avoid avoid recursive calls to FLUSH_VERTICES during a buffer resolve meta-op. Detailed Justification ---------------------- When vertices are queued during a glBegin/glEnd block, those vertices must of course be drawn before any rendering state changes. To enusure this, Mesa calls FLUSH_VERTICES as a prehook to such state changes. Therefore, FLUSH_VERTICES itself cannot change rendering state without falling into a recursive trap. This precludes meta-ops, namely i965 buffer resolves, from occuring while any vertices are queued. To avoid that situation, i965 must satisfy the following condition: that it queues no vertex if a buffer needs resolving. To satisfy this, i965 will use the PrepareExecBegin hook to resolve all buffers on entering a glBegin/glEnd block. -------- v2: Don't add dd_function_table::CleanupExecEnd. Anholt and I discovered that hook to be unnecessary. Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* mesa/vbo: Treat attribute 0 and vertex as the sameIan Romanick2011-10-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is supported by the pseudo-code on pages 27 and 28 (pages 41 and 42 of the PDF) of the OpenGL 2.1 spec. The last part of the implementation of ArrayElement is: if (generic attribute array 0 enabled) { if (generic vertex attribute 0 array normalization flag is set, and type is not FLOAT or DOUBLE) VertexAttrib[size]N[type]v(0, generic vertex attribute 0 array element i); else VertexAttrib[size][type]v(0, generic vertex attribute 0 array element i); } else if (vertex array enabled) { Vertex[size][type]v(vertex array element i); } Page 23 (page 37 of the PDF) of the same spec says: "Setting generic vertex attribute zero specifies a vertex; the four vertex coordinates are taken from the values of attribute zero. A Vertex2, Vertex3, or Vertex4 command is completely equivalent to the corresponding VertexAttrib* command with an index of zero." Fixes piglit test attribute0. NOTE: This is a candidate for stable branches. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 03:41:21 +0000