03:51 SolarAquarion: the intel Xe GPU's sounds like a godsend
03:53 HdkR: As with any product, wait for reviewers to thoroughly break them in before purchasing
03:54 SolarAquarion: HdkR: but knowing intel the firmware package and such won't be locked behind a signed binary
03:54 HdkR: Sure
03:54 HdkR: But if the hardware is buggy AF then it would be unusable :P
03:54 SolarAquarion: Honestly most of the hardware accelerated video stuff is already open sourced with firmware's
03:54 SolarAquarion: True, lmao.
03:57 SolarAquarion: HdkR: yes, yes, but, at least most of the stacks that locked behind the signed nvidia driver is already open sourced so that's a plus
03:57 SolarAquarion: which means the updates for Xe will be in the intel stack
03:57 HdkR: Of course
03:58 SolarAquarion: plus, like the documentation on the driver is out there, it's not a black box, like there's already a CUDA like service in development
03:59 SolarAquarion: https://www.phoronix.com/scan.php?page=news_item&px=Intel-ZLUDA-CUDA-For-GPUs
04:01 HdkR: zluda is pretty awesome
04:01 SolarAquarion: https://spec.oneapi.com/level-zero/latest/index.html
04:02 SolarAquarion: this is the entire spec of the CPU/GPU
04:02 SolarAquarion: so better then Nvidia, which means reclocking and everything else will be there day 1
04:03 HdkR: I'm not doubting the ecosystem isn't going to be immediately better
04:04 SolarAquarion: but, hopefully the first dGPU's are not trash. I want to get the high end/gaming GPU, if it's as good as the 1080/2080 it'll be good enough
04:04 SolarAquarion: it seems the first one for laptops is going to be equivalent to the worst nvidia GPU of 2015
04:05 HdkR: Xe Max? That's already out
04:05 SolarAquarion: which is going to be great for older people who just want to use their 4k monitors
04:05 SolarAquarion: no, it's not, afaik
04:06 SolarAquarion: HdkR: Xe Max is only for laptops
04:06 HdkR: The Acer Swift 3X with Xe Max can already be purchased
04:08 SolarAquarion: HdkR: like, i said laptops
04:08 HdkR: That's why I responded to the statement for "first one for laptops"
04:09 SolarAquarion: yep, 2021 is when the Intel Xe's are going to be able to be bought in stores like MicroCenter for enthusiasts
04:09 HdkR: Because yes, it's already out and you get 96 EU tied to 4GB of VRAM. Which is a slight improvement for laptop users
04:13 SolarAquarion: Xe-HPG is the one i'm looking forward too
04:17 airlied: HdkR: can be purchased like 6900s?
04:17 airlied:doubts it's a real product yet
04:18 airlied:is looking at X stipple on what I assume is an XeMax
04:19 HdkR: airlied: Yea, you'd probably be importing from somewhere atm
04:23 airlied:can see swift3x ads but noting in the store here
04:37 HdkR: airlied: https://store.acer.com/en-sg/swift-3-sf314-510g-799x Purchased direct?
04:37 HdkR: It's very much a regional problem atm
04:46 airlied: I should get someoen in sg to get me one :-P
05:07 HdkR: Probabl easier to wait a month or two instead :P
10:00 tm512: so I know nouveau's performance tends to not be great relative to nvidia's proprietary driver, but I'm wondering how the performance compares to intel's integrated graphics with their driver
10:01 HdkR: Performance is bad because of clocking. Intel would perform better in a lot of cases
10:01 tm512: I might have a chance to get a GTX 750 off of a friend for free or pretty cheaply, not keen on using nvidia's proprietary driver though
10:01 tm512: I read somewhere that reclocking is supported on older GPUs, I'm not sure if 7xx is "old enough" though
10:02 HdkR: It's Maxwell1 so it at least doesn't need Nvidia to give signed firmware blobs
10:04 HdkR: Which is always the issue for anything newer. Nvidia is at fault for the bad performance, not Nouveau
10:06 tm512: heh, if I'm ever going to buy a proper discrete GPU I certainly wouldn't go with nvidia, especially since it seems like AMD has a good open source driver at this point
10:07 tm512: but I'd take this GTX 750 if nouveau supports reclocking it
10:11 tm512: well sounds promising: https://www.phoronix.com/scan.php?page=news_item&px=Nouveau-Engine-Reclock-V5
11:08 RSpliet: tm512: I think it should work for this generation of GPUs, but bear in mind it's all manual. No load-based automatic DVFS fanciness, just a lever in debugfs to let you pick one of two/three modes.
11:10 karolherbst: ahh yeah... maybe I should get back to those patches :D
11:10 karolherbst: but there isn't much we can do anyway
11:10 karolherbst: tm512: yeah, any gm10x GPU should reclock just fine (tm)
11:10 RSpliet: karolherbst: someone needs to figure out how to not make the screen blink on a DRAM clock change.
11:11 karolherbst: RSpliet: yeah.....
11:11 karolherbst: well.. we know how though
11:11 karolherbst: we just need to implement it
11:11 RSpliet: karolherbst: do you? it's something to do with the NISO buffer
11:11 RSpliet: or that's what it's used to be called on pre-GF119
11:11 karolherbst: that sounds like we know the solution to me :p
11:12 karolherbst: but yeah, we just have to cache a few lines for scanout for the time VRAM is offline
11:12 RSpliet: we know what, not how... which registers are involved :-P
11:12 karolherbst: yeah well.. we got some more docs from nvidia, I am sure the bits are actually documented by now
11:14 RSpliet: I would encourage you to lift that up on your todo list :-D
11:14 karolherbst: lol
11:14 karolherbst: still awaiting the time where I can do 100% random nouveau stuff :p
11:14 RSpliet: just like all the other items on your todo list by the way, they should all be at the top of the list!
11:15 karolherbst: like fixing multithreading? :p
11:15 RSpliet: Yep!
11:15 RSpliet: And more OpenCL fixes
11:15 RSpliet: Instruction scheduling
11:15 karolherbst: yeah.. actually I think the multithreading is like 1-2 weeks of work left
11:15 RSpliet: Everything :-D
11:15 RSpliet: Oh, Vulkan while we're at it!
11:15 karolherbst: it's actually not that brutal anymore as I have a good idea on how to fix it without having to change the world
11:15 RSpliet: That's encouraging to hear!
11:16 karolherbst: I just had to change my desktop environment yesterday as the one I was using for years just became unusable
11:17 RSpliet: (That being said, nothing personal, but it might be too little too late. I'm thinking of upgrading to a 4K monitor, and Kepler isn't going to drive that... and not putting up with the whole no-PMU-firmware situation so if I need to choose today I'd chose team red)
11:17 karolherbst: yeah, sure
11:17 karolherbst: as a linux user I'd do the same
11:19 RSpliet: At this point they're just leading me on... I think it's time to draw my conclusions and start dating other GPU vendors :-P
11:20 tm512: hmm, well I'll probably get this GTX 750 from my friend then. I guess if I do run into issues with nouveau I could probably swallow my pride and go with the proprietary driver, but I resent proprietary software and I'm worried about how futureproof a binary blob that can't be recompiled/relinked actually is
11:21 tm512: can't really rely on nvidia to keep GTX 750 support around forever
11:21 tm512: and I don't upgrade very often. I'd probably be stuck on an outdated driver eventually
11:21 RSpliet: tm512: I suspect Maxwell is next on the list for being "legacy hw". Wonder whether you'll see Wayland support for it on the blob.
11:22 karolherbst: RSpliet: there already is wayland suport
11:22 RSpliet: is there? oh I missed that
11:22 karolherbst: yeah, for over a year already
11:22 karolherbst: just need to enable kms
11:22 karolherbst: it won't give you GLX/EGL with legacy X clients
11:22 RSpliet: thought they had all this trouble with EGL buffer extensions that they tried to push through but never did
11:22 karolherbst: so it's mostly useless
11:22 karolherbst: _but_ :p
11:23 RSpliet: (for all the resistance from the OSS world)
11:23 tm512: I still use Xorg, never really looked into wayland
11:23 tm512: since I'm pretty happy with the dwm setup I have currently
11:23 karolherbst: personally I stopped caring about X
11:23 karolherbst: it's like software from 2000
11:23 karolherbst: well.. 1990
11:24 karolherbst: if you have two displays with mixed DPI you already can't use X
11:24 karolherbst: so.. why even bother anymore
11:24 RSpliet: X.org is from 2004, X goes waaay back
11:24 RSpliet: but the last release was in 2018
11:24 tm512: I'm still a single-monitor pleb
11:24 RSpliet: So as Phoronix put it: abandonware :-D
11:24 karolherbst: RSpliet: I meant on a feature level it's form 1990 :p
11:25 karolherbst: tm512: and that any application can just record your screen and record all your key events
11:25 RSpliet: tm512: oh so am I. My monitor is older than X.org 1.0
11:25 karolherbst: no idea why I would even want to use software like this
11:25 tm512: karolherbst: seems more like on an architectural level, with newer features just piled on top or crammed in
11:25 karolherbst: no, it's really from the 1990
11:26 karolherbst: X is fundamentally just broken and there are just enough workarounds to make it somewhat work
11:26 karolherbst: but...
11:26 karolherbst: what is actually anything X supports what is considered "modern"
11:26 karolherbst: I can't think of anything
11:27 tm512: things like DRI and compositing are from like the 00s right?
11:27 karolherbst: I meant user facing features
11:27 RSpliet: tm512: the architecture of X.org doesn't allow decent security measures like not grabbing others framebuffers or inputs. One might say the X protocol doesn't allow it, I know too little about it - but there's a reason why the Wayland protocol was done from the ground up.
11:28 karolherbst: and there is XTEST to even inject random events
11:28 karolherbst: and distributions can't disable it
11:28 tm512: karolherbst: well that's mainly what DE/WMs and widget toolkits are for, no?
11:28 karolherbst: because "xdotools is broken 11!!11!"
11:28 karolherbst: tm512: nope
11:28 karolherbst: hotunpluggable GPUs is something X would have to support
11:29 karolherbst: but it can't
11:29 karolherbst: same goes for hiDPI
11:29 karolherbst: X can't
11:29 karolherbst: toolkits just worked around that issue
11:29 karolherbst: and that doesn't even work
11:29 RSpliet: karolherbst: with enough engineering effort I'm sure it can... but the clean slate approach turned out cheaper and more future-proof :-P
11:29 karolherbst: RSpliet: it can't
11:30 RSpliet: There's a point you cross the line of "is this still X?", but that's all semantics :-D
11:30 karolherbst: maybe the modesetting DDX _might_ be able to support hotunpluffable GPUs
11:30 karolherbst: but the native DDX?
11:30 karolherbst: no way
11:30 karolherbst: and then details like shared buffers and all that stuff
11:31 karolherbst: it's just so out of question
11:31 karolherbst: security wise X is also just broken and now way of fixing it without breaking all applications
11:31 karolherbst: so you can also just replace X completely
11:31 karolherbst: because fixing all the issues already means breaking the API
11:32 tm512: if I could copy my X setup over to wayland then maybe I'd consider switching at some point, ffmpeg has x11grab which I've been using an awful lot lately, not sure how I could screen capture from wayland if I switched
11:32 karolherbst: tearing, also unfixable
11:32 karolherbst: efficient display offloading, also unfixable
11:33 karolherbst: tm512: the compositor handles that
11:33 karolherbst: I know that mutter can
11:33 karolherbst: I even tested WebRTC yesterday
11:33 karolherbst: just works
11:33 karolherbst: the thing is, with wayland the compositor is the one allowing/denying requests, so you get some nice popup to approve the requests
11:33 karolherbst: and that's how it should have been all the time
11:34 karolherbst: not agreeing with everything on how wayland was designed, but it at least brings the linux desktops into 2010
11:35 tm512: er, handles what? ffmpeg needs a way to get the pixel data for recording, it seems like I'd need to use the kmsgrab input device, doesn't seem like there's anything specifically for capturing from wayland
11:35 tm512: also thought wayland was Linux only, and while I'm not using a BSD desktop currently I'd like to keep that option open, but seems like it's finally been (unofficially) ported
11:37 tm512: kmsgrab sounds like it'd cause permissions issues, dunno if just having my user in the 'video' group would give me access to the device
11:37 karolherbst: no
11:37 karolherbst: you want to have to enter your pw to approve that
11:37 karolherbst: that's the entire point
11:37 karolherbst: or something else "acking" it
11:38 karolherbst: obs seems to support screenrecording through wayland as well already
11:38 karolherbst: so ffmpeg can also just support it if they actually wanted to
11:42 tm512: I don't really want to enter my password every time I want to record or stream. I don't have to with my current setup using x11grab
11:42 karolherbst: that's a ffmpeg limitation
11:45 karolherbst: but you can also use the X api
11:50 karolherbst: but yeah.. it's all a bit annoying atm, as software still needs to port over and stuff
11:50 karolherbst: oh well
11:50 karolherbst: maybe in 5 years
11:52 tm512: I'm not exactly fond of X, but I am used to it, heh
11:52 tm512: I guess it's pretty impressive how much staying power it's had
11:53 karolherbst: RSpliet: yeah lol.. moved to turing with my new laptop, the CL stuff still works :D I am kind of surprised that I didn't completely screw up :D
11:54 karolherbst: the thing I am most worried about though is recovery which I think is still busted
11:54 RSpliet: If it's better than before, it's progress!
11:54 RSpliet: \o/
11:55 karolherbst: maybe I get the CL 1.2 stuff in soonish
11:55 karolherbst: just have to tidy up my inline sampler patch