05:48AndrewR: airlied, congratulation for landing your 'software Vulkan' initial work in mesa :}
06:02airlied: AndrewR: thanks!, now to get through the fixes on top of it :-P
06:06AndrewR: airlied, :}
06:06AndrewR: well ..not quite ":}" for you ...
06:07AndrewR: airlied, I also had this stupid qestion ...can be virtio-gpu reused in qemu-user (at least for some combinations of host/target architectures, LE ones) ? I saw some drm/i915 patches floating around on qemu ML, but because I don't have Intel GPU ....
06:11airlied: hmm don't think qemu-user can use it, since it gets direct access to ioctls
06:16AndrewR: airlied, ok, I don't have any 'serious' use case for this, just thought virtio-gpu today can be used as some kind of 'universal' gpu for such cases ....
06:26airlied: AndrewR: nope it needs a process on the "other"side
06:26airlied: it might be possible to hack something up using the testing code that passes stuff over a pipe
06:49AndrewR: airlied,yeah .. I'm not sure how normal X rendering and OpenGL will be coordinated in this case ....
09:54karolherbst: pmoreau: do you want to review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6338/ or should I just merge?
09:54karolherbst: no change in shader-db (except minor things which affect nothing)
09:54karolherbst: like instead of advertising 64 bytes, for 4 vec2s we advertise 56 (as the last 8 bytes were unused anyway)
09:55pmoreau: I won’t have time to review until this weekend, at least.
09:55karolherbst: and we align to 0x10 later on anyway
09:55pmoreau: And I don’t think I would have the proper knowledge for reviewing it anyway. I have no idea how it currently works
09:55karolherbst: I see :D
09:56karolherbst: it essentially just removes ugly code and makes it possible to support CL private memory :p
09:58karolherbst: mhh.. actually...
09:58karolherbst: I think I can rework mov even more
10:00karolherbst: nope.. but can remove more code duplication
17:39hoodle: Hey guys! Is anyone around to answer some questions regarding the TU168 chipset?
17:39imirkin: ask and ye might receive
17:40hoodle: Sweet. Basically, I temporarily have an Nvidia GTX 1660. Of course, proprietary drivers are a nightmare for Wayland, so I'm trying to use Nouveau as I have been.
17:40hoodle: Unfortunately, I can't seem to find a solid answer as to whether or not that chipset is supported by nouveau.
17:41imirkin: which kernel?
17:41hoodle: Kernel 5.8. Running Archlinux (I think I'm bound by law to say that, right? heh)
17:41imirkin: presumably you mean NV168, aka TU116?
17:42hoodle: Yupp! That's the one.
17:42imirkin: if so, should be, afaik, for some definition of supported
17:42karolherbst: hoodle: you will need mesa 20.2 for OpenGL support
17:42hoodle: Right, that's what I've seen. But I don't think any 2D acceleration is supported checking from the feature matrix.
17:42hoodle: Right, okay. How could I check my mesa version?
17:43imirkin: hoodle: or use arch's package manager to tell you?
17:43hoodle: Right, smart.
17:43karolherbst: or that...
17:43imirkin: 20.2 isn't fully out yet
17:43hoodle: Mesa version is 20.1. Makes sense then.
17:43imirkin: but there's a 20.2.0-rc2
17:43hoodle: Darn, I've been unable to launch sway without it running at an abhorrent framerate.
17:43karolherbst: yeah, please give it a try and report any bugs :)
17:44imirkin: there's no such thing as 2D accel with wayland compositors btw -- they all use OpenGL (or Vulkan)
17:44hoodle: Oh okay, good to hear. I thought something along those lines, honestly. But admittedly wasn't quite sure.
17:44hoodle: Would I have to compile it myself? Or is there a place I can get it with my package manager?
17:44imirkin: unless there's someone here who knows arch ... we don't do distro support
17:44karolherbst: install the 20.2 rc
17:44hoodle: Wouldn't consider myself a Linux noob, but definitely is the first time I'm getting dipping my toes into custom modules like this.
17:45hoodle: Yeah, that makes sense.
17:45karolherbst: or use mesa-git
17:45hoodle: Alright I'll take a look. Thanks a ton for your help so far!
17:45hoodle: Right yeah, mesa-git should be perfect.
17:45karolherbst: there is a arch package for mesa-git somewhere :)
17:45hoodle: I'm so done with Nvidia at this point. So ready for RDNA2 so I can get a new AMD card.
17:45karolherbst: well.. yeah
17:45karolherbst: their wayland support sucks
17:45karolherbst: and their prime support is also bad
17:46hoodle: Yeah, it's frustrating. I have a laptop with an integratd 960 I believe. Was a nightmare trying to get that working/
17:46karolherbst: tried the proper prime on 450 with intel being the main (finally!)
17:46karolherbst: but.. nvidia just displayed garbage doing display offloading
17:46hoodle: Ah, yeah. Doesn't it also keep both powered up? I heard it was awful for battery life.
17:46karolherbst: not anymore
17:46karolherbst: they added it in 435 for turing+ or so
17:46karolherbst: but you still have to enable it
17:46hoodle: Right, yeah I did know Nvidia was finally doing at least something for Linux in that regard. Good to see.
17:46karolherbst: and stuff...
17:46karolherbst: but it's also buggy :D
17:47karolherbst: they suffer the same bug nouveau suffered from
17:47karolherbst: but I failed to convince them of it
17:47karolherbst: so they still think it's fine,but users are complaining.. oh well
17:47hoodle: I'm just biting my fingernails over here because my old GPU started dying. My fiance doesn't use her PC all that much so we've swapped GPUs and I'm now waiting for AMD to release next-gen.
17:47hoodle: Such is life being a second-class citizen to Nvidia unfortunately.
17:47karolherbst: anyway.. with mesa-git the TU116 should run much better :)
17:48hoodle: Awesome. Hugely appreciate it. It's currently compiling.
17:48karolherbst: right.. NV168 but TU116.. weird naming
17:48hoodle: Yeah, it's a bit weird.
17:48karolherbst: ohh right.. AURs needs to be compiled
17:48karolherbst: oh well
17:48hoodle: Not all of them do. Specifically the git ones do.
17:48hoodle: Because they just pull source from git of course.
17:49karolherbst: I still have a few fixes for volta/turing locally, but they are quite low priority to mainline unless users are acutally hitting issues...
17:49karolherbst: most of the things are a bit annoying to get in at this point
17:49hoodle: Right. What card do you have?
17:50karolherbst: tu117 right now
17:50karolherbst: but I have more in the office
17:50hoodle: Right right. It's also a shame so few people seem to have TU116 as well, so there was very little info online about what to do about things.
17:51hoodle: Maybe I'll write a guide once I get this working for people currently on Arch.
17:51hoodle: Or, currently in this version at least. I hope the changes will get pushed into the mainline soon.
17:52karolherbst: ehh.. most of the remaining fails are really only relevant to the conformance test or games requiring high end power, but yeah.. trying to get back to it at some point
18:04hoodle: Hm, new issues now it seems unfortunately. Getting crashes on sway being launched. May have to do some poking around.
18:08karolherbst: hoodle: interesting
18:08karolherbst: backtrace and such would be welcomed
18:10hoodle: It's still the same kind've issue it seems. Sway is failing to get the proper DRM device. It's failing an assert resulting in DRM_FORMAT_MOD_INVALID.
18:10hoodle: Additionally, if I try and launch xorg I get an unrecognized chipset with xorg itself, despite the fact that nouveau initializes properly.
18:12hoodle: If AMD could just release their new GPU line tomorrow that would be awesome lmao. It seems like a waste of time to spend hours trying to fix this when I'm just going to swap out the GPU in 2 months.
18:12hoodle: But I also don't want to be stuck in Windows for 2 months, either. Tough decisions :p
18:12hoodle: Either way, need to get back to work so I'll let you guys know if I figure something out later. Thanks again for all the help!