05:24mooch2: so, i have a problem when using yuzu. when i run it with the blob, it runs at about 13 fps max in cap kingdom in super mario odyssey. but in nouveau, it runs at a few seconds per frame
05:24mooch2: any ideas why this might be?
05:24mooch2: my gpu is a gm107 btwe
05:24imirkin: are you reclocking?
05:26mooch2: how do i do that again?
05:27imirkin: echo 0f > /sys/kernel/debug/dri/0/pstate
05:27mooch2: also, lemme try again with the latest version of mesa lol
05:28mooch2: says permission denied, even with sudo
05:29mooch2: oops, that's because i gotta replace that 0 with a 1
05:29mooch2: for my config, anyway
05:30mooch2: nope, even then, bash gives me permission denied
05:32imirkin: you have to be root
05:32imirkin: (think for a moment what 'sudo' does)
05:33mooch2: i was root
05:33imirkin: then why use sudo?
05:33mooch2: and the thing is... if i run su - even with the same password
05:33mooch2: it doesn't work
05:33mooch2: linux mint 19
05:33imirkin: what kernel version?
05:34mooch2: according to uname -a
05:34imirkin: that should definitely be new enough
05:34imirkin: pastebin dmesg
05:36mooch2: ignore the stupid filename lol
05:37imirkin: no errors... i'm still assuming user error here
05:37mooch2: okay, what should i do next?
05:37imirkin: step 1: become root
05:37imirkin: step 2: echo 0f > /sys/kernel/debug/dri/1/pstate
05:37mooch2: i've tried su - with the same password i use for sudo
05:37imirkin: if you do it as one step
05:37mooch2: says authentication failure
05:38imirkin: then it's less likely to work
05:38imirkin: unless you do it carefully
05:38mooch2: i've also tried just straight up logging in as root in a tty
05:38mooch2: same thing
05:38imirkin: which you clearly aren't doing
05:38mooch2: um, how?
05:38imirkin: well, let me guess, you're doing "sudo echo 0f > /bla"?
05:38mooch2: no, i'm doing "su -" and then entering my password, and it doesn't fucking work
05:38mooch2: i already tried the sudo way
05:39imirkin: why would your password be the relevant one?
05:39imirkin: would be the root password...
05:39mooch2: i use the same password for both
05:39imirkin: try this: "sudo su -"
05:39mooch2: at least, both sudo and my regular account
05:39mooch2: wtf lmfao
05:39mooch2: that worked
05:39imirkin: moral of the story: you don't use the same password for both.
05:39mooch2: THAT WORKED
05:40mooch2: i seem to be reclocked
05:40imirkin: cat the file
05:40Sarayan: mooch2" What imirkin is hinting at is that the redirection is done by the "englobing" shell, and who you run the echo command as does not matter. There are tricks to use sudo in that care, but they're non-trivial. To be sure of the result you need to do the echo from a root shell
05:40imirkin: ensure that the "AC" (or "DC") line has the higher clock rate?
05:40mooch2: it does indeed
05:40imirkin: Sarayan: there's other clever ways one can do it, e.g. ensuring that the write is being done by sudo
05:40imirkin: some people like to use 'tee'
05:41imirkin: mooch2: ok, check if you get moar fps nwo
05:41mooch2: i'm on mesa 18.0.5 rn, but i'll check right now yeah
05:41imirkin: this is all unrelated to mesa
05:41imirkin: although updating could be helpful.
05:42Sarayan: imirkin: yeah, I tend to sudo sh -c 'blah > whatever' personally
05:42mooch2: yeah, i figured that updating might get me slightly higher fps lol
05:42imirkin: i tend to not have sudo set up in the first place, so none of this bs comes up :)
05:42Sarayan: imirkin: I have sudo as NOPASSWD: for me, it's nice
05:42imirkin: i just type "su -". problem solved.
05:43mooch2: i mean, this distro didn't give me the option to set a separate root password so lol
05:56mooch3: ...just then, yuzu completely fucking froze my computer
05:56imirkin: but it did it really fast, right? :)
05:56mooch3: nope lol
05:57mooch3: it took forever once i told it to resume from the save file
05:57mooch3: and then it froze EVERYTHING
05:57mooch3: except sysrq lol
05:57mooch3: at least performance was more consistent in the parts where it actually worked lol
14:25joepublic: So I went back and asked more questions about this china counterfeit "660ti". Apparently it was $65 too-good-to-be-true, and it was "too expensive" to send it back to china, so the seller gave a partial refund of something like $20. Whoever does that is pure evil, meaning they got $45 for a useless fake.
14:29Tentacles: hey guys! Vulkan API still no support?
14:30HdkR: I personally blame karolherbst for being to busy implementing OpenCL over NIR :P
14:32Tentacles: Is there any information about timing?
14:32HdkR: Timing of Vulkan support?
14:33HdkR: It's an open source project, not really much of a timeline for product features :P
14:33HdkR: Everything is better in 2025
14:33imirkin: what are the chances that much time will happen, anyways
14:33joepublic: How about some mpeg, 2d, and 3d accelleration for the Jetson TX2 while you're at it.
14:34imirkin: 2d/3d accel on TX2 should work, i think?
14:34HdkR: Someone actually cares about Jetson?
14:34HdkR:fishes Xavier out of the toilet
14:34joepublic: I care about the Jetson (it's on my to-buy list) but I am very, very unusual
14:35HdkR: You just want those hecking awesome Denver2 CPU cores I bet
14:35joepublic: I explore what's possible outside the realm of x86/AMD64 in fulfilling normal desktop and server roles.
14:36HdkR: I personally wouldn't use Jetson for that. Choose a more sane SBC :P
14:37joepublic: HdkR, any suggestions? It seems mostly slow rockchips in that arena.
14:37joepublic: And slower allwinner.
14:37HdkR: Hikey 970
14:38HdkR: If there is a Kirin 980 board then that would be pretty cool, but it is too new for that
14:40joepublic: hikey 970 has the kirin and has PCIe and usb3, that actually does look very interesting
14:41HdkR: I have a board, sadly haven't spent as much time on it as I would want
14:58joepublic: so many of these SBCs omit any sort of way to attach a sata device short of slow usb-to-sata
15:10imirkin: usb3 isn't _that_ slow
15:11joepublic: it makes a difference in the case of, for example, a stripe set of SSDs.
15:11joepublic: you are quite right that for most cases it's fine.
15:12imirkin: right, i mean i wouldn't use USB3 for my server's raid
15:13imirkin: but USB1 transfer speeds are a thing of the past
15:46karolherbst: HdkR: I know who to blame for that :p
15:47karolherbst: but I was also able to work on those multi context issues, which is important
15:47HdkR: What was the end result of that? I lost sight of the progress
15:47karolherbst: I wanted to get the one hardware channel solution to work as well
15:48karolherbst: I ran into some unexpected issues there, but I was talking with skeggsb about that
15:48HdkR: Basically get one hardware channel working well so that in the future it can be improved to handle multiple channels?
15:49HdkR: channels or subchannels I guess
15:49karolherbst: why using multiple channels if it works with one channel?
15:49HdkR: async compute comes to mind
15:49karolherbst: do we actually need that?
15:50HdkR: need no, want maybe
15:50karolherbst: for what?
15:51HdkR: I mean, if you can smash the graphics stack with regular work and have a compute kernel doing presentation work, that is a common use case in Vulkan now
15:51karolherbst: but that's vulkan
15:51HdkR: Sure, it can directly relate to GL as well though :P
15:52HdkR: It usually ends up being the case that you have some lightweight sidechannel work that doesn't have a direct timely requirement that you just want churning on an SM or so
15:52HdkR: and now with nanosleep you can have a work queue spinning on an SM, delegating work out to the rest of the GPU </s>
15:55karolherbst: but anyway, I think I will focus on what we have for now and the changes to fix using one hw channel isn't as big as moving to one channel per context
15:56HdkR: Which I believe is the smart way to do it. multiple channels with convolute it. Just fix the multi-context issues first :P
16:02karolherbst: anyway, I planned to continue to work on that this week