summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* i965: Warn about preliminary support for Gen11Matt Turner2018-02-281-0/+7
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: use context priority definitions from gen_defines.hTapani Pälli2018-02-283-10/+10
| | | | | | Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* st/mesa: ensure that images don't try to reference non-existent levelsIlia Mirkin2018-02-271-0/+1
| | | | | | | | | Ideally the st_finalize_texture call would take care of that, but it doesn't seem to with KHR-GL45.shader_image_size.advanced-nonMS-*. This assertion makes sure that no such values are passed to the driver. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* i965: Use gen_get_pci_device_id_overrideJordan Justen2018-02-271-52/+5
| | | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Scott D Phillips <[email protected]>
* mesa: Expose EXT_shader_framebuffer_fetch(_non_coherent) on desktop and ↵Francisco Jerez2018-02-241-1/+2
| | | | | | embedded GL. Reviewed-by: Plamena Manolova <[email protected]>
* glsl: Specify framebuffer fetch coherency mode in ↵Francisco Jerez2018-02-242-2/+4
| | | | | | | | | | | | | | | | | | | | | lower_blend_equation_advanced(). This requires passing an extra argument to the lowering pass because the KHR_blend_equation_advanced specification doesn't seem to define any mechanism for the implementation to determine at compile-time whether coherent blending can ever be used (not even an "#extension KHR_blend_equation_advanced_coherent" directive seems to be required in the shader source AFAICT). In the long run we'll probably want to do state-dependent recompiles based on the value of ctx->Color.BlendCoherent, but right now there would be no benefit from that because the only driver that supports coherent framebuffer fetch is i965 on SKL+ hardware, which are unable to support the non-coherent path for the moment because of texture layout issues, so framebuffer fetch coherency is always enabled for them. Reviewed-by: Plamena Manolova <[email protected]>
* mesa: Implement glFramebufferFetchBarrierEXT entry point.Francisco Jerez2018-02-243-2/+24
| | | | Reviewed-by: Plamena Manolova <[email protected]>
* mesa: Rename MESA_shader_framebuffer_fetch gl_extensions bits to EXT.Francisco Jerez2018-02-2410-16/+15
| | | | | | | | The changes I had originally planned for the MESA_shader_framebuffer_fetch extension have been merged into the EXT spec, there's no point in keeping MESA_shader_framebuffer_fetch extension enables. Reviewed-by: Plamena Manolova <[email protected]>
* mesa: Rename dd_function_table::BlendBarrier to match latest EXT spec.Francisco Jerez2018-02-244-9/+9
| | | | | | | | This GL entry point was renamed to glFramebufferFetchBarrier() in the EXT extension on request from Khronos members. Update the Mesa codebase to match the latest spec. Reviewed-by: Plamena Manolova <[email protected]>
* i965: Fix KHR_blend_equation_advanced with some render targets.Francisco Jerez2018-02-241-1/+3
| | | | | | | | | | | | | | | | This reverts two bogus and seemingly useless changes from the commits referenced below, which broke KHR_blend_equation_advanced (and EXT_shader_framebuffer_fetch_non_coherent which wasn't exposed yet) for any kind of render target surface that would cause the get_isl_surf() call in brw_emit_surface_state() to do anything useful (notice how the result of get_isl_surf() is completely ignored by the caller right now), as was the case while using those extensions with 1D array or 3D framebuffers in particular. Fixes: f5859b45b1686e8116380d87 "i965/miptree: Switch remaining surfaces to isl" Fixes: bf24c3539e4b6989512968ca "i965/miptree: Clean-up unused" Cc: [email protected] Reviewed-by: Plamena Manolova <[email protected]>
* mesa: Update vertex processing mode on _mesa_UseProgram.Mathias Fröhlich2018-02-231-0/+2
| | | | | | | | | | | | The change is a bug fix for 92d76a169: mesa: Provide an alternative to get_vp_mode() that actually got exposed through 4562a7b0: vbo: Make use of _DrawVAO from the dlist code. Fixes: KHR-GLES31.core.shader_image_load_store.advanced-sso-simple Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105229 Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: rename has_core_gs -> has_gs in get_programivMarek Olšák2018-02-231-5/+5
| | | | | | | This is also true for GLES. Tested-by: Dieter Nützel <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: replace some API_OPENGL_CORE checks with _mesa_is_desktop_glMarek Olšák2018-02-233-6/+6
| | | | | | | This is more accurate with respect to the compatibility profile. Tested-by: Dieter Nützel <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: add some of missing compatibility support for ARB_bindless_textureMarek Olšák2018-02-232-8/+9
| | | | | | | The extension is exposed in the compatibility profile. Tested-by: Dieter Nützel <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: expose ARB_enhanced_layouts in the compatibility profileMarek Olšák2018-02-232-2/+3
| | | | | | | GLSL 1.40 is required. Tested-by: Dieter Nützel <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: enable OpenGL 3.1 with ARB_compatibilityMarek Olšák2018-02-232-14/+10
| | | | | Tested-by: Dieter Nützel <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: implement ARB_compatibilityMarek Olšák2018-02-232-0/+2
| | | | | Tested-by: Dieter Nützel <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: add missing RGB9_E5 format in _mesa_base_fbo_formatJuan A. Suarez Romero2018-02-231-0/+3
| | | | | | | | | | | | | | | | | | RGB9_E5 should be accepted by RenderbufferStorage if the EXT_texture_shared_exponent is exposed. It is left to the implementations to return GL_FRAMEBUFFER_UNSUPPORTED_EXT when checking the framebuffer completeness if they do not support rendering in this format. Discussed in: https://github.com/KhronosGroup/OpenGL-API/issues/32 This fixes KHR-GL45.internalformat.renderbuffer.rgb9_e5 v2: Added more info to the commit message (Antia) Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Antia Puentes <[email protected]>
* vbo: Make use of _DrawVAO from the dlist code.Mathias Fröhlich2018-02-234-93/+144
| | | | | | | | | Finally use an internal VAO to execute display list draws. Avoid duplicate state validation for display list draws. Remove client arrays previously used exclusively for display lists. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Use atomics for shared VAO reference counts.Mathias Fröhlich2018-02-233-5/+46
| | | | | | | | | | | VAOs will be used in the next change as immutable object across multiple contexts. Only reference counting may write concurrently on the VAO. So, make the reference count thread safe for those and only those VAO objects. v3: Use bool/true/false for gl_vertex_array_object::SharedAndImmutable. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* vbo: Make use of _DrawVAO from immediate mode drawMathias Fröhlich2018-02-235-104/+78
| | | | | | | | | Finally use an internal VAO to execute immediate mode draws. Avoid duplicate state validation for immediate mode draws. Remove client arrays previously used exclusively for immediate mode draws. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* vbo: Implement tool functions for vbo specific VAO setup.Mathias Fröhlich2018-02-232-2/+55
| | | | | | | | Correct VBO_MATERIAL_SHIFT value. The functions will be used next in this series. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Add flush_vertices to _mesa_bind_vertex_buffer.Mathias Fröhlich2018-02-234-16/+19
| | | | | | | We will need the flush_vertices argument later in this series. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Make _mesa_vertex_attrib_binding public.Mathias Fröhlich2018-02-232-18/+27
| | | | | | | | | Change vertex_attrib_binding() to _mesa_vertex_attrib_binding(), add a flush_vertices argument, and make it publicly available. The function will be needed later in the series. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Add flush_vertices to _mesa_{enable,disable}_vertex_array_attrib.Mathias Fröhlich2018-02-234-22/+34
| | | | | | | We will need the flush_vertices argument later in this series. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* vbo: Use _DrawVAO for array type draw commands.Mathias Fröhlich2018-02-233-73/+100
| | | | | | | | | | | | | | | | Switch over to use the _DrawVAO for all the array type draws. The _DrawVAO needs to be set before we enter _mesa_update_state, so move setting the draw method in front of the first call to _mesa_update_state which is in turn called from the *validate*Draw* calls. Using the gl_vertex_array_object::_Enabled bitmask, gl_vertex_program_state::_VPMode and gl_vertex_array_object::_AttributeMapMode we can already set varying_vp_inputs before we call _mesa_update_state the first time. Thus remove duplicate state validation. v2: Update comments. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* vbo: Implement method to track the inputs array.Mathias Fröhlich2018-02-234-0/+122
| | | | | | | | | | | | | Provided the _DrawVAO and the derived state that is maintained if we have the _DrawVAO set, implement a method to incrementally update the array of gl_vertex_array input pointers. v2: Add some more comments. Rename _vbo_array_init to _vbo_init_inputs. Rename vbo_context::arrays to vbo_context::draw_arrays. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Introduce a yet unused _DrawVAO.Mathias Fröhlich2018-02-237-0/+69
| | | | | | | | | | | | | During the patch series this VAO gets populated with either the currently bound VAO or an internal VAO that will be used for immediate mode and dlist rendering. v2: More comments about the _DrawVAO, filter and enabled mask. Rename _DrawVAOEnabled to _DrawVAOEnabledAttribs. v3: Fix and move comment. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* vbo: Remove get_vp_mode() and enum vp_mode.Mathias Fröhlich2018-02-231-27/+0
| | | | | | | Is now unused. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* vbo: Use _VPMode instead of get_vp_mode().Mathias Fröhlich2018-02-234-11/+14
| | | | | | | | At those places where we used get_vp_mode() use gl_vertex_program_state::_VPMode instead. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Provide an alternative to get_vp_mode()Mathias Fröhlich2018-02-2310-0/+75
| | | | | | | | | | | | | | | | | To get equivalent information than get_vp_mode(), track the vertex processing mode in a per context variable at gl_vertex_program_state::_VPMode. This aims to replace get_vp_mode() as seen in the vbo module. But instead of the get_vp_mode() implementation which only gives correct answers past calling _mesa_update_state() this context variable is immediately tracked when the vertex processing state is modified. The correctness of this value is asserted on state validation. With this in place we should be able to untangle the dependency with varying_vp_inputs and state invalidation. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965: perf: ensure reading config IDs from sysfs isn't interruptedLionel Landwerlin2018-02-231-1/+2
| | | | | | | Fixes: 458468c136e "i965: Expose OA counters via INTEL_performance_query" Signed-off-by: Lionel Landwerlin <[email protected]> Cc: <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* i965: Use finish_external instead of make_shareable in setTexBuffer2Jason Ekstrand2018-02-215-2/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The setTexBuffer2 hook from GLX is used to implement glxBindTexImageEXT which has tighter restrictions than just "it's shared". In particular, it says that any rendering to the image while it is bound causes the contents to become undefined. The GLX_EXT_texture_from_pixmap extension provides us with an acquire and release in the form of glXBindTexImageEXT and glXReleaseTexImageEXT. The extension spec says, "Rendering to the drawable while it is bound to a texture will leave the contents of the texture in an undefined state. However, no synchronization between rendering and texturing is done by GLX. It is the application's responsibility to implement any synchronization required." From the EGL 1.4 spec for eglBindTexImage: "After eglBindTexImage is called, the specified surface is no longer available for reading or writing. Any read operation, such as glReadPixels or eglCopyBuffers, which reads values from any of the surface’s color buffers or ancillary buffers will produce indeterminate results. In addition, draw operations that are done to the surface before its color buffer is released from the texture produce indeterminate results In other words, between the bind and release calls, we effectively own those pixels and can assume, so long as we don't crash, that no one else is reading from/writing to the surface. The GLX and EGL implementations call the setTexBuffer2 and releaseTexBuffer function pointers that the driver can hook. In theory, this means that, between BindTexImage and ReleaseTexImage, we own the pixels and it should be safe to track aux usage so we can avoid redundant resolves so long as we start off with the right assumption at the start of the bind/release pair. In practice, however, X11 has slightly different expectations. It's expected that the server may be drawing to the image at the same time as the compositor is texturing from it. In that case, the worst expected outcome should be tearing or partial rendering and not random corruption like we see when rendering races with scanout with CCS. Fortunately, the GEM rules about texture/render dependencies save us here. If X11 submits work to write to a pixmap after the compositor has submitted work to texture from it, GEM inserts a dependency between the compositor and X11. If X11 is using a high-priority context, this will cause the compositor to get a temporarily boosted priority while the batch from X11 is waiting on it. This means that we will never have an actual race between X11 and the compositor so no corruption can happen. Unfortunately, however, this means that X11 will likely be rendering to it between the compositor's BindTexImage and ReleaseTexImage calls. If we want to avoid strange issues, we need to be a bit careful about resolves because we can't really transition it away from the "default" aux usage. The only case where this would practically be a problem is with image_load_store where we have to do a full resolve in order to use the image via the data port. Even there it would only be a problem if batches were split such that X11's rendering happens between the resolve and the use of it as a storage image. However, the chances of this happening are very slim so we just emit a warning and hope for the best. This commit adds a new helper intel_miptree_finish_external which resets all aux state to whatever ISL says is the right worst-case "default" for the given modifier. It feels a little awkward to call it "finish" because it's actually an acquire from the perspective of the driver, but it matches the semantics of the other prepare/finish functions. This new helper gets called in intelSetTexBuffer2 instead of make_shareable. We also add an intelReleaseTexBuffer (we passed NULL to releaseTexBuffer before) and call intel_miptree_prepare_external in it. This probably does nothing most of the time but it means that the prepare/finish calls are properly matched. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/tex_image: Reference the renderbuffer miptree in setTexBuffer2Jason Ekstrand2018-02-211-14/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | The old code made a new miptree that referenced the same BO as the renderbuffer and just trusted in the memory aliasing to work. There are only two ways in which the new miptree is liable to differ from the one in the renderbuffer and neither of them matter: 1) It may have a different target. The only targets that we can ever see in intelSetTexBuffer2 are GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE and the difference between the two doesn't matter as far as the miptree is concerned; genX(update_sampler_state) only looks at the gl_texture_object and not the miptree when determining whether or not to use normalized coordinates. 2) It may have a very slightly different format. Again, this doesn't matter because we've supported texture views for quite some time so we always look at the gl_texture_object format instead of the miptree format for hardware setup anyway. On the other hand, because we were recreating the miptree, we were using intel_miptree_create_for_bo which doesn't understand modifiers. We really want this function to work without doing a resolve so long as you have modifiers so we need to fix that. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/tex_image: Pull the tex format from the renderbuffer in intelSetTexBuffer2Jason Ekstrand2018-02-211-15/+19
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/miptree: Loosen the format check in miptree_match_imageJason Ekstrand2018-02-214-6/+8
| | | | | | | | | | This function is used to determine when we need to re-allocate a miptree. Since we do nothing different in miptree allocation for sRGB vs. linear, loosening this should be safe and may lead to less copying and reallocating in some odd cases. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/state: Ignore intel_obj->_Format for depth/stencil and ETC2Jason Ekstrand2018-02-211-1/+15
| | | | | | | | | | We're about to start letting the intel_obj->_Format be the "real" texture format. For depth/stencil textures, this may be a combined depth stencil format. For ETC2 on gen7 and earlier, this will be the actual ETC2 format. This makes a bit more GL sense but means we have to be careful in state upload. Reviewed-by: Chad Versace <[email protected]>
* i965: Enable disk shader cache by defaultJordan Justen2018-02-201-3/+0
| | | | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* st/mesa: Factorize duplicate code for atomic buffer bindingGuillaume Charifi2018-02-201-38/+29
| | | | | Signed-off-by: Guillaume Charifi <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* st/mesa: Factorize duplicate code in st_update_framebuffer_state()Guillaume Charifi2018-02-201-13/+5
| | | | | | Signed-off-by: Guillaume Charifi <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* mesa: add xbgr support adjacent to xrgbIlia Mirkin2018-02-193-1/+15
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Acked-by: Daniel Stone <[email protected]>
* st/shader_cache: copy nir pointer to gl_program after deserializingTimothy Arceri2018-02-201-0/+6
| | | | | | | This fixes a crash when running the arb_get_program_binary-api-errors piglit test twice. Reviewed-by: Marek Olšák <[email protected]>
* i965: Use absolute addressing for constant buffer 0 on Kernel 4.16+.Kenneth Graunke2018-02-172-1/+32
| | | | | | | | | | | | | | | | | | | | | | | By default, 3DSTATE_CONSTANT_* Constant Buffer 0 is relative to dynamic state base address. This makes it unusable for pushing UBOs. There is a bit in the INSTPM register (or CS_DEBUG_MODE2 on Skylake) which controls whether buffer 0 is relative to dynamic state base address, or simply a normal pointer. Setting that gives us full flexibility. This lets us push up to 4 UBO ranges. We can't currently write this on Haswell and earlier, and will need to update the kernel command parser, and then do the whole version checking song and dance. We also need a brand new kernel that supports context isolation - on older kernels, newly created contexts inherit register state from whatever happened to be running. So, setting this would have catastrophic impact on other drivers such as libva, Beignet, or older Mesa. See commit 8ec5a4e4a4a32f4de351c5fc2bf0eb615b6eef1b where we did this once before, but had to revert it in commit 013d33122028f2492da90a03a. Reviewed-by: Francisco Jerez <[email protected]>
* i965: Stop restoring the default L3 configuration on Kernel 4.16+.Kenneth Graunke2018-02-173-2/+7
| | | | | | | | | | Kernel 4.16 has proper context isolation, which means we can change the L3 configuration without worrying about that leaking to other newly created contexts, breaking the assumptions of other userspace. So, disable our workaround to reprogram it back to the default. Reviewed-by: Francisco Jerez <[email protected]>
* i965: Fix aux-surface size checkDaniel Stone2018-02-172-3/+12
| | | | | | | | | | | | | | | | | | | The previous commit reworked the checks intel_from_planar() to check the right individual cases for regular/planar/aux buffers, and do size checks in all cases. Unfortunately, the aux size check was broken, and required the aux surface to be allocated with the correct aux stride, but full image height (!). As the ISL aux surface is not recorded in the DRIimage, we cannot easily access it to check. Instead, store the aux size from when we do have the ISL surface to hand, and check against that later when we go to access the aux surface. Signed-off-by: Daniel Stone <[email protected]> Fixes: c2c4e5bae3ba ("i965: Fix bugs in intel_from_planar") Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Implement GenerateMipmap directly, rather than using Meta.Kenneth Graunke2018-02-165-0/+135
| | | | | | | | | | | | | | | | | | Meta is awful and we'd like to stop using it. Implementing this using BLORP allows us to stop trashing a bunch of GL state every time. This follows the structure of st_generate_mipmap(). compute_num_levels is lifted directly from there. Improves performance in Gl41HdrBloom by about 11.794% +/- 1.01919% (n=3) on Kabylake GT2 at 1280x720 (the difference seems much smaller at higher resolutions). v2 (idr): Don't try depth or depth-stencil blorp blits on Gen4 or Gen5 because it's not implemented yet. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* mesa: Move compute_num_levels from st_gen_mipmap.c to mipmap.c.Kenneth Graunke2018-02-163-27/+29
| | | | | | | I want to use compute_num_levels inside i965. Rather than duplicating it, move it from mesa/st to core Mesa, and make it non-static. Reviewed-by: Marek Olšák <[email protected]>
* i965/icl: Add render target flush after uploading binding tableAnuj Phogat2018-02-151-0/+14
| | | | | | | | | | | | | | | | | | From PIPE_CONTROL command description in gfxspecs: "Whenever a Binding Table Index (BTI) used by a Render Taget Message points to a different RENDER_SURFACE_STATE, SW must issue a Render Target Cache Flush by enabling this bit. When render target flush is set due to new association of BTI, PS Scoreboard Stall bit must be set in this packet." V2: Move the PIPE_CONTROL to update_renderbuffer_surfaces() in brw_wm_surface_state.c (Ken). Fixes a fulsim error and a GPU hang described in below JIRA. JIRA: MD5-322 Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/icl: Enable float blend optimization and Wa3DStateModeAnuj Phogat2018-02-151-1/+1
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/common/icl: Add has_sample_with_hiz flag in gen_device_infoAnuj Phogat2018-02-151-4/+1
| | | | | | | | | | | Sampling from hiz is enabled in i965 for GEN9+ but this feature has been removed from gen11. So, this new flag will be useful to turn the feature on/off for different gen h/w. It will be used later in a patch adding device info for gen11. Suggested-by: Kenneth Graunke <[email protected]> Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-23 12:29:47 +0000