summaryrefslogtreecommitdiffstats
path: root/src/mesa/vbo
Commit message (Collapse)AuthorAgeFilesLines
* 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]>
* Revert "vbo: Don't discount stride == 0 for testing all varyings in VBOs."Eric Anholt2011-10-011-1/+2
| | | | | | | | | | | | | | | | | This reverts commit d631c19db47181129811080bfa772b210d762d4d. The commit was broken, and ended up returning false all the time because nobody in the world binds every single possible vertex array. On further reflection, we don't want to discount stride == 0: This function is just used for deciding to calculate whether to compute the bonuds on the index, and there's no sense in computing index bounds when stride == 0. For the separate question of "how much data do I upload for this vertex element?", the i965 driver was fixed to upload the data. Fixes a regression of about 2x in 3DMMES, and most importantly, makes Hammerfight playable.
* mesa: s/INLINE/inline/Brian Paul2011-10-014-12/+12
| | | | | | | INLINE is still seen in some files (some generated files, etc) but this is a good start. Acked-by: Kenneth Graunke <[email protected]>
* mesa: check glBegin()/glDrawArrays()/etc mode with _mesa_valid_prim_mode()Brian Paul2011-09-211-0/+7
| | | | | | | | | We now raise an GL_INVALID_ENUM in glBegin() if mode is illegal, as was done in Yuanhan Liu's original patch. Take geometry shaders support into account too. Reviewed-by: Yuanhan Liu <[email protected]>
* mesa: fix error handling for glMaterial*Yuanhan Liu2011-09-201-1/+12
| | | | | | | | | | | | | | | Trigger GL_INVALID_ENUM error if the face paramter is not a valid value. Trigger GL_INVALID_VALUE error if the GL_SHININESS value is out side [0, ctx->Constant.MaxShiniess]. v2: fix the max shininess value. v3: suggested by Brian, move the face check into glMaterialfv function to reduce code duplicate. Also, refactor the error message. Signed-off-by: Yuanhan Liu <[email protected]> Signed-off-by: Brian Paul <[email protected]>
* mesa/vbo: s/inline/INLINE/Vinson Lee2011-09-061-6/+6
| | | | MSVC does not support inline keyword.
* mesa/vbo: add ARB_vertex_type_2_10_10_10_rev APIs.Dave Airlie2011-09-063-2/+490
| | | | | | | | | | | | | | | This adds the vertex processing paths for the 2101010 types. It converts the attributes to floats for all the immediate entry points, some entrypoints are normalised and the attrib APIs take a normalized parameter. There are four main paths, ui10 -> float unnormalized i10 -> float unnormalized ui10 -> float normalized i10 -> float normalized along with the ui2/i2 equivs. Signed-off-by: Dave Airlie <[email protected]>
* mesa/tnl_dd: Remove unused header file t_dd_rendertmp.hIan Romanick2011-08-261-2/+1
| | | | | | | | | | Acked-by: Kristian Høgsberg <[email protected]> Acked-by: Marek Olšák <[email protected]> Acked-by: Alan Coopersmith <[email protected]> Acked-by: Jakob Bornecrantz <[email protected]> Acked-by: Dave Airlie <[email protected]> Build-Tested-by: Jakob Bornecrantz <[email protected]> Tested-by: Eugeni Dodonov <[email protected]>
* vbo: remove unused var, remove unneeded local varBrian Paul2011-08-241-4/+1
|
* mesa: Only map the necessary buffer range in vbo_get_minmax_indexIan Romanick2011-08-231-4/+19
| | | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Eliminate dd_function_table::MapBufferIan Romanick2011-08-236-31/+35
| | | | | | | | | | Replace all calls to dd_function_table::MapBuffer with appropriate calls to dd_function_table::MapBufferRange, then remove all the cruft. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Remove target parameter from dd_function_table::FlushMappedBufferRangeIan Romanick2011-08-231-2/+1
| | | | | | | | | | No driver used that parameter, and most drivers ended up with a bunch of unused-parameter warnings because it was there. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Remove target parameter from dd_function_table::MapBufferRangeIan Romanick2011-08-231-2/+1
| | | | | | | | | | No driver used that parameter, and most drivers ended up with a bunch of unused-parameter warnings because it was there. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Remove target parameter from dd_function_table::GetBufferSubDataIan Romanick2011-08-231-1/+1
| | | | | | | | | | No driver used that parameter, and most drivers ended up with a bunch of unused-parameter warnings because it was there. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Remove target parameter from dd_function_table::MapBufferIan Romanick2011-08-236-18/+7
| | | | | | | | | | No driver used that parameter, and most drivers ended up with a bunch of unused-parameter warnings because it was there. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Remove target parameter from dd_function_table::UnmapBufferIan Romanick2011-08-237-17/+12
| | | | | | | | | | No driver used that parameter, and most drivers ended up with a bunch of unused-parameter warnings because it was there. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: fix !FEATURE_GL buildChia-I Wu2011-08-211-18/+18
| | | | | | | Move vbo_exec_FlushVertices_internal out of FEATURE_beginend. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* vbo: do not call _mesa_max_buffer_index in debug buildsMarek Olšák2011-08-051-3/+1
| | | | | | | | | That code drops performance in Unigine Heaven and Tropics by a factor of 10. That's too crazy even for a debug build. NOTE: This is a candidate for the 7.11 branch. Reviewed-by: Brian Paul <[email protected]>
* vbo: minor optimisation in vbo_exec_DrawRangeElementsDave Airlie2011-07-141-3/+3
| | | | | | | | this moves getting the context into the debug in this function, just spotted it trawling callgrind traces for other things. Signed-off-by: Dave Airlie <[email protected]>
* vbo: Don't discount stride == 0 for testing all varyings in VBOs.Eric Anholt2011-06-231-2/+1
| | | | | | | | | | | | | | | | | In fixed function, stride == 0 (e.g. glColor4f() outside of the draw call) would get turned into uniform inputs, which is why it was ignored originally in this test. For shaders, drivers end up seeing a need to upload stride == 0 data, and get confused by needing to upload when vbo_all_varyings_in_vbos() returned true. In the 965 driver case, it wouldn't bother to compute the min/max index, and uploaded nothing if the min/max wasn't known. We've talked about removing the ff stride=0-into-uniforms code, so this check shouldn't be missed once that's gone. Fixes ARB_vertex_buffer_object/mixed-immediate-and-vbo Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37934 Reviewed-by: Brian Paul <[email protected]>
* vbo: Don't bother checking for stride == 0 for "any varying in a VBO".Eric Anholt2011-06-231-2/+1
| | | | | | | We would still want to consider that data as being in a VBO even if we managed to produce this case, which as far as I know we can't. Reviewed-by: Brian Paul <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 06:58:33 +0000