MesaGL development on Fedora
Hello, I was going over MesaGL Blending when I discovered an issue that needs fixing. The problem is that when I compile and install a custom version of the Fedora mesa-libGL package, i.e. https://archive.mesa3d.org/mesa-23.1.9.tar.xz, that my system (gnome-terminal, firefox, chromium) becomes unstable even without the patch applied. At first I thought it was the patch, but it isn't. Help would be appreciated. Best regards, Mischa Baars.
Re: [ANNOUNCE] mesa 23.3.2
Hello Eric, I recently opened two issues and have a bugfix available, but the issues seem to be overlooked. I am unable to fork the project and submit a merge request for unknown reasons. https://gitlab.freedesktop.org/mesa/mesa/-/issues/10346 https://gitlab.freedesktop.org/mesa/mesa/-/issues/10257#note_2209602 The patch attached is against the latest 23.3.2 release. The arguments passed to glBlendFunc, glBlendEquation, glBlendFuncSeparate and glBlendEquationSeparate did not always arrive at the graphics adapter unharmed. They do with the patch applied. The blender results now do correspond to their precomputed values. Blenders grouped as in the .inc file now do produce identical results for the given input colors. Hope you accept my patch like this. Best regards, Mischa Baars, the Netherlands. On Wed, Dec 27, 2023 at 11:47 PM Eric Engestrom wrote: > Hello everyone, > > The bugfix release 23.3.2 is now available. > > If you find any issues, please report them here: > https://gitlab.freedesktop.org/mesa/mesa/-/issues/new > > The next bugfix release is due in two weeks, on January 10th. > > Cheers, > Eric > > --- > Bas Nieuwenhuizen (1): > radv: Use correct writemask for cooperative matrix ordering. > > Boris Brezillon (3): > util/hash_table: Use FREE() to be consistent with the > CALLOC_STRUCT() call > util/hash_table: Don't leak hash_u64_key objects when the entry > exists > util/hash_table: Don't leak hash_key_u64 objects when the u64 hash > table is destroyed > > Christian Gmeiner (2): > etnaviv: Update headers from rnndb > etnaviv: Add static_assert(..) to catch memory corruption > > Dave Airlie (1): > intel/compiler: move gen5 final pass to actually be final pass > > David Heidelberg (2): > ci/freedreno: timestamp-get no longer fails on Adreno > ci/freedreno: fail introduced by ARB_post_depth_coverage > > Eric Engestrom (12): > docs: add sha256sum for 23.3.1 > .pick_status.json: Update to d761871761e5fe7d498b0cc818ed627698ed1225 > .pick_status.json: Update to 377c6b2d45ee73da3e5431846a3b4bfdd7ae2b83 > ci/b2c: drop passthrough of unset CI_JOB_JWT > .pick_status.json: Updates notes for > 6a92af158dc132eee449c175bdee66d92c68d191 > vulkan/wsi: fix build when platform headers are installed in > non-standard locations > .pick_status.json: Update to 670a799ebff9a98daafccf49324c2a01311b0c41 > .pick_status.json: Update to e61fae6eb8ae1ae1228d6f89329324310db808ae > .pick_status.json: Update to 1e6fcd6a611574241b1cde306afcc416a03ac76b > .pick_status.json: Update to 55c262898ae7188311c89a60e4ec0fbb67b7a95b > docs: add release notes for 23.3.2 > VERSION: bump for 23.3.2 > > Faith Ekstrand (1): > nir: Scalarize bounds checked loads and stores > > Friedrich Vock (2): > radv,vtn,driconf: Add and use radv_rt_ssbo_non_uniform workaround > for Crysis 2/3 Remastered > radv/rt: Initialize unused children in PLOC early-exit > > George Ouzounoudis (1): > vulkan: Fix dynamic graphics state enum usage > > Gert Wollny (1): > r600/sfn: keep workgroup and invocation ID registers for whole shader > > Jesse Natalie (1): > d3d12: Only destroy the winsys during screen destruction, not reset > > Jonathan Gray (1): > intel/common: add directory prefix to intel_gem.h include > > José Expósito (1): > egl/glx: fallback to software when Zink is forced and fails > > Karol Herbst (4): > rusticl/kernel: explicitly set rounding modes > rusticl: do not warn on empty RUSTICL_DEBUG or RUSTICL_FEATURES > rusticl: silence clippy::arc-with-non-send-sync for now > rusticl: check rustc version for flags requiring newer rustc/clippy > > Kenneth Graunke (3): > iris: Initialize bo->index to -1 when importing buffers > iris: Don't search the exec list if BOs have never been added to one > iris: Skip mi_builder init for indirect draws > > Lionel Landwerlin (4): > nir/clone: fix missing printf_info clone > nir/divergence: handle printf intrinsic > anv: fix incorrect queue_family access on command buffer > anv: wait for CS write completion before executing secondary > > Michel Dänzer (2): > gallium/dri: Return __DRI_ATTRIB_SWAP_UNDEFINED for _SWAP_METHOD > glx: Handle IGNORE_GLX_SWAP_METHOD_OML regardless of GLX_USE_APPLEGL > > Pierre-Eric Pelloux-Prayer (4): > radeonsi/sqtt: fix RGP pm4 state emit function > radeonsi/sqtt: clear record_counts variable > radeonsi/sqtt: rework pm4.reg_va_low_idx > radeonsi/sqtt: use calloc instead of malloc > > Robert Foss
Re: MesaGL development on Fedora
In continuation of our earlier conversation ( https://gitlab.freedesktop.org/mesa/mesa/-/issues/10257): I did not get this error message creating a fork of the GNOME/gtk project five minutes ago, but I do get the message when trying to create a fork of the mesa project: An error occurred while forking the project. Please try again. Any idea why? Regards, Mischa. On Tue, Dec 26, 2023 at 11:11 AM Mischa Baars wrote: > Hi Marek, > > Although 23.1.9 is the version that is used throughout the system, loading > the custom library resolved through /etc/ld.so.cache destabilizes things. > Maybe it's simpler to use 'LD_LIBRARY_PATH=/usr/local/mesa-23.1.9/lib64 > path/to/binary', to ensure that only this specific application uses this > specific library, then to create more custom libraries at this point. > > Regards, > Mischa. > > On Mon, Dec 25, 2023 at 1:46 PM Marek Olšák wrote: > >> Hi, >> >> All Mesa libraries must come from the same build so as not to be >> rejected at runtime. >> >> Marek >> >> On Mon, Dec 25, 2023 at 7:15 AM Mischa Baars >> wrote: >> > >> > Hello, >> > >> > I was going over MesaGL Blending when I discovered an issue that needs >> fixing. The problem is that when I compile and install a custom version of >> the Fedora mesa-libGL package, i.e. >> https://archive.mesa3d.org/mesa-23.1.9.tar.xz, that my system >> (gnome-terminal, firefox, chromium) becomes unstable even without the patch >> applied. At first I thought it was the patch, but it isn't. >> > >> > Help would be appreciated. >> > >> > Best regards, >> > Mischa Baars. >> > >> >
Re: MesaGL development on Fedora
Hi Marek, Although 23.1.9 is the version that is used throughout the system, loading the custom library resolved through /etc/ld.so.cache destabilizes things. Maybe it's simpler to use 'LD_LIBRARY_PATH=/usr/local/mesa-23.1.9/lib64 path/to/binary', to ensure that only this specific application uses this specific library, then to create more custom libraries at this point. Regards, Mischa. On Mon, Dec 25, 2023 at 1:46 PM Marek Olšák wrote: > Hi, > > All Mesa libraries must come from the same build so as not to be > rejected at runtime. > > Marek > > On Mon, Dec 25, 2023 at 7:15 AM Mischa Baars > wrote: > > > > Hello, > > > > I was going over MesaGL Blending when I discovered an issue that needs > fixing. The problem is that when I compile and install a custom version of > the Fedora mesa-libGL package, i.e. > https://archive.mesa3d.org/mesa-23.1.9.tar.xz, that my system > (gnome-terminal, firefox, chromium) becomes unstable even without the patch > applied. At first I thought it was the patch, but it isn't. > > > > Help would be appreciated. > > > > Best regards, > > Mischa Baars. > > >
Re: rendering scene on a card different from the one displaying
Hi test, And I found this for you: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/getting_started_with_the_gnome_desktop_environment/remotely-accessing-an-individual-application-wayland_getting-started-with-the-gnome-desktop-environment I just tested it here and it works. I can run a Wayland server application on a Wayland client. Regards, Mischa. On Sat, Jan 27, 2024 at 11:01 PM Konstantin Kharlamov wrote: > On Thu, 2024-01-25 at 18:13 +0300, test wrote: > > What is the most proper way to re-route output from a rendering card > > (which can have it's output disconnected or don't have it at all) to > > a > > displaying card (weak one, iGPU etc)? > > For example, a laptop with an external card in an ExpressCard riser > > (no > > external display is connected to the card), or a desktop PC with > > embedded video plus Nvidia Tesla? > > How should I configure Mesa in order to get «auto-screen-grabbing» > > from > > the rendering card to the displaying one? > > Fixed the title. > > Sounds like you're interested in `DRI_PRIME` variable. See > documentation here > https://docs.mesa3d.org/envvars.html#envvar-DRI_PRIME > > Assuming you want this for development purposes, you can also use > Vulkan API, but Idk details here. > > This is a user question though, so belongs to mesa-users and not to > mesa-dev. >
