Compiling drivers for Intel Nuc6i5SYH
wayland is not working because of drivers, so its time to compile some shit myselve
122 Replies
how would I get started? do I have to compile on the nuc or can I do that on my pc to (ryzen 5 1500)
@pixelperfect1 so this would be the patch I would need to cherrypick? https://gitlab.freedesktop.org/mesa/mesa/-/commit/70ce634dc6d9c61db8af4dc5cb888b3ef51deef8.patch
you would need to apply that patch to the version of mesa we ship
in theory you could patch the srpm of the mesa you have installed
http://bradthemad.org/tech/notes/patching_rpms.php
see the repo's spec_files/mesa folder
which one are you shipping?
it's in the repo
You’ll need to use distrobox to set up an rpmbuild environment if you’re doing it on the NUC
I would prefer doing the compiling on my desktop
you mean bazzite git repo, or that i can run rpm-ostree to get the version ?
so youre running 23.1.6
GitHub
bazzite/spec_files/mesa at main · ublue-os/bazzite
Bazzite is an OCI image that serves as an alternative operating system for the Steam Deck, and a ready-to-game SteamOS-like for desktop computers and living room home theater PCs. - ublue-os/bazzite
he meant the repo
yea
ive already got that
and in the repo it says 23.1.6
I now got a local copy of the offical mesa repo of 23.1.6
I now gonna try building it without modifications, so that I can see that that works with my enve atleast
you need to use that spec file and build it using rpmbuild, not using make in the sync'd repo
you can add that patch to the spec file and use rpmbuild to build it
ahh oaky
I believe it will even grab the sources?
yeah--it should
so how ecaxt would I use rpmbuild, any arguments? in the spec_files/mesa folder? or would i make a build folder?
ahh found it:
rpmbuild -ba file.spec
@KyleGospo is that right? can I do the building on my Desktop (running fedora 38 kde?) or do I have to do it on the nuc itselve?damn
what am I doing wrong?
You'll want to do it in copr
?
Learning curve is more of a brick wall here
gimme docs I shoudl read
eh?
so, step 1 is creatingg a custom copr repo?
rpmbuild is fine? it can be layered?
just to ensure the patch even works--the same spec would then be able to be pushed to a copr?
well, I did compiling stuff before, I even worked with opengl itsleve, so I guess, I atleast could get some grip on that wall
@KyleGospo could I follow this to setup a new copr? https://docs.fedoraproject.org/en-US/quick-docs/publish-rpm-on-copr/
Fedora Docs
How to Publish your Software on Copr, Fedora’s User Repository
This is a short tutorial on how to create and maintain a Copr repository for your software in an automated fashion. It assumes some basic familiarity with Git & how…
or, is the spec using macros that only work on copr? I'm just so lost as to why you need copr here
welll, ive ive read right, I first need a git: https://git.euph.dev/Snoweuph/Copr-mesa-nuc6i5syh
@KyleGospo would I just copy the spec file from bazzites repo, or would I use a git module for this?
would i use tito?
so, yes, these are copr-related macros
https://docs.pagure.org/rpkg-util/quick_start.html
theoretically you could use rpkg locally? unfamiliar here
so
I started following the official fedora guide for creating an copr
if I find time, my theory
* clone bazzite locally
* modify spec file to include patch file
* git add ./path/to/spec ./path/to/patch
* git commit -m "test"
* rpkg local ./path/to/spec
would be the minimum to get an RPM built for testing
Fork bazzite in GitHub
Create Copr account
Create repo, point to Mesa spec file in your fork
so that I get github actions?
for the build?
Add patch to spec file, build on copr
Edit containerfile to add Copr repo and use that mesa
ah yeah, you know what, copr would be easier lol
Then you have your own bazzite build for old intel
And it'll stay up to date
Like I said, brick wall learning curve
But you can do it
there are hackier ways to add a copr but that would even make it sharable
well, just doing a fork, prolly is the easiest
yay cor website is online again
oh wow--looks like copr has some documentation on reproducing copr builds locally https://docs.pagure.org/copr.copr/user_documentation/reproducing_builds.html#reproducing-builds
but yeah, best to just do things publicly and set up the tooling to let it all update automatically
saves you having to do all this again every update
yeah especially considering how often mesa gets updates
what do I set for the build options?
f38?
you'll want to build x86_64 specifically
you don't need ppc, aarch, arm.
i386? @KyleGospo
probably not--I don't think we need 32bit mesa?
I would just start with x86_64 for now and you can enable more later if need be, but you should be good--you could optionally enable. f39, f40, rawhide, but eh
just only gonna use f38 for now
anyting I put here?
what do I put here?
and what for option 4
38, 39, rawhide
all x86_64
keep follow fedora branching checked
no other changes
okay
I love the response time of https://copr.fedorainfracloud.org
https://copr.fedorainfracloud.org/coprs/snoweuph/mesa-bazzite-intel-nuc6i5syh/
what are the next steps?
new package?
yep
add your spec file from your forked repo
name it mesa
like this?
clone url is your github repo
check auto rebuild
ending in .git
the repo url you'd use to clone
good
whats next?
running rebuild action?
did you edit the spec to have your patch?
not yet
do that first
then worry about building
this is ready to build whenever
so how and where would I do that inthe spec file?
you'd make a .patch file that applies to the current version of mesa
put it in spec_files/mesa
there's two other patches in the file already
add it as a PatchX in the spec next to the others
and then build it in copr
patchX.patch?
name doesn't matter
make it useful to you
look in the spec to figure out what PatchX means
and then I just copy this in therre?
what
if that applies to the latest mesa, yea
if it doesn't you'll have to make a new one
@pixelperfect1 had givven me taht one
it's dated 2022
no guarantees
might have to be updated
that was the one from the thread. it may or may not work, yeah
so just gonna trial and error now
and then add the .patch to the .spec ?
yes
as patch30 ?
sure
the number I believe just denotes the order the patches are applied, incremented by 1--why these are by 10? idk, probably just in case a patch for a patch is needed by a downstream?
ahh, so like systemd files
okay, now if I want to make a build
just press rebuild
and change nothing
okay
now waiting
patch needs to be updated
not update, patched lmao xD
well, its quite late for me allready, gonna not work on it more today
odd
the srpm that it output didn't include that reject file?
nah that's normal
just copr things
is there any way to get the rejected patchfile or do you need to specify it as a build target...
easiest to just download the mesa source for that version
patch manually
and make a new .patch from it
then you know it applies cleanly
true, making a new diff wouldn't be hard
oh yeah there's been a lot added to that .c file
for example, there's a whole new section that's been added
wait, that links to an MR that's been merged? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17182
GitLab
anv: Improve image/view usage bits verification (!17182) · Merge re...
This change makes usage bits verification closer to the Vulkan spec (at least as I understand it). VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT does not always require all formats to support...
So, that means, part of the patch got merged?
I wasn’t able to take time to look at Mesa’s actual code, but following the thread, gamesvope devs say: “this won’t be fixed. We are waiting for this upstream MR to fix this issue”
The upstream MR has been merged, so theoretically the issue was already patched, but you’re clearly still having issues
Damn
I should tryout some distros to see if it works on others, and when I find ine that works, then I could search for the differences
How do I check if im using software or hardware rendering again?
Or is that a stupid idea?
@KyleGospo what would you suggest?
I just booted fedora 38 stock life, and in the about system in the settings there, on the live image its saying wayland
Booting X isn't a sign of an issue
We force X on the deck builds atm because steam input doesn't support Wayland
SteamOS does the same
So, what was the specific sigb twelling us that the driver is not working?
You have a specific issue with some Vulkan extension
That renders gamemode unusable
So how would I test thet out?
Is there somethin like vktest ?
You'd have to install and launch gamescope
That being said we ship the same Mesa that's in Fedora
We add two patches on top, neither of which touch intel
So, it would make sense to try out another distro?
Not really, it's not like Fedora ships a different Mesa than anybody else
Damn
Im just confused because that one pr is merged, that is supposed to fix my problem
so, I now Need to find out where the problem lies in mesa and my only help is:
in that file of gamescope , the surounding lines are:
so the problem of gamescope is: that it want something in that pointer related to drm, but instead it is just null.
so next step is to find more out aboutthat wlr_drm_format_set_get function, so that I can maybe point it more down towhat is acutally failing in the driver
I guess that wlr stands for wlroots
okay, found it:
https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/render/drm_format_set.c
GitLab
render/drm_format_set.c · master · wlroots / wlroots · GitLab
A modular Wayland compositor library
things I could look at:
1. test that the pointer primary_formats and the value drmFormat are good before they are given to the wlr_drm_format_set_get function.
2. look into the wlr_drm_format_set_get of wlroots to see what it is actually doing, and then reproducing that in a test script, that I can then use to test if the cahnges to the drivers are working.
3.write an issue on gamescope in the hope to get the needed information to do something more myself
I modifyed gamescope to log me the values and builded it myselve and this is the output:
Value of &g_DRM.primary_formats: 0x6dc200
Value of drmFormat: 808669761
I did multiple test runs and these values are allways the same
I did some logging
So, it looks like its tryng to get a specific DRM format out of the list of available ones, but it does not exist
found the missing format in mesa: DRM_FORMAT_ARGB2101010 is not included in the list
Okay, I was able to backtrace the call to Bint to the vulkan_make_output_images function, next I gonna do some logging here to get more info, goal is to find out why that format is missing
I was able to find out that this is equal to: VK_FORMAT_A2R10G10B10_UNORM_PACK32 or also known as the number 58 as a vulkan Format
so now the next question I mighty wanna solve is: is the format its trying to get not in the list of formats because it shouldnt be or is it missing because of some problem
@KyleGospo the struct that stores the available drms is defined in the drm.hhp, but I have problerms finding out, where it gets filled with the actuall data
In rendervulkan.ccp there is a call to vulkan_make_output() which says: outputFormat = VK_FORMAT_A2B10G10R10_UNIFORM_PACK32
well, I just did some more looging and it doesnt even reach the point.
@KyleGospo gamescopes checks in the
vulkan_make_output if its a VR || Headless session else if SDL session else it just takes the pre defined "Invalid DRM format" and converts and uses it, and thats where im landing. Now my question: if im running gamescope from TTY, what kind of session is it?I'll have to look, but TTY should be the same as how the session starts it
Yea, the question is, if its a headless or sdl session or something else on machines were its working right
Because depending on the session type its trying diffrent stuff, and knowing this will allow me to eliminate a bif chunk of code
In the end im still trying to figure out where the drives are doing me wrong