Out of memory: Killed process 1820693 (rustc)
With only 4 GB of memory, you need to be careful when building Mesa.
Remote
Christian Gmeiner
@austriancoder@fosstodon.org
mastodon 4.7.3219 Followers
218 Following
23 Posts
Joined November 05, 2022
New blog post: PanVK Extension Sprint - Mesa 26.1 🚀
18 Vulkan extensions landed in PanVK for Mesa 26.1 - the open-source Vulkan driver for Arm Mali GPUs. Covering the Proton stack essentials (DXVK, vkd3d-proton), DDK feature parity, and closing gaps on mesamatrix.
From VK_EXT_conditional_rendering to VK_EXT_nested_command_buffer - each one pulls PanVK closer to "throw a DXVK game at it and it just works."
depth32f emulation MR is ready!
Took me some rounds to cleanup and simplify some details, but this is the next big puzzle peace for gles3.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42448
I am working an a panvk extension and my commit messages are reflecting the heat in Europe.
One thing I find hard when working on multiple topics/MRs in parallel is remembering all the details behind why I implemented something a certain way. By the time the first code review arrives - often days/weeks later - I've already moved on mentally and started working on something else.
From time to time I work on kernel stuff, and I finally switched to using b4. It has eliminated so much manual work that I wish I'd made the switch sooner.
In order to land support for a new feature, I had to rework how hw texture descriptors are created/handeld. Lucky me, I could look at other drivers how it was solved. I need to look at it with fresh eyes before creating the MR.
Good night
To pass more deqp gles3 tests, we need to support UNIFIED_SAMPLER feature of Vivante GPUs. It allows the fragment and vertex stages share one 32-entry
sampler HW array, that gets managed dynamically. With out it there is a fixed 16/16 split.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42507
When your newly written NIR pass causes an infinite optimization pass loop, you know it’s time to go to bed.
Yeah… cleaning up a long-lived git branch with more than 200 commits will take some time. There are reverts, hacks, and all sorts of fun issues.
Pro tip: don’t keep your feature branches alive for too long - in my case, 2 years. Catching up with upstream is painful.
Replying to
@karolherbst@chaos.social I'm surprised - yes .. ebc_nir_lower_pack_64.c
Replying to
@Luigi311@mastodon.social ATM it's still gles2 but I am working actively on it and a lot of gles3/3.1 features are already in place. Using a more recent version gives new working features (even if they are hidden behind an env var) and from time even performance optimizations.
Life is hard - 100 meters away there’s 1 Gbps fiber available… but here? Nothing 😞
Replying to
@linmob@linuxmobile.social @Luigi311@mastodon.social correct - I work on other areas in mesa too :)
Replying to
@Luigi311@mastodon.social always try to use a recent/latest mesa version... there is always something for etnaviv.
Replying to
Spend the nights during the weekend with some time consuming debug of RA issues - looks like it seems to be okay now.
Replying to
@karolherbst@chaos.social best commit message so far: "hacks.. again .." 😅
Replying to
@karolherbst@chaos.social I’ll remember this tip for the next feature branch. I actually started catching up with upstream about six months ago. I’m now at a point where I think everything works as expected, but there’s still a lot of cleanup left to do.
The biggest pain point is that about 4–5 months ago, I decided to slowly change the core architecture. I probably should have started fresh back then… but yeah, I didn’t have anything better to do at night.
Replying to
@Luigi311@mastodon.social I couldn't resist and went with the maxed-out IMX8M version 🙃
#etnaviv #MechaComet
Replying to
@linuxplumbersconf I think the correct link would be https://lpc.events/event/18/abstracts/