01:10karolherbst: imirkin: if you want I could test that PIPE_CAP_MAX_TEXTURE_UPLOAD_MEMORY_BUDGET thing with my 770m
01:11karolherbst: one of the slowest Kepler GDDR5 GPUs, but I guess better than nothing
01:11karolherbst: uhm, slowest memory
01:12karolherbst: mhh, actually there are slower ones, but those are also all mobilec chips
01:12imirkin: DDR3 is probably slower still ;)
01:13imirkin: i suspect the fact that i have PCIe 2.0 and not 3.0 also plays a factor
01:13karolherbst: that one has around 100GB/s
01:13karolherbst: ohh evil, a GDDR5 one with 40 GM/s
01:13karolherbst: 64 bus width... calling for it
01:13imirkin: anyways, i tested with nv34, G92 with GDDR2 (400mhz out of a total of 800mhz), and a GM206 at lowest clocks
01:14imirkin: so ... not exactly the PERFECT performance test scenarios...
01:14karolherbst: ohh I can test on my newer GPU as well
01:14karolherbst: 970m :D
01:14karolherbst: 120 GB/s memory
01:14karolherbst: that's more like it
01:14imirkin: feel free to play around with it
01:14imirkin: i saw almost no difference between 4M and 64M
01:15imirkin: and very little difference between 1M and 4M
01:15karolherbst: what's the most relevant factor here? PCIe bandwidth?
01:15imirkin: no clue
01:15imirkin: no-more-oom seemed like a nice little benefit
01:15karolherbst: I think I actually have the reclocking patches on that gm204 active, so I should probably test there
01:45pmoreau: karolherbst: How do you specify for a Meson build of Mesa which LLVM version to use? I tried setting PATH to include my custom build of LLVM first, but it still ends up linking against my system LLVM install rather than my custom build.
01:45karolherbst: pmoreau: either export PATH whenever you use meson/ninja
01:46karolherbst: or write a cross file and specify llvm-config
01:47pmoreau: I’ll try with exporting or writing a cross file, but setting PATH on the command line whenever I run a meson or ninja command was not enough.
01:48karolherbst: pmoreau: weird, works for me
01:50pmoreau: I’ll try again next week once I’m back home. I could try on my old laptop that I have with me, but not sure if 1) your NIR work would let me run OpenCL on NV50 and 2) compiling LLVM on this Intel Core 2 Duo is going to take years! :-D
01:50karolherbst: should work and why compiling llvm?
01:50karolherbst: ohh right, I use my system llvm :D
01:50karolherbst: but yeah, I used to use my local one
01:51pmoreau: Because you need LLVM 8 for the latest SPIRV-LLVM-Translator, which isn’t released yet.
01:53karolherbst: get a distribution where you can install such a llvm system wide :p (if you don't fear mesa master)
01:53pmoreau: And Arch does not provide packages for unreleased versions usually. Maybe there is a different repo that has them?
01:53karolherbst: there always is
01:54pmoreau: There is an AUR package for LLVM SVN, but AUR packages are built locally so it’s not going to help with build time.
01:55karolherbst: let it compile over night :D
01:55HdkR: Does it only need LLVM or does it need LLVM and Clang?
01:55karolherbst: clang as well of course
01:55HdkR: ick, clang takes forever
01:56airlied: or fix the spirv-llvm-translator to build against llvm7:-P
01:56karolherbst: clang takes less than llvm though
01:56karolherbst: there is a branch actually
01:56karolherbst: never tried it
01:56HdkR: Weird, clang takes longer than llvm for me :P
01:56airlied: yeah but its old
01:56airlied: it does build from the branch
01:56karolherbst: but it also doesn't contain the additions we need for mesa anyway
01:57pmoreau: There’s a MR to merge in the fixes from the master branch into the release-70 branch
01:57karolherbst: sadly that llvm testing thing makes it impossible to have the same branch working for multiple releases
01:58karolherbst: the tests are stupid anyway
01:58karolherbst: I don't see the point in testing for order of instructions really
01:58karolherbst: more of a hazzle than beneficial
01:59karolherbst: of final bytecodes that is
02:00karolherbst: or well, it would be usefull if the same ll file would compile to the same spir-v, no matter what version of llvm you have
02:44blipk: any suggestions on getting 4K display to work on nouvue drivers? keep getting 'configure crtc 0 failed' when trying to change output to any higher res with xrandr
02:44blipk: seems my monitor is sending bad EDID data, also only get 'default' output in xrandr rather than specifics, if that has anything to do with it
02:44airlied: sounds like you have nomodeset and are using vesa
02:46blipk: so I should try disabling nomodeset?
02:46blipk: I just installed the nvidia driver package and works fine
02:47blipk: I'd rather use free software though
02:47airlied: well then you need to uninstall nvidia, and remove nomodeset
02:47imirkin: or return the nvidia board and buy amd
02:47blipk: right, it wasnt working before I installed nvidia though and I didnt turn on nomodeset
02:47blipk: would installing them have turned that off?
02:49blipk: well I broke my distro in other ways too
02:49blipk: so I'll give that a shot when I reinstall
02:49blipk: whats an alternative to vesa?
02:49blipk: if its just not the nomodeset issue
02:50airlied: it's just nomodeset
02:50imirkin: could be a million things, would have to debug it.
02:50imirkin: in general nouveau's pretty good at the basics of modesetting though
02:51imirkin: [until i touched it with my grimey hands... waiting for reports of issues to flow in for 4.20...]
11:16blipk: so I'm trying to get my GTX 1060 to work with nouveau and a 4K display over display port, seems I might need video acceleration, is that just impossible because of the signed proprietary nvidia blobs that I need?
11:29HdkR: Video being video decoder acceleration or something else that isn't related to the 3D engine?
11:29HdkR: Because you at least need the signed blobs for the 3D engine, which are available for pascal
14:37joepublic: Curious, PhyX ("Including the GPU accelleration code" according to Phoronix) being released under BSD license -- is that helpful to any extent, or is it still too much of the wrong thing to help nouveau?
14:38joepublic: if I could spell which I obviously cannot
14:40gnarface: i wonder if it means that someone can fix physX support in Borderlands2 and the pre-seqel for Linux
14:50loonycyborg: PhysX probably is just overkill for games, so they're opensourcing it so at least scientists could make use of it
14:54karolherbst: joepublic: physx is cuda
14:54karolherbst: well, makes use of cuda
14:54karolherbst: without a cuda runtime, no physx
14:57karolherbst: or it was at least. maybe it can use compute shaders now. dunno
14:58joepublic: I am just hoping that Nvidia edges ever closer to providing helpful needful things.
20:49Lyude: karolherbst: poke; do you know if the PCI driver on linux changes the power state of PCI devices before their respective drivers are actually loaded?
20:49Lyude: like-if I had a nvidia gpu that the bios put into D3 mode then I boot up, but nouveau isn't loaded at any point, will it stay in D3?
21:11karolherbst: Lyude: I am sure the pci subsystem would put it into D0 mode
21:12karolherbst: but... maybe it doesn't?
21:12karolherbst: I think it's done somewhere in enable_device
21:12Lyude: karolherbst: alright
21:13karolherbst: calls pci_set_power_state(dev, PCI_D0)
21:13Lyude: and devices are just enabled by default?
21:13karolherbst: you have to aaik
21:14karolherbst: either by the driver or by the subsystem