01:39airlied: skeggsb: same problem with 4.4-rc1 and vpn for me
01:44airlied: skeggsb: there was a thread on lkml about it already
01:45airlied: so hopefully somone figures it out
01:48airlied: oh actually that is ancient email, ignore me
01:50airlied: skeggsb: http://patchwork.ozlabs.org/patch/544307/ works
02:46hakzsam: xexaxo, good catch! :)
05:16xexaxo: hakzsam: yw
05:16xexaxo: hakzsam: can you take a look at patchwork and let me know which patches we can "keep"
05:17xexaxo: ... I can change the rest of superseded/other
05:17hakzsam: I'll do
05:58xexaxo: s/rest of/rest to/
06:02Agiofws: nouveau segfaults with make human and does not work well when displaying the screen in bhvhacker BUT both work well with vesa drivers is there a way to install latest nouveau driver somehow in debian 8 ?
06:03karolherbst: Agiofws: what kernel are you running?
06:03Agiofws: the one that debian gave me let me check
06:03Agiofws: Linux P4 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt17-1 (2015-09-26) i686 GNU/Linux
06:03karolherbst: 3.16 :O
06:03karolherbst: what gpu does lspci say you have?
06:04karolherbst: Agiofws: if you want to test latest nouveau, you already need 4.3
06:04Agiofws: a 5700LE geforce nvidia card which is not supported by debian 8 anymore with its legasy drives
06:04karolherbst: I have some branches that are still 3.19 compatible though
06:04Agiofws: what should i do ?
06:05karolherbst: Agiofws: you mean thos FX 5xxx thing?
06:05Agiofws: it is supported by debian 7 but i don't want to downgrade
06:05karolherbst: by the nvidia driver you mean
06:05Agiofws: yes thats what i mean
06:05karolherbst: yeah, these cards are really old and nvidia drops support for older cards in newer drivers
06:05Agiofws: legasy 173xx something debian package for wheezy
06:06Agiofws: i even tried nvidias binary driver but it would not install
06:06karolherbst: I currently don't know who did something the last time for those cards, there was some activity, but I don't know
06:06karolherbst: RSpliet: do you know anything?
06:06karolherbst: Agiofws: yeah, they fail because of kernel too new
06:07karolherbst: Agiofws: what kernel package are you using?+#
06:07xexaxo: karolherbst: one of the redhat guys fixed a few bugs in the mesa nv30 driver.
06:07Agiofws: can i somehow upgrade or downgrade nouveau to get a working version for all apps not some only
06:07xexaxo: iirc ilia also tackled a few.
06:07karolherbst: Agiofws: ahh right, where do you get the segfault? in mesa or in the kernel?
06:07Agiofws: kernel package?
06:07Agiofws: in nouveau
06:07karolherbst: Agiofws: I don't know how the package is called in debian for the kernel
06:07Agiofws: Loading main GUI
06:07Agiofws: Loading plugins
06:07Agiofws: /usr/bin/makehuman: line 4: 2009 Segmentation fault python makehuman.
06:08Agiofws: Linux P4 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt17-1 (2015-09-26) i686 GNU/Linux
06:08karolherbst: Agiofws: ohh okay, so X is running with nouveau and it works basically
06:08karolherbst: but sometimes you get segfaults for some applications?
06:08Agiofws: it does but not fro the above programs
06:08Agiofws: when vesa does
06:08Agiofws: not sometimes on the above apps always
06:08karolherbst: then X log, dmesg pls
06:08Agiofws: well app.
06:08karolherbst: and you could do something
06:09karolherbst: I don't know where libSegfault.so is in debian
06:09Agiofws: dmesg | pastebinit
06:09karolherbst: Agiofws: does this file exist? /lib/i386-linux-gnu/libSegFault.so
06:10Agiofws: no such file exists
06:11RSpliet: karolherbst: that was Hans de Goede
06:11karolherbst: Agiofws: and /lib32/libSegFault.so ?
06:11karolherbst: RSpliet: ahh k
06:11Agiofws: karolherbst, pastebinit Xorg.0.log
06:11RSpliet: generally dislikes IRC
06:11karolherbst: yeah, no worries
06:13xexaxo: RSpliet: is that you or Hans that isn't a fan of IRC :-P
06:13Agiofws: locate libSegFault | pastebinit
06:13Agiofws: http://paste.debian.net/333018/ karolherbst ?
06:13RSpliet: xexaxo: Hans
06:13karolherbst: Agiofws: yeah well: /lib/i386-linux-gnu/libSegFault.so
06:13karolherbst: I asked for that :p
06:14RSpliet: I just oppose to humour
06:14karolherbst: LD_PRELOAD=/lib/i386-linux-gnu/libSegFault.so some command
06:14karolherbst: Agiofws: that will give you a stacktrace on crash
06:14Agiofws: what version of nouveau am i using and can i replace it for something else
06:14karolherbst: there won't be much debug information by default, so you may want to install mesa debug package
06:14xexaxo: karolherbst, Agiofws: using old(ish) mesa ?
06:15karolherbst: xexaxo:I guess so
06:16Agiofws: karolherbst, http://codepad.org/UihDdIvB
06:17xexaxo: karolherbst: you're into into the debian wagon are you ?
06:17Agiofws: it works with the vesa driver but its quit slow
06:17karolherbst: Agiofws: install libgl1-mesa-dri-dbg and try again pls
06:17karolherbst: xexaxo: ohhh I used to use debian/ubuntu on servers
06:18karolherbst: theser were some vservers mainly and too slow for gentoo
06:18xexaxo: shame... I'm looking for victims^Wvolunteers for a mesa ala LTS thingy :P
06:19karolherbst: Agiofws: after installing it, pls run something again the same way
06:19karolherbst: the stack should look a bit nicer then
06:19Agiofws: geforce 5 series is from 2003, probably nobody cares enough to improve nouveau drivers for it
06:19karolherbst: I think there will be somebody
06:19karolherbst: a segfault is usually easy to fix
06:19Agiofws: image link: https://i.imgur.com/VhxPw4S.png
06:21RSpliet: Agiofws: we're looking for volunteers :-P
06:21RSpliet: in general, simple bugs are picked up, but focus is on newer GPUs indeed
06:21RSpliet: given the small size of the team
06:21RSpliet: it's all we can do
06:22xexaxo: although this could already be fixed... (with backtrace providing info to jog peoples memory)
06:24RSpliet: "Mesa 10.3.2"
06:24RSpliet: yes, well, maybe just try newer software?
06:24Agiofws: karolherbst, RSpliet http://codepad.org/NkuFwk7T
06:24xexaxo:doesn't feel to optimistic and looks at the calendar
06:25Agiofws: what version of nouveau am i using and is there a better version older or newer?
06:25RSpliet: agiofws: there's no single nouveau version number
06:25Agiofws: well its through debians 8 packaging system
06:25xexaxo: 10.3.2 - 24 Oct 2014. Five more point releases since then.
06:25karolherbst: stupid libsegfault doesn't pick up debug files? :/
06:26xexaxo: latest fixes from ilia/hans made it only up-to 10.5 iirc
06:26karolherbst: Agiofws: then run in gdb
06:26Agiofws: image link: https://i.imgur.com/ePndshl.png
06:26Agiofws: ^^ thats the version i am using
06:26Agiofws: karolherbst, can you guide me through gdm ?
06:26karolherbst: gdb makehuman
06:27karolherbst: is it a bunary or some script?
06:27Agiofws: /usr/bin/makehuman": not in executable format: File format not recognized
06:27Agiofws: i think it python \
06:27Agiofws: so script
06:27karolherbst: gdb python makehuman
06:27RSpliet: Agiofws: that's the Xserver component, look at "mesa"
06:28karolherbst: Agiofws: gdb python /usr/bin/makehuman
06:29Agiofws: /usr/bin/makehuman" is not a core dump: File format not recognized
06:29karolherbst: ohh right
06:29karolherbst: Agiofws: gdb --args python /usr/bin/makehuman
06:30Agiofws: Reading symbols from python...(no debugging symbols found)...done.
06:30RSpliet: Agiofws: please update libgl1-mesa-dri to version 10.6 or newer
06:30karolherbst: RSpliet: I don'T think he can that do with his debian *cough* :D
06:30RSpliet: you can always do that
06:30RSpliet: there's external repo's, newer releases and compile from source
06:31karolherbst: Agiofws: ohh wait
06:31RSpliet: I don't think anyone here is interested in chasing a bug that potentially was fixed between a year from now and today
06:31karolherbst: please upgrade to stretch
06:31Agiofws: how ?
06:31karolherbst: debian 9
06:32karolherbst: orr use this external repo
06:32karolherbst: I don't know any for debian though
06:32karolherbst: RSpliet: you know which repo that is? I know only one for ubuntu
06:32RSpliet: karolherbst: no idea, I'm a Fedora user
06:32RSpliet: Agiofws: or if you want to quickly test whether your problems have already been solved, can you try to reproduce on a Fedora 23 live image? That way you don't have to mess with your running installation
06:33karolherbst: RSpliet: you know what the repository of the _newest_ debian is shipping, which isn'T release yet?
06:33karolherbst: sid is on 11.0 though
06:34RSpliet: karolherbst: idk, I just google and find https://packages.debian.org/search?keywords=libgl1-mesa-dri
06:34Agiofws: i have a slow machine downloading a live image? and running off disk on a 1.5GB machine and a pentium4 ?
06:34Agiofws: what is mesa by the way
06:35karolherbst: Agiofws: there is always xubuntu :/
06:35karolherbst: there you can at least install the xorg-edgers ppa
06:35karolherbst: and get newest software for your gpu
06:36RSpliet: karolherbst: it's not the goal to switch distro's, that should be unneccessary
06:36karolherbst: Agiofws: using nouveau on debian somehow sucks, because bugs get fixed, but usually not backported, so you are like 2+ years behind the actual state
06:36RSpliet: Agiofws: mesa is the 3d component of nouveau, does the OpenGL acceleration bits
06:36karolherbst: RSpliet: I know, but what do you expect, that he compiles the entire software stack on his machine?
06:36RSpliet: that's where your program crashes in
06:37RSpliet: if you need support getting a newer version of Mesa running on your machine, I suggest you ask the Debian people (IRC: #debian?). They might know best which packages exist and are reliable
06:38karolherbst: RSpliet: I already checked that: 10.3 for his version, 10.6 for the next version and 11.0 inside dev
06:38RSpliet: karolherbst: there might be mountains of custom repo's out there as well that we haven't heard of, but compiled against jessie
06:38RSpliet: people using Steam probably know ;-)
06:39xexaxo: I doubt they use things other than bleeding edge :P
06:39karolherbst: steam debian wiki page :D
06:39karolherbst: the steam wiki page suggest insalling blob dirvers
06:40xexaxo: surprised ?
06:41karolherbst: I thought they cared a bit more about free softare *cough*
06:41xexaxo: sure they do. that's why they have the non-free repo separate :P
06:42karolherbst: Agiofws: personally I would really suggest to you to use another distribution which doesn't use _ancient_ software. So if you don't care about using debian at all I would use something else, but if you really want to use debian, we might have to find an external repository or compile mesa and some other components from source
06:43karolherbst: xexaxo: right
06:43karolherbst: xexaxo: but at least on the wiki page they should also mention, that you may want to try out mesa instead of the blob stuff
06:43RSpliet: (to clarify, in graphics drivers terms, 1 year old brings you back to the middle ages, three years there still were dinosaurs walking around... development moves rapidly)
06:44karolherbst: xexaxo: not even intel is mentioned as if intel gpus were totally useless with steam :/
06:44xexaxo: hmm smells like Scientology :P
06:44Agiofws: karolherbst, i'd compile mesa on this machine
06:45xexaxo: karolherbst: based on the reply I've got from dri-devel... I'm not too surprised "don't think those can be updated post-release...new releases would need an ack from the security team, aiui"
06:45xexaxo: surprised = lack of updates thus any information how to handle/use mesa supported GPUs
06:46xexaxo: Agiofws: I'd suggest getting the latest debian build scripts, rather than trying to figure everything yourself.
06:46Agiofws: the way to go is compiling from source?
06:47Agiofws: where and how ?
06:47Agiofws: Package: xserver-xorg-video-nouveau on amd64 -- squeeze: 1:0.0.15+git20100329+7858345-5; squeeze-backports: 1:0.0.16+git20110411+8378443-1~bpo60+1; wheezy: 1:1.0.1-5; jessie: 1:1.0.11-1; sid: 1:1.0.11-1+b1; stretch: 1:1.0.11-1+b1
06:48xexaxo: *not nouveau but mesa ;-)
06:48RSpliet: xexaxo: that might require a libdrm rebuild as well, given the coherency work that gnurou did
06:49Agiofws: so a shot is to compile from source?
06:49xexaxo: RSpliet: good point. although it should also be trivial
06:49karolherbst: Agiofws: you have to compile libdrm and mesa
06:49RSpliet: yep :-)
06:49xexaxo: https://packages.debian.org/sid/libdrm-nouveau2 and https://packages.debian.org/sid/mesa-vdpau-drivers-dbg
06:50xexaxo: either fetch the source package from the right or fetch them via git.
06:50karolherbst: xexaxo: why the vdpau thingy? :D
06:51Agiofws: [mesa_11.0.5.orig.tar.gz] ?
06:52xexaxo: Agiofws: + the diff
06:52Agiofws: both diffs?
06:53xexaxo: might need the dsc - not too sure (by debian days were 6years ago)
06:53Agiofws: ok downloaded
06:53karolherbst: maybe this helps? https://www.debian.org/doc/manuals/apt-howto/ch-sourcehandling.en.html
06:54karolherbst: ohh obsolete :/
06:54Agiofws: image link: https://i.imgur.com/8V7I8oU.png
06:54Agiofws: ok extracted now ?
06:55Agiofws: and why cant i install the legasy 173xx driver that is for wheezy on jessie somehow convert it ? short answer: because it doesn't work any more
06:55karolherbst: Agiofws: you would need an older kernel
06:56jelly: and an older xorg-server perhaps?
06:56karolherbst: I think 173 needs 2.6.7
06:56karolherbst: ohh wait, not
06:56karolherbst: this is the lower bound
06:57Agiofws: i'd have to compile against an older kernel that 3.16 ?
06:58karolherbst: 173xx needs < 3.13
06:58Agiofws: would i have to compile a new kernel ?
06:58Agiofws: also ?
06:58karolherbst: Agiofws: not if you use mesa
06:59Agiofws: i think i'me using it
07:01jelly: Agiofws: backporting libdrm2 2.4.65 for debian 8 seems doable, but mesa looks to be a bigger problem
07:01karolherbst: jelly: X libraries?
07:01jelly: wants newer llvm than what's available in debian 8
07:02xexaxo: boohoo llvm. we don't need that :P
07:02Agiofws: should i start compiling or not follow the instructions in http://nouveau.freedesktop.org/wiki/InstallNouveau/ ?
07:02jelly: if llvm is optional (I don't know) Agiofws might just remove those build options
07:03jelly: our bot (I come from #debian) said: <judd> Backporting package libgl1-mesa-dri in sid→jessie/amd64: unsatisfiable build dependencies: Build-Depends: libdrm-dev (>= 2.4.63) [!hurd-any], llvm-3.7-dev (>= 1:3.7~+rc2) [amd64 i386 kfreebsd-amd64 kfreebsd-i386 armhf ppc64el], libclang-3.7-dev (>= 1:3.7~+rc2) [amd64 i386 armhf], libclc-dev (>= 0.2.0+git20150813) [amd64 i386 armhf].
07:04jelly: binary-based distros are fun!
07:05jelly: Agiofws: I'd say, as first step, build and install libdrm*deb using the procedure from /msg dpkg simple sid backport
07:06jelly: if you manage to do that it might be worth guiding you through building mesa, either packaged or from source
07:07jelly: how likely is it the newer drm+mesa will support NV30 better?
07:07Agiofws: First, check for a backport on <debian-backports>. ?
07:09xexaxo: jelly: we have 70 patches since 10.3-branchpoint. you can call 1/3 of those as bugfixes so ... yea there are some bits in there
07:09Agiofws: is there a url for that ?
07:10Agiofws: jelly, deb http://httpredir.debian.org/debian/ jessie-backports main ?
07:10Agiofws: insert that in my repos?
07:14Agiofws: jelly, apt-get -t jessie-backports install libdrm ?
07:17xexaxo: neither libdrm nor mesa seems to be on the online jessie-backports list :\
07:18Agiofwss: jelly, build and install libdrm*deb ?
07:19Agiofwss: apt-get -t jessie-backports install libdrm*deb ?
07:21Agiofwss: Download Page for libdrm-nouveau2_2.4.65-3_i386.deb on Intel x86 machines n?
07:21Agiofwss: can i just download that deb file?
07:33jelly: Agiofwss: do "/msg dpkg simple sid backport", read the procedure and follow it carefully. No, you can't just install the .deb files from sid, that will not work.
07:33Agiofwss: i did
07:34Agiofwss: not sure what to do i inserted a the back port line in my repository but now what ?
07:35jelly: Agiofwss: there is no backport in jessie-backports for you, they're unavaiable. Proceed with building.
07:38Agiofwss: jelly, whats the package name?
07:38Agiofwss: aptitude build-dep ?
07:38Agiofwss: libdrm*deb ?
07:39Agiofwss: https://packages.debian.org/unstable/libgl1-mesa-dri jelly ?
07:40Agiofwss: jelly, karolherbst aptitude build-dep libgl1-mesa-dri ?
07:45Agiofws: image link: https://i.imgur.com/dA4sgWC.png
07:46Agiofws: jelly, image link: https://i.imgur.com/dA4sgWC.png karolherbst can you take a look?
07:46Agiofws: am i building mesa?
08:01RSpliet: Agiofws: that looks like you're building old Mesa
08:01RSpliet: (as you could've seen from it downloading a version "10.3.2-...")
08:02RSpliet: can't help you with the debian-specific way of building new-mesa though
08:09Agiofws: RSpliet, are you sure?
08:10karolherbst: Agiofws: nobody here that I am aware of uses debian
08:10RSpliet: Agiofws: yes, that's what it says in the lines you highlighted, right?
08:11Agiofws: but i followed
08:11Agiofws: First, check for a backport on <debian-backports>. If unavailable: 1) Add a deb-src line for sid (not a deb line!); ask me about <deb-src sid> 2) enable debian-backports (see <bdo>) 3) aptitude update; aptitude install build-essential; aptitude build-dep packagename; apt-get -b source packagename; 4) install the resultant debs. To change compilation options, see <package recompile>; for versions newer than sid see <uupdate>.
08:11hakzsam: xexaxo, done
08:12Agiofws: how long is it going to take to build this?
08:15RSpliet: too long, given how it's unlikely to help you with it. If you need help with debian builds (which I think you do), ask in #debian please
08:15RSpliet: your problem, as harsh as it sounds, is a problem with debian rather than nouveau until you can reproduce it with a new software stack (kernel, mesa, libdrm, xf86-nouveau). As much as I'd love to help you with debian related issues with getting this stack up to date, I can't because I simply don't know debian
08:15RSpliet: I'm sorry
08:17Agiofws: RSpliet, would this help? http://ubuntuforums.org/showthread.php?t=1046504 ?
08:17Agiofws: or is it too ubuntu specific?
08:18RSpliet: it doesn't seem to be too ubuntu specific
08:19Agiofws: isn't theer a vesa 3d accel. hack or something ?
08:19RSpliet: but it is a guide from 2011, you might run into problems if you simply try to copy-paste the solution from there
08:20Agiofws: even if i do get a latest nouveau driver on debian it might not even work right?
08:20Agiofws: card maybe too old right ?
08:21RSpliet: possibly, but if it fails with modern software, then we can consider this a bug
08:21RSpliet: and you gain "bug reporting" rights ;-)
08:23karolherbst: RSpliet: do you know if the cstates and pstates are "sorted" in nvkm_clk?
08:24RSpliet: to the best of my knowledge, pstates are always sorted in VBIOS
08:24karolherbst: okay, and cstates?
08:24RSpliet: that's all I know, sorry :-P
08:24karolherbst: I just saw a vbios where the fastest cstate was at the top
08:24karolherbst: but this vbios also had only three cstates
08:24karolherbst: and was a kepler one
08:25RSpliet: I think kernel doesn't make an attempt at sorting pstates/cstates itself
08:25karolherbst: I think I will rely on the states being sorted
08:25RSpliet: oh, but is that by any chance one cstate per pstate?
08:25Agiofws: Weren't the nvidia-legacy-173xx-driver packages removed from Jessie because they won't build on Jessie's newer version of xorg? A package won't be dropped for no good reason. Seahorse41, a little web search will tell if you if that's the reason that the nouveau driver is your only hope. You may be able to fiddle with your DPI setting in the 1920 x 1080 resolution to get bigger buttons and fonts; I know you can do that in KDE, but
08:25Agiofws: I don't use GNOME.
08:25karolherbst: and then we just sort them while reading out the vbios
08:25karolherbst: RSpliet: yes
08:25karolherbst: RSpliet: there were two for 0f
08:25karolherbst: it also got the 0a cstate
08:26karolherbst: Agiofws: it's because of the kernel
08:26karolherbst: I told you already
08:26karolherbst: Xorg may be another reason, but the less bigger one
08:27Agiofws: The 173 series nvidia legacy driver was only supported up to and including the 1.14.x version of Xorg, Jessie is using the 1.16.x version of Xorg.
08:28Agiofws: karolherbst, can i downgrade nouveau ?
08:28Agiofws: maybe that will work?
08:28karolherbst: Agiofws: I will tell you this bluntly: there is _no_ easy way to get either nvidia or a new nouveau running with current debian 8
08:29karolherbst: Agiofws: why should it?
08:29karolherbst: Agiofws: newest nouveau => best nouveau :p
08:29karolherbst: there might be a regression, but then you would have to bisect an issue, which may be already fixed in the newest code
08:29Agiofws: well i assume that some version of nouveau worked well with 5700le card
08:29RSpliet: nope, sorry, that assumption is false
08:30karolherbst: it may have worked with _one_ 5700le, but there is no guranetee that _all_ 5700le cards ever worked
08:30Agiofws: maybe downgrade X to 1.14 but can i do that in jessie?
08:31RSpliet: ask the debian people, we don't know
08:31karolherbst: Agiofws: don't even think about that, because you also need an older kernel
08:31karolherbst: shortly: it would be too painfull either way
08:32karolherbst: here is _my_ recommendation: either use debian 7 or don
08:32karolherbst: 't use debian
08:32karolherbst: if you want to use the propritary driver
08:32karolherbst: if you want to use nouveau: use either debian sid or another distribution
08:33imirkin_: s/nouveau/open-source graphics stack/
08:34karolherbst: s/open-source graphics stack/new softare/ :p
08:34Agiofws: if i use debian sid will nouveau work with my card?
08:35imirkin_: Agiofws: no clue, but what i _can_ guarantee is that no one will look at your issue unless you're using the latest
08:35imirkin_: Agiofws: we don't have the resources to debug old issues
08:35Agiofws: latest what?
08:35Agiofws: h/w or s/w
08:36imirkin_: latest whatever it is that's dying. in your case that's mesa i gather? although i have no clue... i don't think you ever supplied the relevant info.
08:36RSpliet: Agiofws: which is why I suggested you take a look at Fedora 23 live, which has the entire open-source stack in a nice upgraded package. It's 1,3GB and can run off a USB disk
08:36imirkin_: latest software... i'll happily look at crashes with a Riva TNT if you can find 'em
08:37Agiofws: RSpliet, if i try it out and it works then what would the problem be?
08:37RSpliet: Agiofws: then the problem is the old software in Debian and you can think about how to upgrade your machine accordingly
08:38RSpliet: judging by the time you spent trying to do that, it's more complex than downloading, copying and booting a live image
08:38RSpliet: hence that's probably your lowest-resistance route to understanding your problem
08:39xexaxo: hakzsam: ouch. did not mean for you to tick them one by one - sorry for the hassle.
08:39xexaxo: for the future let me know if there's a bunch that I can mass change.
08:40hakzsam: yep, okay
08:40RSpliet: (and yes, with upgrade your machine I mean upgrading the software)
08:41hakzsam: xexaxo, I'll try to update the status of my patches in the future (when it's not done automatically) :)
08:43xexaxo: thanks !
09:33karolherbst: I got a fifo: PBDMA0: 00000002 [MEMACK_TIMEOUT] ch 2 [00bf890000 glxspheres64] subc 0 mthd 001c data 00000002
09:36karolherbst: mupuf: I see it already coming: before I get to finish those dyn reclock stuff, I will fix all the other reclocking issues as well and be done with dynr eclocking in a year
10:27pmoreau: SPIR-V power!!!!
11:11pmoreau: Let's compile and test this LLVM <=> SPIR-V backend…
11:13imirkin_: just don't try to use control flow :p
11:14pmoreau: Eh eh eh!
11:14pmoreau: I'll start with the samples that currently work with my code
11:14imirkin_: but if you want to add a ton of numbers, this is the backend for you!
11:14pmoreau: This is also the backend for lazy me
11:15pmoreau: Cause writing the SPIR-V by hand does take some time
11:15imirkin_: i can imagine
11:56imirkin_: skeggsb: ping about nv1f/nv1a clock adjustment inconsistencies
13:26pmoreau: imirkin_: Here is what I have for splitting 64 MAD/MUL: https://phabricator.pmoreau.org/P65
13:28imirkin_: hmmmm... i won't even ask why it does that clone bs. i assume it's coz the other half does it.
13:28imirkin_: you need to ensure that the multiplicands are TYPE_U32/S32
13:28pmoreau: Otherwise I bail?
13:29imirkin_: or write a lot more code :)
13:29imirkin_: bailing seems easier
13:33pmoreau: As for the clone, I don't know. Maybe it is needed to increment a ref counter for the source, to detect unused variables or other kind of optimisation?
13:42pmoreau: Should I check as well that the added value is TYPE_U64/S64?
13:43imirkin_: welllll... that's sorta implied
13:43imirkin_: you could assert it
13:43imirkin_: otoh, perhaps it's ok to allow 32 x 32 -> 64
13:44imirkin_: or 32x32 + 32 -> 64
13:44imirkin_: that seems reasonable...
13:44imirkin_: not like that's excruciatingly difficult to implement either
13:44imirkin_: albeit a tad annoying for S64
13:45imirkin_: since you have to sign-extend the low 32
13:45imirkin_: so... don't allow it for S32
13:45pmoreau: For S64 rather
13:46imirkin_: well, if the addend is S32
13:46imirkin_: then you'd have to sign-extend it for S64
13:46imirkin_: so that's annoying
13:46imirkin_: so don't allow the addend to be S32
13:46imirkin_: i dobut such code would ever be generated though
13:47pmoreau: Putting 0 for the high part of the addend wouldn't work
13:47pmoreau: I understand
13:49pmoreau: I doubt OP_MUL takes three operands, right?
13:49imirkin_: highly unlikely
13:49pmoreau: Might need to fix that in my patch
14:29Agiofws: does anyone in here have a 5700LE nvidia gfx card?
14:30imirkin_: unlikely.... that's a fairly gpu generation and very specific model of it.
14:32karolherbst: Agiofws: I thought we had already discuessed that: if you have problems with nouveau, test newest software and report back, then we can debug the issue with you
14:32RSpliet: karolherbst: maybe he's reporting back... as tempting as it may be, don't jump to conclusions ;-)
14:32karolherbst: yeah sorry
14:32imirkin_: fairly old*
14:33karolherbst: Agiofws: I don't want to annoy you with the idea of not using debian, but it would spare you a _lot_ of pain if you don't want to recompile your entire software stack. You could also just switch to debian sid, which is quite easy to do, but there might be bugs and package updates may be broken temporarily
14:34karolherbst: Agiofws: as somebody already suggested here: you could try out a live system
14:34karolherbst: with newest software
14:34karolherbst: and if nouveau works there, you know that upgrading software might help
14:35Agiofws: sid is wheezy ?
14:36imirkin_: Agiofws: someone who seemed to know about debian suggested that the only way to get the latest mesa packages on debian as to install debian-testing or debian-unstable
14:36imirkin_: Agiofws: alternatively pick a different distribution
14:36imirkin_: one that's not quite so user-hostile
14:37Agiofws: i am on jessie i think thats unstable no?
14:37imirkin_: Agiofws: cool, what version of mesa do you have installed?
14:38karolherbst: Agiofws: no, sid is the current dev stuff
14:38karolherbst: bleeding edge stuff
14:38karolherbst: newest software
14:38karolherbst: newer then debian 9
14:38RSpliet: jessie, ironically, is stable
14:38karolherbst: imirkin_: he has 10.3.2
14:38karolherbst: Agiofws: or did you upgrade anything in the meantime?
14:39karolherbst: imirkin_: it is like that: current debian 10.3.2, next debian: 10.6.8, sid: 11.0.5
14:39Agiofws: i tried to but in the end i was compiling the same mesa as the installed one so i stopped compilation
14:40Agiofws: ok maybe i have to upgrade to sid
14:40imirkin_: Agiofws: ok, well however you achieve it, you're unlikely to get a ton of help on any mesa issues until you install try it with mesa 11.0.x
14:41imirkin_: Agiofws: i believe pmoreau has a livecd with some pretty latest stuff on it... https://nouveau.pmoreau.org/ ... or you could try a plain fedora or arch livecd. dunno how difficult it is to get your software going though.
14:42RSpliet: imirkin_, Agiofws: that doesn't include an i386 iso, so I'm afraid that's not very helpful
14:42imirkin_: oh hah
14:43RSpliet: but at least Fedora still has a 32-bit live image... for now
15:15skeggsb: imirkin_: can you elaborate?
15:15imirkin_: skeggsb: a nv1f user reported weirdness
15:16imirkin_: i went looking at code
15:16imirkin_: comparing xf86-video-nv with what's in nouveau
15:16imirkin_: and i noticed that both we and the nv code have weirdo clock computation logic for nv1a/nv1f, different from the other chips
15:16imirkin_: however our code is different than the xf86-video-nv logic
15:16imirkin_: in the nv1f case, we don't divide by 1000, in the nv1a case we miss a >> 8 in the middle of the computation
15:17imirkin_: also our logic in arb.c seems like a fraction of the complexity of the xf86-video-nv arb calculation code
15:17skeggsb: hrm, i don't know that code very well, i didn't write it.. i had somewhat assumed that we inherited it all from nv
15:18imirkin_: well, the nv code is a HUGE unreadable mess
15:18imirkin_: but it does appear that our code is in fact inherited from it
15:18imirkin_: since we use the same bizarro datastructures
15:18imirkin_: and the same bizarro names
15:18imirkin_: but... the functions don't handle as many various cases
15:20skeggsb: yeah, those are quite different from a quick glance
15:21imirkin_: i'd be semi-in favor of just copying those functions over wholesale
15:21skeggsb: oh, hmm, those differences (in arb) look like it's just because ours only has the !video_enable case
15:21skeggsb: (and cleaned up)
15:21imirkin_: yeah, that could be
15:22imirkin_: whereas nv1a/nv1f set video_enable=0
15:22imirkin_: er you mean ours only has the video_enable case?
15:22skeggsb: well, the nv4 version at least only has the !enable case
15:23imirkin_: nv10UpdateArbitrationSettings sets enable_video to 1
15:23imirkin_: so it's only disabled for nv4 and nforce
15:23imirkin_: [in the nv code]
15:23skeggsb: yeah, i wasn't looking there yet :P
15:23imirkin_: ah heh
15:23imirkin_: well, enable_video is completely gone in the nouveau code
15:25imirkin_: nv10_calc_arb also seems to skip the while(!found) loop
15:27skeggsb: it probably does just make sense to steal it wholesale from nv...
15:27skeggsb: especially if it helps
15:27imirkin_: well i haven't the faintest clue if it helps
15:27imirkin_: i just went looking and it looked different
15:28imirkin_: but the thing that immediately strikes me as odd is take a look at
15:28imirkin_: and compare that to the MClk calculation in nForceUpdateArbitrationSettings
15:28imirkin_: for nv1f: MClk = READ_LONG(5, 0x4C) / 1000
15:28imirkin_: for nv1a: uMClkPostDiv = (READ_LONG(3, 0x6C) >> 8) & 0xf
15:29imirkin_: we appear to miss that entirely
15:31skeggsb: the nv1a thing is definitely a bug - i think ;)
15:32skeggsb: the nv1f one could be explained if we use different units for clock
15:32imirkin_: but then nv1a would have the wrong units too
15:33imirkin_: that's basically where i ended up the other night
15:33imirkin_: didn't peer further into this units thing
15:33imirkin_: i assume you don't have a nv1f available && working?
15:33skeggsb: thankfully, no
15:33imirkin_: otherwise you'd be tempted to check it out?
15:34skeggsb: i'd feel more guilty for not checking it out :P
15:40imirkin_: skeggsb: looking at the various calc functions, they seem to have the same number of 1000's... dunno
15:40imirkin_: skeggsb: so i think the units are the same as in the nv code
15:41imirkin_: fill_lat = mclks * 1000 * 1000 / mclk_freq /* minimum mclk latency */
15:41imirkin_: + nvclks * 1000 * 1000 / nvclk_freq /* nvclk latency */
15:41imirkin_: + pclks * 1000 * 1000 / pclk_freq; /* pclk latency */
15:41imirkin_: us_pipe_min = us_m_min + us_n + us_p;
15:41imirkin_: us_m_min = mclks * 1000*1000 / mclk_freq; /* Minimum Mclk latency in us */
23:51exidux: imirkin_, : i will see if i an get the patch for the nv1f running, later in time.