03:51SolarAquarion: the intel Xe GPU's sounds like a godsend
03:53HdkR: As with any product, wait for reviewers to thoroughly break them in before purchasing
03:54SolarAquarion: HdkR: but knowing intel the firmware package and such won't be locked behind a signed binary
03:54HdkR: Sure
03:54HdkR: But if the hardware is buggy AF then it would be unusable :P
03:54SolarAquarion: Honestly most of the hardware accelerated video stuff is already open sourced with firmware's
03:54SolarAquarion: True, lmao.
03:57SolarAquarion: 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:57SolarAquarion: which means the updates for Xe will be in the intel stack
03:57HdkR: Of course
03:58SolarAquarion: 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:59SolarAquarion: https://www.phoronix.com/scan.php?page=news_item&px=Intel-ZLUDA-CUDA-For-GPUs
04:01HdkR: zluda is pretty awesome
04:01SolarAquarion: https://spec.oneapi.com/level-zero/latest/index.html
04:02SolarAquarion: this is the entire spec of the CPU/GPU
04:02SolarAquarion: so better then Nvidia, which means reclocking and everything else will be there day 1
04:03HdkR: I'm not doubting the ecosystem isn't going to be immediately better
04:04SolarAquarion: 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:04SolarAquarion: it seems the first one for laptops is going to be equivalent to the worst nvidia GPU of 2015
04:05HdkR: Xe Max? That's already out
04:05SolarAquarion: which is going to be great for older people who just want to use their 4k monitors
04:05SolarAquarion: no, it's not, afaik
04:06SolarAquarion: HdkR: Xe Max is only for laptops
04:06HdkR: The Acer Swift 3X with Xe Max can already be purchased
04:08SolarAquarion: HdkR: like, i said laptops
04:08HdkR: That's why I responded to the statement for "first one for laptops"
04:09SolarAquarion: yep, 2021 is when the Intel Xe's are going to be able to be bought in stores like MicroCenter for enthusiasts
04:09HdkR: 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:13SolarAquarion: Xe-HPG is the one i'm looking forward too
04:17airlied: HdkR: can be purchased like 6900s?
04:17airlied:doubts it's a real product yet
04:18airlied:is looking at X stipple on what I assume is an XeMax
04:19HdkR: airlied: Yea, you'd probably be importing from somewhere atm
04:23airlied:can see swift3x ads but noting in the store here
04:37HdkR: airlied: https://store.acer.com/en-sg/swift-3-sf314-510g-799x Purchased direct?
04:37HdkR: It's very much a regional problem atm
04:46airlied: I should get someoen in sg to get me one :-P
05:07HdkR: Probabl easier to wait a month or two instead :P
10:00tm512: 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:01HdkR: Performance is bad because of clocking. Intel would perform better in a lot of cases
10:01tm512: 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:01tm512: I read somewhere that reclocking is supported on older GPUs, I'm not sure if 7xx is "old enough" though
10:02HdkR: It's Maxwell1 so it at least doesn't need Nvidia to give signed firmware blobs
10:04HdkR: Which is always the issue for anything newer. Nvidia is at fault for the bad performance, not Nouveau
10:06tm512: 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:07tm512: but I'd take this GTX 750 if nouveau supports reclocking it
10:11tm512: well sounds promising: https://www.phoronix.com/scan.php?page=news_item&px=Nouveau-Engine-Reclock-V5
11:08RSpliet: 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:10karolherbst: ahh yeah... maybe I should get back to those patches :D
11:10karolherbst: but there isn't much we can do anyway
11:10karolherbst: tm512: yeah, any gm10x GPU should reclock just fine (tm)
11:10RSpliet: karolherbst: someone needs to figure out how to not make the screen blink on a DRAM clock change.
11:11karolherbst: RSpliet: yeah.....
11:11karolherbst: well.. we know how though
11:11karolherbst: we just need to implement it
11:11RSpliet: karolherbst: do you? it's something to do with the NISO buffer
11:11RSpliet: or that's what it's used to be called on pre-GF119
11:11karolherbst: that sounds like we know the solution to me :p
11:12karolherbst: but yeah, we just have to cache a few lines for scanout for the time VRAM is offline
11:12RSpliet: we know what, not how... which registers are involved :-P
11:12karolherbst: yeah well.. we got some more docs from nvidia, I am sure the bits are actually documented by now
11:14RSpliet: I would encourage you to lift that up on your todo list :-D
11:14karolherbst: lol
11:14karolherbst: still awaiting the time where I can do 100% random nouveau stuff :p
11:14RSpliet: just like all the other items on your todo list by the way, they should all be at the top of the list!
11:15karolherbst: like fixing multithreading? :p
11:15RSpliet: Yep!
11:15RSpliet: And more OpenCL fixes
11:15RSpliet: Instruction scheduling
11:15karolherbst: yeah.. actually I think the multithreading is like 1-2 weeks of work left
11:15RSpliet: Everything :-D
11:15RSpliet: Oh, Vulkan while we're at it!
11:15karolherbst: 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:15RSpliet: That's encouraging to hear!
11:16karolherbst: I just had to change my desktop environment yesterday as the one I was using for years just became unusable
11:17RSpliet: (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:17karolherbst: yeah, sure
11:17karolherbst: as a linux user I'd do the same
11:19RSpliet: 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:20tm512: 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:21tm512: can't really rely on nvidia to keep GTX 750 support around forever
11:21tm512: and I don't upgrade very often. I'd probably be stuck on an outdated driver eventually
11:21RSpliet: 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:22karolherbst: RSpliet: there already is wayland suport
11:22RSpliet: is there? oh I missed that
11:22karolherbst: yeah, for over a year already
11:22karolherbst: just need to enable kms
11:22karolherbst: it won't give you GLX/EGL with legacy X clients
11:22RSpliet: thought they had all this trouble with EGL buffer extensions that they tried to push through but never did
11:22karolherbst: so it's mostly useless
11:22karolherbst: _but_ :p
11:23RSpliet: (for all the resistance from the OSS world)
11:23tm512: I still use Xorg, never really looked into wayland
11:23tm512: since I'm pretty happy with the dwm setup I have currently
11:23karolherbst: personally I stopped caring about X
11:23karolherbst: it's like software from 2000
11:23karolherbst: well.. 1990
11:24karolherbst: if you have two displays with mixed DPI you already can't use X
11:24karolherbst: so.. why even bother anymore
11:24RSpliet: X.org is from 2004, X goes waaay back
11:24RSpliet: but the last release was in 2018
11:24tm512: I'm still a single-monitor pleb
11:24RSpliet: So as Phoronix put it: abandonware :-D
11:24karolherbst: RSpliet: I meant on a feature level it's form 1990 :p
11:25karolherbst: tm512: and that any application can just record your screen and record all your key events
11:25RSpliet: tm512: oh so am I. My monitor is older than X.org 1.0
11:25karolherbst: no idea why I would even want to use software like this
11:25tm512: karolherbst: seems more like on an architectural level, with newer features just piled on top or crammed in
11:25karolherbst: no, it's really from the 1990
11:26karolherbst: X is fundamentally just broken and there are just enough workarounds to make it somewhat work
11:26karolherbst: but...
11:26karolherbst: what is actually anything X supports what is considered "modern"
11:26karolherbst: I can't think of anything
11:27tm512: things like DRI and compositing are from like the 00s right?
11:27karolherbst: I meant user facing features
11:27RSpliet: 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:28karolherbst: and there is XTEST to even inject random events
11:28karolherbst: and distributions can't disable it
11:28tm512: karolherbst: well that's mainly what DE/WMs and widget toolkits are for, no?
11:28karolherbst: because "xdotools is broken 11!!11!"
11:28karolherbst: tm512: nope
11:28karolherbst: hotunpluggable GPUs is something X would have to support
11:29karolherbst: but it can't
11:29karolherbst: same goes for hiDPI
11:29karolherbst: X can't
11:29karolherbst: toolkits just worked around that issue
11:29karolherbst: and that doesn't even work
11:29RSpliet: karolherbst: with enough engineering effort I'm sure it can... but the clean slate approach turned out cheaper and more future-proof :-P
11:29karolherbst: RSpliet: it can't
11:30RSpliet: There's a point you cross the line of "is this still X?", but that's all semantics :-D
11:30karolherbst: maybe the modesetting DDX _might_ be able to support hotunpluffable GPUs
11:30karolherbst: but the native DDX?
11:30karolherbst: no way
11:30karolherbst: and then details like shared buffers and all that stuff
11:31karolherbst: it's just so out of question
11:31karolherbst: security wise X is also just broken and now way of fixing it without breaking all applications
11:31karolherbst: so you can also just replace X completely
11:31karolherbst: because fixing all the issues already means breaking the API
11:32tm512: 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:32karolherbst: tearing, also unfixable
11:32karolherbst: efficient display offloading, also unfixable
11:33karolherbst: tm512: the compositor handles that
11:33karolherbst: I know that mutter can
11:33karolherbst: I even tested WebRTC yesterday
11:33karolherbst: just works
11:33karolherbst: the thing is, with wayland the compositor is the one allowing/denying requests, so you get some nice popup to approve the requests
11:33karolherbst: and that's how it should have been all the time
11:34karolherbst: not agreeing with everything on how wayland was designed, but it at least brings the linux desktops into 2010
11:35tm512: 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:35tm512: 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:37tm512: 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:37karolherbst: no
11:37karolherbst: you want to have to enter your pw to approve that
11:37karolherbst: that's the entire point
11:37karolherbst: or something else "acking" it
11:38karolherbst: obs seems to support screenrecording through wayland as well already
11:38karolherbst: so ffmpeg can also just support it if they actually wanted to
11:42tm512: 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:42karolherbst: that's a ffmpeg limitation
11:45karolherbst: but you can also use the X api
11:50karolherbst: but yeah.. it's all a bit annoying atm, as software still needs to port over and stuff
11:50karolherbst: oh well
11:50karolherbst: maybe in 5 years
11:52tm512: I'm not exactly fond of X, but I am used to it, heh
11:52tm512: I guess it's pretty impressive how much staying power it's had
11:53karolherbst: 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:54karolherbst: the thing I am most worried about though is recovery which I think is still busted
11:54RSpliet: If it's better than before, it's progress!
11:54RSpliet: \o/
11:55karolherbst: maybe I get the CL 1.2 stuff in soonish
11:55karolherbst: just have to tidy up my inline sampler patch