ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
tzimmermann__ has joined #dri-devel
tzimmermann_ has quit [Ping timeout: 480 seconds]
_whitelogger has joined #dri-devel
tarceri has quit [Server closed connection]
tarceri has joined #dri-devel
DanaG has quit [Remote host closed the connection]
znullptr[m] has joined #dri-devel
DanaG has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
pcercuei has quit [Quit: dodo]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
lemonzest has joined #dri-devel
DanaG has quit [Remote host closed the connection]
DanaG has joined #dri-devel
mripard has joined #dri-devel
DanaG_ has joined #dri-devel
mripard_ has quit [Ping timeout: 480 seconds]
adjtm has quit [Remote host closed the connection]
DanaG_ has quit [Quit: Leaving]
heat has joined #dri-devel
mhenning has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
adjtm has joined #dri-devel
mhenning has quit [Quit: mhenning]
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
Duke`` has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
Haaninjo has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
rpigott has quit [Read error: Connection reset by peer]
rpigott has joined #dri-devel
MajorBiscuit has joined #dri-devel
gouchi has joined #dri-devel
i-garrison has joined #dri-devel
garrison has quit [Read error: Connection reset by peer]
danvet has joined #dri-devel
rasterman has joined #dri-devel
Lucretia has quit []
Lucretia has joined #dri-devel
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
pcercuei has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
gouchi has quit [Remote host closed the connection]
kts has joined #dri-devel
khfeng has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
gouchi has joined #dri-devel
khfeng has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
ds` has quit [Quit: ...]
ds` has joined #dri-devel
kts has joined #dri-devel
kts_ has joined #dri-devel
kts_ has quit []
kts has quit [Quit: Konversation terminated!]
iive has joined #dri-devel
kts has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
heat has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
alarumbe has quit [Remote host closed the connection]
<karolherbst> dcbaker: do we have a way to specify the rust edition used?
<karolherbst> or well.. version even
<dcbaker> The edition can be set in the default options with `rust_std=2018` (or whatever) just like c and c++
<karolherbst> ahh
<dcbaker> And you can add the same value to the target’s `override_options` if you need to change it for a specific target
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
mriesch has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
mriesch has joined #dri-devel
tzanger has quit [Ping timeout: 480 seconds]
alarumbe has joined #dri-devel
ella-0_ has joined #dri-devel
DanaG has quit [Remote host closed the connection]
ella-0 has quit [Read error: Connection reset by peer]
alarumbe has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
DanaG has joined #dri-devel
alarumbe has joined #dri-devel
<DanaG> Is anyone familiar with the ast kernel module? Not sure whether this is the right place, or something else is, but KDE and Gnome both crash with the same innermost level of stacktrace if I try to start a wayland session on a machine that has AST + AMDGPU.
<DanaG> The innermost stacktrace level is a function called gbm_dri_bo_import.
<imirkin> sounds like a userspace issue
<imirkin> not specifically related to the "ast" kernel module
<imirkin> ast being a display-only device probably trips things up?
<karolherbst> imirkin, DanaG: there are or were prime related issues with AST
<karolherbst> and userspace tripping when assumptions are not met
<imirkin> yeah, like no accel presumably
<karolherbst> I think those issues were resolved, so with a recent enough userspace stack that should be all fixed
<karolherbst> imirkin: no
<karolherbst> so there were an issue if the main GPU doesn't support prime, but the other does
<karolherbst> like gnome tries to create a GL context for both devices, which usually succeeds, as you just get llvmpipe on non accel devices, but then it tries to actually share stuff for offloading etc.. and then things break randomly
<karolherbst> at least I think it was something like that
<karolherbst> but I think those issues were fixed and updating to newest gnome could run better here
<karolherbst> or well.. should
<imirkin> ah ok
<imirkin> well, my initial assumption was right
<imirkin> the fact that ast is display-only trips things up :)
<karolherbst> heh..
<karolherbst> I think it's more the "no prime support" part, but maybe that
<imirkin> ah yeah. that makes more sense actually
<imirkin> harsh.
<karolherbst> imirkin: ohhhh nooo. I remember now
<imirkin> [to not support prime, in this day and age]
<karolherbst> you got 3d on the same GPU twice :)
<imirkin> 6d!
<karolherbst> no it was more annoying like that
<karolherbst> soooo this was funny as I actually hit it on intel + nouveau
<karolherbst> nouveau fails to do 3D, because of.. ampere
<karolherbst> fallsback to software and finds.. lavapipe :)
<karolherbst> so it uses intels vulkan thing as the 3D stuff for nouveau
<karolherbst> so you have iris on the intel gpu and lavapipe+anv on the nvidia gpu
<karolherbst> anyway.. all of those issues I know of have been fixed afaik
<karolherbst> maybe it's something more annoying now :D
<karolherbst> DanaG: I'd suggest trying with newest mesa + newest gnome and see if that helps
kts has quit [Quit: Konversation terminated!]
<karolherbst> anyway.. there were many issues
sravn has quit []
JohnnyonFlame has joined #dri-devel
natto has quit []
natto has joined #dri-devel
mhenning has joined #dri-devel
<DanaG> I should check what Windows does on that device. After all, I need to boot Windows to use the SSD firmware updater tool anyway.
danvet has quit [Ping timeout: 480 seconds]
<DanaG> ASPEED is such a nonsense name, it should be more like ASLOWNESS
<DanaG> I wish there were a modern equivalent of the Radeon-based BMCs. Even if it didn't have 3D, it would at least have modesetting and PRIME.
<HdkR> Don't worry, the ASPEED2600 upgrades from a single core ARM to a triple core ARM. Also doubling the ram from 1GB to 2GB. Obviously it will be 2-3x speedier :P
<imirkin> DanaG: aspeed is that equivalent
<imirkin> DanaG: userspace has moved on
<DanaG> I found that KDE and Gnome were *both* crashing in the same function, gbm_dri_bo_import.
<karolherbst> DanaG: yeah, probably because hybrid GPUs and one not supporting prime doesn't match well
<karolherbst> but I suspect you are not running updated software as I think we fixed those crashes
<karolherbst> maybe you hit a new bug though
<imirkin> DanaG: yeah... but they both should know not to call that function
<karolherbst> DanaG: ohh btw, I also know about some machines where the uefi graphics stuff is implemented incorrectly, so that could be another issue
<imirkin> or something.
<karolherbst> logs/stacktraces might help figuring this out
<imirkin> DanaG: basically you have a unique setup, so you get to deal with the pieces.
<karolherbst> imirkin: I wish it would be unique :(
<imirkin> yeah, i bet RH is paid to support some of that stuff
<karolherbst> you'd win that bet
<imirkin> but i'm equally betting the gnome devs don't test on that very often
<karolherbst> yeah...
<DanaG> I can pastebin a stacktrace of both KDE and Gnome.
<DanaG> I filed an ubuntu bug, but really I should stop being lazy and file it upstream.
<DanaG> And oddly, it didn't attach the backtrace.
<imirkin> the problem is that someone has to expend effort to sort out where the problem is
<imirkin> every project assumes it's a different project's fault
<imirkin> unless proven otherwise
<pinchartl> we should create one library whose purpose is to gather all faults. then all the other projects would be bugless
<pinchartl> and there would be a single source of problems to fix
<pinchartl> that reminds me of a story my brother told me, when he was a teacher assistant for a java programming course. a student asked him for help, to fix a compilation error that they couldn't get rid of. my brother has a look, and quickly saw that there was a missing semicolon at the end of a line. he proceeded to add it, and the student screamed, telling him not to do that. he was puzzled and asked why,
<pinchartl> and got told to try. so he did, and the compiler then spat 400 error messages. the student said, proudly, that they managed to fix all errors but the one caused by the missing semicolon
<imirkin> heheh
<DanaG> oh, silly me, I went to look at the crashes, and ended up accidentally looking at a different KDE crash (plasmashell on an arm64 machine, sometimes dies when changing themes)
* airlied deals with ast but only in the sense of having an ast and nothing else :-P
<imirkin> i only deal with the abstract syntax tree variant :)
<airlied> you plug in a real GPU, and you still have the ast active life is hard
<DanaG> Next time around, screw server boards, I'll go desktop board with serial port, and use pikvm.
<airlied> you can just xorg.conf your way out of it with X
<DanaG> This Asrock X570 server board also fails to support serial-over-lan properly in the IPMI.
<airlied> like if you just want to use a GPU, there can often be BIOS options to just enable PCIE primary
<karolherbst> airlied: oh boi do I have bad news for you
<karolherbst> although yeah, I guess firmware _should_ disable the AST GPU once something else gets plugged in
<karolherbst> airlied: we shouldn't crash though :/
<karolherbst> I bet the issue is something stupid
<karolherbst> but most likely also fixed
<DanaG> I do have an option to disable the discrete, but sometimes I'd like to be able to switch between the two without rebooting. Like, "oh, I randomly feel like using that machine and the Radeon today."
<karolherbst> DanaG: we wished for an option to disable the AST one though
<DanaG> But other times, I want to only use it headless, and leave the Radeon in powersave mode.
<karolherbst> DanaG: what version of gnome is running?
<DanaG> I'll check once it finishes rebooting from the Windows firmware update. Looks like Windows allows extended desktop mode only, no clone mode.
<karolherbst> anyway.. I was under the impression I was running into similiar issue and bugged people enough to fix those, so my expectation is that newest mesa + newest gnome should be fixed
<DanaG> Windows tool doing SSD firmware update, I mean.
<karolherbst> but not sure
<DanaG> I can try a PPA for Mesa, perhaps.
<karolherbst> would have to find the bugs and fixes first to tell when stuff got fixed
<karolherbst> airlied: do you remember when that issue got fixed where mesa loaded lavapipe on the GPU without accel?
<DanaG> libgl1-mesa-dri 21.2.6-0ubuntu0.1
famfo has quit []
<karolherbst> ehh wait.. I search for the wrong thing
<karolherbst> I meant zink
<DanaG> argh, apport is deleting the .crash file.
<DanaG> "it's been uploaded, so surely you don't need it anymore, right?"
famfo has joined #dri-devel
<DanaG> Okay, got a more useful result with systemd-coredump. https://pastebin.com/BjkWAFxm
<DanaG> It would be nice to be able to actually use PRIME with the ast. That is, connect to server via ast, yet still be able render stuff (even if slowly due to bottleneck) on the Radeon.
<DanaG> Interestingly, if I don't have a monitor on the Radeon, and I boot Windows, I can run Vulkan demos on the Radeon and have the output dumped to the AST.
<karolherbst> DanaG: mhh yeah so.. theoretically one could try to support display offloading for no accel display GPUs. I think nobody really cared, because using the discrete GPU directly will be faster
<DanaG> Wouldn't surprise me if the aspeed is slow enough that you can't actually DMA every frame from the Radeon to the aspeed. Might have to either DMA in the other direction (slow thing read from fast thing, causing tearing), or only push every Nth frame to the slow thing.
<karolherbst> I think the bigger concenr is running a feature rich compositor on top of AST, because the compositor itself is also doing things
<karolherbst> and burns CPU cycles
<karolherbst> using the Radeon card directly is probably more energy efficient anyway
<DanaG> That reminds me, when Vista Aero first came out, everyone was all, "oh, disable Aero to save power!" Oh really? Then why does my laptop battery watt meter read lower with it *enabled?* Answer: because efficient GPU drawing is better than slow CPU drawing.
<airlied> I do wonder if the ast has a dma engine, however I've no idea how to expose it for prime use
<karolherbst> DanaG: yep
<DanaG> Great, now the ast is giving me no signal at all. Go figure.
<DanaG> Sometimes it just does that. Have to reboot to get it back, even reloading `ast` doesn't do it.
<karolherbst> DanaG: well, the AST GPUs aren't supposed to be used
<DanaG> Calling them GPUs is giving them too much credit.
<karolherbst> there are just there so one can tick a check mark for "debugging with GUI is possible" :p
<imirkin> s/with/the/
rasterman has quit [Quit: Gettin' stinky!]
<DanaG> oh, that's interesting... if I boot with Radeon disconnected, then log in to KDE via IPMI, then connect the Radeon, I can use clone mode, and no crash (since it's using llvmpipe).
gouchi has quit [Remote host closed the connection]
<DanaG> I'm trying ppa:kisak/kisak-mesa now, to see if that changes anything.
Haaninjo has quit [Quit: Ex-Chat]
<DanaG> Okay, that makes KDE start (with swrast only), but Gnome still crashes. Going to be AFK for a while, though.
sdutt has joined #dri-devel
yogesh_mohan has quit [Server closed connection]
yogesh_mohan has joined #dri-devel
<DanaG> Gnome on X11 just gives a blank screen with a cursor.
Duke`` has quit [Ping timeout: 480 seconds]
<DanaG> Mar 20 15:25:47 danaserver gnome-shell[131178]: cr_parser_new_from_buf: assertion 'a_buf && a_len' failed
<DanaG> Mar 20 15:25:47 danaserver gnome-shell[131178]: cr_declaration_parse_list_from_buf: assertion 'parser' failed
aissen has quit [Ping timeout: 480 seconds]
aissen has joined #dri-devel
Danct12 has quit [Server closed connection]
Danct12 has joined #dri-devel
DanaG has quit [Remote host closed the connection]
tarceri has quit [Server closed connection]
tarceri has joined #dri-devel
Surkow|laptop has quit [Remote host closed the connection]
Surkow|laptop has joined #dri-devel
<airlied> karolherbst: so clover could do with a nir_sweep somewhere then?
<karolherbst> airlied: directly after inlining and killing the other entrypoints
<karolherbst> and well.. once after all passes were ran
<karolherbst> airlied: anyway.. atm I am debugging some of extern kernel linking and I think it's broken
<karolherbst> not sure what exactly though
<karolherbst> I just know that's __spirv_BuiltInGlobalInvocationId value_type is never updated to _pointer :/
<karolherbst> airlied: for god sakes... I found the bug
<karolherbst> it's terrible
<karolherbst> airlied: the extern kernel doesn't list variables on OpEntryPoint :(
<karolherbst> so.. we don't process it
<karolherbst> mhhhh
<karolherbst> mhhhhh
<karolherbst> pfffff
<karolherbst> airlied: yeah... so it doesn't list variables from called kernels
<karolherbst> "The set of Interface <id> must be equal to or a superset of the global OpVariable Result <id> referenced by the entry point’s static call tree, within the interface’s storage classes"
<karolherbst> I understand it like that we have to list all potentially used ones walking the entire call tree
<karolherbst> *sigh* ignoring for now