<jani>
airlied: also, airlied@linux.ie keeps bouncing from airlied@skynet.ie
<kj>
Could someone with permission add powervr as a coverity component?
nchery is now known as Guest1812
nchery has joined #dri-devel
<mripard>
jani: is there a coccinelle script for this one? from experience it only stopped once the script was removed
pcercuei has joined #dri-devel
Guest1812 has quit [Ping timeout: 480 seconds]
jfalempe has quit [Remote host closed the connection]
jfalempe has joined #dri-devel
<jani>
mripard: yeah, returnvar.cocci
<jani>
I also hate the fact that they credit "Reported-by: Zeal Robot <zealci@zte.com.cn>" while it's just running cocci scripts contributed by other people
<jani>
in some cases I think returnvar.cocci changes are fine; it's subjective and case-by-case I think. but what can you do when there's zero interaction and it's just undiscriminate patch bombing with the idea that some of them stick?
<jani>
one day you get a thousand "remove repeated words from comments" patches, the other day something else
<mripard>
I've yet to see someone that likes that kind of patch, so you could argue that it needs to be removed
<mripard>
I'd ack it ;)
<mripard>
and then, sure, the communication is bad, but if you remove the source of the problem you won't have to communicate
<mripard>
and coccinelle patches are controversial indeed... I still think it's a good thing to do that kind of low-effort, background improvements
<mripard>
even if they can be a bit meaningless
<jani>
there are different ways of doing it I think
<jani>
some folks actually listen to your feedback
<mripard>
that's true
<hakzsam>
dcbaker: eric_engestrom: when 22.2.0 will be released?
<jani>
also, it kind of used to be a gentle way to ease into submitting kernel patches to do the odd cleanups first, and then progressing. now, we have people (and I guess organizations) who are really focused only on doing these small improvements all over the place, en masse
<jani>
the top Reported-by credits in lwn stats are various robots
<jani>
Dan Carpenter is there too, is he a real person? :o ;)
<mripard>
I mean, imho it's due to us having the CI completely backward by reacting to a patch being merged instead of preventing it from being merged in the first place
<mripard>
and we pushed for having more and more of that CI
<mripard>
and some people actually listened
<mripard>
but it's not going to change any time soon, is it? :)
<jani>
I think that spirals pretty quickly into a discussion about email based workflows :p
<jani>
it would be so much easier to bolt all kinds of pre-merge checks into a merge request based workflow on some forge
<qyliss>
No reason one can't do CI on emails — QEMU does it.
<jani>
yeah, and we do it do, on a large scale
<jani>
*too
<qyliss>
oh, pre-merge CI for dri in the kernel?
<qyliss>
i didn't know that
<jani>
intel CI crunches through all patch series sent to intel-gfx@
<mripard>
some linux maintainers didn't have a git tree until a couple monthes ago, so it's a bit of a far fetch to expect that the entire kernel would switch to it
<jani>
on a plethora of machines
<qyliss>
oh, cool
<mripard>
but if we can do it for DRM, at least we could isolate ourselves from all those coccinelle checks
<airlied>
jani: yeah i see emails on lists separate to thslat
<airlied>
though i should getil it fixed, but reliant on admins on holidays
<jani>
daniels: yeah, but I'm kind of thinking about workflows you could pick and choose. like check a box to enable checking if a series introduces new cocci check issues
<jani>
daniels: not "send patches to igt, kernel, and have someone enable stuff in CI"
<jani>
daniels: debate whether we have time/hw budget to run this on every series, what's the ROI
<daniels>
so you want buttons in patchwork for 'run cocci on this series, run checkpatch on this series, run sparse on this series, ...'?
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
<jani>
daniels: heh, not really. I'm kind of thinking of being able to provide pre-merge workflows that would be easier to share. maybe
<daniels>
easier to share between ... ?
<jani>
drivers/subsystems/people willing to run them on the changes
<jani>
I think I'm probably talking more than thinking ;)
<jani>
looks like at the moment there's more perceived value in running "ci-ish" tasks post-merge with the possibility to get your Reported-by credits in kernel than doing any of that stuff pre-merge
<jani>
but even if you had the resources and desire to do pre-merge runs for the benefit of the kernel, *how* would you do that? everyone just picking patches off the list and trying to guess where to apply them?
<daniels>
stone tablets ftw
<daniels>
tbh I have zero confidence that pre-merge & unified submission will happen any decade soon for the kernel; the last time I tried to submit something outside of DRM, I got yelled at because 'PATCH for-5.15' was wrong and told to resubmit with 'PATCH for-v5.15' or whatever
<daniels>
so atm the focus on the DRM side has just been doing actual useful DRM testing and making sure the tests continue to work well, and treat the rest of the kernel as a hostile tyre fire
<jani>
qyliss: it's not a bad idea, but idk how much it helps with the current approach of developing and testing on top of drm-tip which is a rebasing integration tree and the base commits are largely ephemeral
<javierm>
jani: having a `dim check` or something that could somehow trigger a dry-run with your local changes would be awesome
pcercuei has quit [Read error: Connection reset by peer]
<qyliss>
yeah, perhaps not too useful for drm in partciular
pcercuei has joined #dri-devel
<javierm>
err, `dim test`
<jani>
javierm: locally or in CI?
<javierm>
jani: in CI
<javierm>
locally would be hard since I guess the CI has a lot of different gfx devices plugged in
<jani>
javierm: there's a "trybot" mailing list for sending your patches to be tested, but that's throttled with the main CI needs
itoral_ has joined #dri-devel
<javierm>
jani: I see. Wasn't familiar with that trybot
<jani>
I'm sure we don't advertize it really
<javierm>
jani: so dim could use the same infra and maybe do a push of your local drm-$foo to an ephemeral branch that's only used for CI once
<javierm>
and if is part of dim, then you make sure that only drm-misc committers could use it
<javierm>
jani: which I guess is the reason why you don't advertise the trybot ML
<jani>
javierm: it could. but then people start doing that first, get results, send the same thing over to public list, everything gets run again
<javierm>
jani: yeah, but hopefully they will only send the same thing if no errors were found :)
<jani>
I think the intention is more like, "if I make this change, would anything catch fire"
<javierm>
other that having to fix after-merge
<daniels>
well, the idea of GitLab is to do that pre-merge testing, so dim test could quite trivially push the branch and then poke the API to run the pipeline - we already have various scripts for doing & monitoring that within Mesa
<javierm>
jani: in other words. It would be great to have CI feedback before doing a dim push
<javierm>
*push-branch
<jani>
intel ci puts a lot of effort and resources into running pre-merge on real hardware. but *personally* I guess I'd like to see more static pre-merge checking too, not just from intel
<tagr>
some people already run pre-merge checks based on patchwork
<javierm>
jani: then maybe there could be split in two sets of tests, those that could be run locally (coccicheck, sparse, etc) and those that must be run on the CI infra due HW needs ?
<daniels>
jani: right, the GitLab CI stuff runs real tests on real hardware too ...
<jani>
e.g. we run sparse on the entire series only, not individual commits, so a patch mid-series might not even compile and it passes
<tagr>
not sure if they keep their tools anywhere public, though, it's not entirely trivial to write those from scratch
<daniels>
but there's no integration between the two worlds, so there's one way to get Intel's results and one way to get results from everyone else (which does include a few generations of Intel)
<jani>
javierm: well, I religiously run checkpatch and sparse before pushing anything, locally
itoral has quit [Ping timeout: 480 seconds]
<javierm>
jani: I do that too. But it's not part of the expected process, so is not enforced
<jani>
right
<jani>
sometimes you discover there's a patch series at v10 you're asked to push because it's reviewed and done, only to discover at the last stage before pushing that CI has been complaining about issues since v1 :p
<javierm>
jani: yeah, that's why I think that having this intregrated in the pushing workflow and getting feedback at that time is the way to go
<daniels>
++
<eric_engestrom>
hakzsam: it's dcbaker who handles 22.2.x, I don't know anything more than you and you'll have to wait a few hours before he wakes up :)
Company has joined #dri-devel
<javierm>
jani: because all kernel developers are usually quite behind their inbox to rely on feedbacks sending over emails :)
<daniels>
javierm: and that's assuming that the email actually gets delivered in the first place
<javierm>
daniels: right
<eric_engestrom>
kj: you can see the list of admins on https://scan.coverity.com/projects/mesa?tab=members; right now it's Vinson Lee & Brian Paul, neither of which on IRC as far as I know, so you might want to send them an email instead
<jani>
tagr: I didn't know that, besides intel CI of course
<tagr>
jani: so the kernel test robot (which is run by Intel) does per-merge build testing and such, and robher for example runs various DT checks based on patchwork
<tagr>
robher: on that note, do you keep the scripts that you use for that somewhere public? I'd be interested in comparing notes
<jani>
daniels: if I were to redesign the stone tablets workflow, I'd figure out systems where you can git push your series, and that would trigger sending emailed patches from a standardized enviroment, instead of trying to piece everything together again after lossy transmission over email
<kj>
eric_engestrom: will do thanks
<jani>
daniels: so you could keep the email based reviews. but then you could actually merge the stuff via git
<kj>
eric_engestrom: will do thanks
<daniels>
jani: I don't want to keep email-based reviews tbqh :P
<daniels>
but yeah, having a single source of truth as to what the code was actually supposed to be would be a huge improvement ... which is a pretty damning statement
<jani>
daniels: heh. but email-based review is just *human communication* and lossy is fine for that
<jani>
daniels: yeah. huge amounts of effort are being put into e.g. signing patches and figuring out how that works with a lossy medium. I don't really get it
<jani>
daniels: of course, the "Reviewed-by" is also unreliable. patchwork parses "if you rewrite everything then this is R-b" as "R-b"
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<daniels>
jani: yeah, my biggest issue is mostly the cognitive load to track everything between different series. I always spent a pretty inordinate amount of time going back over every part of every mail from the previous submission to make sure I'd addressed things, compared to having an actionable to-do list from every revision in the MR page. that and it got pretty painful trying to remember which revision a particular discussion was
<daniels>
in if you needed to continue on a discussion later ...
<kj>
eric_engestrom: will do thanks
kj has left #dri-devel [#dri-devel]
kj has joined #dri-devel
<kj>
eric_engestrom: will do thanks
devilhorns has joined #dri-devel
<jani>
daniels: agreed on that. the thing that's difficult for me personally is switching between the editor and some web page, and having different edit/search/etc environments in both
<daniels>
jani: you have your mail in emacs?
<jani>
daniels: since I read/write code and email in emacs
<jani>
yes :)
<daniels>
haha
<daniels>
perkeleen emacs os
<jani>
I find it hard to do code review in the web page alone, I often find I need to look around efficiently in the codebase
<jani>
daniels: :D
<daniels>
I'm kind of surprised no-one's written an extension to do that yet - the GitLab extension for VS Code (Emacs for young people) is pretty slick
<javierm>
there used to be a very nice extension for thunderbird that allowed you to use an external editor for editing emails, I used emacs for that
<javierm>
but unfortunately that stopped being supported by TB at some point :(
<daniels>
jani: wow, I didn't expect that at all
<jani>
daniels: I know!
<qyliss>
jani: have you looked at https://github.com/magit/forge at all? I keep meaning to set it up but haven't got round to it yet.
<jani>
qyliss: no, I don't use magit at all. I only do read-only git stuff from emacs, such as git log, git diff, git blame, etc.
<jani>
everything else on the command line
<jani>
(which, technically, could also happen in emacs, but to the surprise of daniels I'm sure I actually use separate terminal windows)
* jani
heads off to do some code review
<javierm>
jani: in emacs :)
<daniels>
jani: some of the Collabora Emacs enthusiasts use IRC from Emacs, and also wrote a timelog-mode so they could integrate their timesheet submissions too
<pq>
jani, funny. The need to look around in the code base is a big reason why reviewing emailed patches suck for me. :-)
<pq>
though that's painful also in the Gitlab web UI, so I tend to just fetch the branch
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #dri-devel
<daniels>
yeah, unless it's small and self-contained I always fetch it and mostly use tig to review
<javierm>
daniels: yeah, same for me. Fetch from patch-work the whole series, apply it in a branch and review the end result in my editor
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
devilhorns has quit []
jkrzyszt_ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
nchery has quit [Read error: Connection reset by peer]
kts has quit [Quit: Konversation terminated!]
cengiz_io has joined #dri-devel
karolherbst_ has joined #dri-devel
karolherbst_ is now known as karolherbst
kts has joined #dri-devel
itoral_ has quit [Remote host closed the connection]
<jani>
hwentlan_: what would it take to nuke the edid parsing from amdgpu_dm.c? it's just a dupe subset of what's in drm_edid.c
alyssa has left #dri-devel [#dri-devel]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
Peuc has joined #dri-devel
Peuc_ has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
dakr has joined #dri-devel
devilhorns has joined #dri-devel
mvlad has joined #dri-devel
fab has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
heat has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
camus has quit []
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
kts has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
<dcbaker>
hakzsam: hopefully next week, there’s a pretty bad nouveau regression that we’re trying to sort out, and I’m behind getting an rc out this week
<hakzsam>
ok
AndroUser2 has quit [Remote host closed the connection]
<robher>
netdev and bluetooth also have their own checks
kts has quit [Quit: Konversation terminated!]
<Ristovski>
Is there a way to benchmark vram speed on amdgpu?
<tagr>
robher: yeah, I've seen at least that netdev adds a _lot_ of patchwork checks to their patches, which is quite neat
<tagr>
thanks for the links, I'll look at that
kts has joined #dri-devel
<robclark>
daniels: fwiw, the way we've been gluing gitlab together with kernel stone-tablet workflow is to send MRs to ourself, https://gitlab.freedesktop.org/drm/msm/-/merge_requests/19 .. which actually works reasonably well since I'm handling mostly the GPU+GEM stuff and abhinav__ and lumag the display stuff. (Also CI pipelines usually don't work outside of an MR context because you don't know what -external-fixes branch to pull in)
Duke`` has joined #dri-devel
tanty has quit [Remote host closed the connection]
devilhorns has quit [Remote host closed the connection]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
bcheng_ has quit [Remote host closed the connection]
bcheng has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
rasterman has quit [Remote host closed the connection]
mbrost has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
rasterman has joined #dri-devel
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #dri-devel
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
karolherbst: ack on merging rusticl
<alyssa>
sorry I never got around to reviewing the code
<alyssa>
my only concern is added burden when changing the gallium api, since updating bindings can require legitimate engineering effort and not just a coccinelle script
<alyssa>
but given you're not going anywhere and can helpw ith that, it's probably okay
<alyssa>
and given that CL requires a much smaller API surface area than GL
* alyssa
is skimming through the patchset, so far it looks great
<alyssa>
the heck is cles_khr though
<alyssa>
did i miss OpenCL ES this? yikes :p
ybogdano is now known as Guest1829
ybogdano has joined #dri-devel
<karolherbst>
alyssa: yeah.. but it's mostly CL with lower reqs
<karolherbst>
and more optional stuff
<karolherbst>
you advertise your device as embedded and now you are doing CL ES
<alyssa>
Ah
<alyssa>
"rusticl/kernel: WIP some cleanups" ... squash?
<alyssa>
robclark: I think this can be handled outside of isaspec abstractly like:
<alyssa>
encode: encode full length instruction with isaspec. if (instruction->op has a short encoding && encoded_form[-skipped_bytes[instruction->op]:] == 0) { unset length bit and pack the short form } else { pack the long form }
<karolherbst>
tesla and fermi also have short encodings :/
<alyssa>
decode: decode the bottom 2 bytes of the instruction to get the opcode. if (op has a short encoding && length bit [bit 15] not set) { artifically set the length bit, pad out in memory, and decode that with isa spec } else { decode with isaspec as is }
<karolherbst>
alyssa: I think isaspec seriously needs a builtin opcode field
<karolherbst>
_but_
<karolherbst>
what if your opcode is also variable
<alyssa>
The issue with this approach is that the (opcode enum, physical opcode value, short encoding supported, number of skipped bytes in short encoding) table needs to be accessible
<alyssa>
isaspec doesn't have a good way to expose that information to C code
<karolherbst>
another issue with opcodes are: what if they are not static
<alyssa>
which means it would get opencoded out-of-band
<alyssa>
yeah
<karolherbst>
or well.. encode the form as part of the opcode
<alyssa>
ideally the long/short forms are handled in isaspec directly
<alyssa>
where you still have enough information to do it 'properly'
<alyssa>
though isaspec is pretty small. maybe I could extend to do what I want.
<karolherbst>
isaspec really falls apart once positioning of stuff isn't static anymore :(
<alyssa>
karolherbst: I mean. Piles of <override> I guess.
<karolherbst>
"#alu_instruction" is such a beast :(
<alyssa>
karolherbst: quite.
<karolherbst>
I suspect we need a isaspec v2 and think about such issues from the start or something
<alyssa>
the thing is, I don't know how I would design isaspec differently to cater to so many ISAs
<karolherbst>
less assumptions
<karolherbst>
atm isapsec assumes everything is more or less static
ngcortes has quit [Remote host closed the connection]
<karolherbst>
and you also can't say "look, this field defines how sources are laid out"
<karolherbst>
we could e.g. add support for "forms" to isaspec
<alyssa>
"nvir: add isaspec files for ampere"
<karolherbst>
and for isas not having it, they always have a default form or something
<alyssa>
does this not work?
<alyssa>
or is it just aesthetically bad?
<robclark>
karolherbst: not having an opcode field was pretty deliberate ;-)
<alyssa>
because it's guaranteed better than src/panfrost/bifrost/ISA.xml
<karolherbst>
alyssa: it works, but I didn't write a compiler on top
<karolherbst>
but you see that I overwrite bit meanings and stuff
<karolherbst>
and I have to define all bits outside of the override handling
<robclark>
since we have cases where different groups of instr have different size opc... and some cases where they squeezed in a few new opc bits in some different part of teh instruction
<karolherbst>
it's quite messy
<karolherbst>
robclark: yeah...
<karolherbst>
could have an opcode size per instruction
<alyssa>
karolherbst: See +BRANCH.f16 in that file for a particularly pathological example
<karolherbst>
but then it becomes really messy
<karolherbst>
uhhh
<karolherbst>
what's swap doing btw?
<alyssa>
swap source[left] and source[right] if the specified condition holds and rewrite [name] by mapping value [from] to value [to]
pcercuei has quit [Read error: Connection reset by peer]
Dr_Who has joined #dri-devel
<karolherbst>
but yeah.. for the nvidia ISA I really need some first level support for forms :(
<yang>
Ristovski: Device: Mesa Intel(R) HD Graphics 400 (BSW) (0x22b1)
<karolherbst>
alyssa: ahh
pcercuei has joined #dri-devel
<Ristovski>
yang: Yeah the files shouldn't be needed then. BSW is Gen8, GuC/HuC is afaik Gen9+
<alyssa>
in this case, rewrite `a < b` to `b > a` in certain cases due to asymmetric encoding
<alyssa>
IDK. I'd really rather not NIH isaspec
<alyssa>
again
<yang>
Ristovski: ok
<alyssa>
if there's an extension I can make that will get it to work for the ISAs I care about, then that's what I want to do
<karolherbst>
alyssa: yeah...
Dr_Who has quit []
<alyssa>
but IDK what extension that would be at this point
<alyssa>
I guess I should give a try at modeling CEU with isaspec
<alyssa>
since that's easy and regular
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
gouchi has quit [Quit: Quitte]
Haaninjo has joined #dri-devel
nchery has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
nchery has joined #dri-devel
nchery is now known as Guest1834
nchery has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]
<alyssa>
nope too tricky to do nicely ..
Guest1834 has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
AndroUser2 has joined #dri-devel
iive has joined #dri-devel
flto has quit [Quit: Leaving]
flto has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
warpme___ has quit []
mvlad has quit [Remote host closed the connection]
jljusten has quit [Ping timeout: 480 seconds]
pallavim_ has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
<HdkR>
Is there a good way to spin up a temporary XServer for CI? Maybe with the ability to capture a screenshot
<HdkR>
I usually just do a terrible thing of auto logging in a user so a DE can auto setup
<alyssa>
is zink+radv+drm-shim expected to work?
<alyssa>
zmike: ^^
<zmike>
what is "shim"
<zmike>
and what is the context of your question
<alyssa>
src/amd/drm-shim
<zmike>
I have no idea what that is
<alyssa>
zmike: I want to compile GLSL shaders through ACO and see the disassembly
<alyssa>
I have no AMD hardware.
<zmike>
I would expect zink to work anywhere radv works
<alyssa>
Usually you can use drm-shim with a GL driver to mock out the hw
<zmike>
TIL
<alyssa>
but radeonsi doesn't support ACO for some reason
<alyssa>
and IDK if radv + drm-shim works
<zmike>
probably just haven't flipped the switch there
<zmike>
I'm sure it's trivial
<alyssa>
or more to the point if radv + zink + drm-shim does
<zmike>
you'll be the first person to try it I'd guess
<alyssa>
I guess amd/drm-shim is for r300 and r600
<alyssa>
neither of which is vulkan capable
<alyssa>
(is the UAPI the same? idk)
<alyssa>
DRM_RADEON vs DRM_AMDGPU. joy.
Dr_Who has joined #dri-devel
<pendingchaos>
there's radv's RADV_FORCE_FAMILY stuff, which works similar to drm-shim
<pendingchaos>
if that doesn't work, there's zink+lavapipe+fossilize then radv/null-device+fossilize
<alyssa>
pendingchaos: oh, interesting
<daniels>
HdkR: most of the traces in CI do run against Xvfb. for Xorg you’d really need a full VM to own the TTY, but you can look at Weston for how to do that
<HdkR>
daniels: Interesting, I've never looked at Weston
<alyssa>
pendingchaos: something like "VK_ICD_FILENAMES=/home/alyssa/mesa/build/src/amd/vulkan/radeon_icd.aarch64.json LIBGL_DRIVERS_PATH=~/lib/dri/ RADV_FORCE_FAMILT=HAWAII"?
AndroUser2 has quit [Read error: No route to host]
AndroUser2 has joined #dri-devel
<alyssa>
fighting the mesa loader, this will be too much magic to get working.
<alyssa>
i'll just wait for dschuermann to tell me if this shader is hard on aco :p
<alyssa>
pendingchaos: unless you're interested in seeing aco's spiller cry :p
<pendingchaos>
I don't know what the LIBGL_DRIVERS_PATH is for, so I don't know about that
<pendingchaos>
that .json file probably uses an absolute path, so you'll want point to the installed one instead, or use radeon_devenv_icd.x86_64.json omstead
<pendingchaos>
you mispelled RADV_FORCE_FAMILY, and (if you're just picking a random family) HAWAII sounds old
<alyssa>
LIBGL_DRIVERS_PATH was for the zink side
<alyssa>
i fixed the devenv and family
<alyssa>
noted on hawaii
<alyssa>
though strace says it's not even getting to zink
<zmike>
you need MESA_LOADER_DRIVER_OVERRIDE=zink
AndroUser2 has quit [Read error: Connection reset by peer]
<alyssa>
zmike: ack, though it wasn't getting that far
<alyssa>
I have no render nodes
<zmike>
also you need to LD_LIBRARY_PATH to the libglx you built zink from
<alyssa>
and the loader doesn't like that
<alyssa>
ack, still not that far
<zmike>
I don't think lavapipe should care about render nodes
jljusten has joined #dri-devel
<zmike>
though if you're not using lavapipe then no render nodes is a problem
<alyssa>
not lavapipe
<alyssa>
radv with null winsys
AndroUser2 has joined #dri-devel
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #dri-devel
alyssa has quit [Quit: leaving]
Duke`` has quit [Ping timeout: 480 seconds]
bcheng has quit [Remote host closed the connection]
bcheng has joined #dri-devel
jewins has joined #dri-devel
gio has quit [Ping timeout: 480 seconds]
tango_ has quit [Quit: I'm never quite so stupid as when I'm being smart (Linus van Pel)]
tango_ has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
danvet has quit [Ping timeout: 480 seconds]
Dr_Who has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
nchery has joined #dri-devel
AndroUser2 has quit [Ping timeout: 480 seconds]
AndroUser2 has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]