00:01Agiofws: how do i disable llvm build options, and remove llvm from to build mesa?
00:06Agiofws: can anyone please take a look at http://paste.debian.net/333256/ and tell me how to fix this ?
01:00pmoreau: Agiofws: Maybe --disable-gallium-llvm?
01:35karolherbst: mupuf: I am now worried about lost IRQs from the pmu where we don't expect any reply at all, like when the pmu just sends stuff :/ We could workaround that by having that loop to handle messags until the queue is empty, but we may be able to find the root cuase maybe
01:35timss: Hi. Trying to setup triple monitor/dual gpu. Is the only option xinerama?
01:37karolherbst: timss: well, I would expect that reverse Prime could also work, but no idea if that works for the same driver
01:39timss: Hmm, that sounds like uncharted territory indeed.
01:40karolherbst: it works for some on laptops with an intel/nouveau combination though
01:40karolherbst: timss: there are acceleration problems with xinerama, aren't there?
01:40timss: This is a desktop with two identical dedicated gpus (quadro 600).
01:41timss: karolherbst: so I've heard. I'm using Plasma/KDE 5, and using the proprietary nvidia driver it wouldn't even start without crashing lol
03:38karolherbst: meh, I can't really get the current memory load with the counters used by the blob :/
04:12Agiofws: i'm trying to build the deps for mesa package and i am getting messages can anyone help me please ? aptitude build-dep mesa | pastebinit
04:13RSpliet: Agiofws: someone already suggested adding the flag --disable-gallium-llvm to compilation
04:13RSpliet: how to do that with the Debian build scripts, no idea...
04:18Agiofws: debian/rules is the makefile used when building a .deb from source, edit it to change compilation options. Some packages use sophisticated build systems that should be documented in debian/README.source.
04:29xexaxo: Agiofws: apart from adding the above configure switch (into debian/rules) you can trim down all the bits that depend on it...
04:30xexaxo: - opencl (--disable-opencl and resulting package) radeon (drop r300, r600, radeonsi from gallium drivers and respective sections that refer to them)
04:32xexaxo: that said I'm not sure why debian mandates 3.7 as it's clearly not something required by upstream.
04:32xexaxo: it's "great to have" afaics
04:33karolherbst: can anybody help me writing a little application for nouveau which just does dozens of memory related operations without using the core too much?
04:35Ghost_r00t: hello hard working pride people
04:37Ghost_r00t: could I ask about the status of bug 84721?
04:38karolherbst: Ghost_r00t: did you try it with newest kernel?
04:39karolherbst: allthough that might not help
04:40karolherbst: Ghost_r00t: did you provide your vbios already?
04:41Ghost_r00t: karolherbst: Yes; I did it today with latest xential-ubuntu nightly build for 16 Nov
04:41Ghost_r00t: my fan was about to do a take off
04:42Ghost_r00t: and yes to your second question
04:43karolherbst: Ghost_r00t: did you run sensors and checked the fan speed there?
04:43karolherbst: maybe the real and expected speed is not the same
04:47Ghost_r00t: karolherbst: the horrifying sound is. ( if I get you right.)
04:47karolherbst: Ghost_r00t: if you have some time you could try to investiage the issue yourself. I don't think it is that hard to actually find the root cause, but without a gpu where nouveau drives the fan too fast no dev will be able to fix it fast
04:47karolherbst: Ghost_r00t: yeah, but if sensors says something like 800rpm, but the fan is noisy, then there is something wrong
04:47Ghost_r00t: nouveau would ran my GPU fan at MAX speed from the get go.
04:48Ghost_r00t: Ghost_r00t: I have no problem with ubuntu 15.04 livecd.
04:48Ghost_r00t: it runs as normal there!
04:49karolherbst: Ghost_r00t: did this issue occured since always or was it okay with an older kernel?
04:49Ghost_r00t: I just saying to assure you
04:50Ghost_r00t: karolherbst: it was ok till 3.8 I think
04:50karolherbst: ohh okay
04:50karolherbst: then here is what you can do:
04:50karolherbst: git bisect the kernel until you find the commit which broke it
04:50karolherbst: and test with 4.3 before doing so
05:02Agiofws: xexaxo, would you no how to apply those args ?
05:33Agiofws: Agiofws, btw, here are ready mesa-packages for jessie: http://kanotix.com/files/fix/mesa.jessie/backports/
05:54RSpliet: Agiofws: cool... well, that's why I referred you to the Debian people instead :-P
05:55RSpliet: but thanks for sharing, that might come in handy some day
06:01Agiofws: RSpliet, can you guide me on what to install and how to try ?
06:02Agiofws: because synaptic has a separate nouveau package and that is only for mesa and libdrm
06:05Agiofws: RSpliet, ?
06:05karolherbst: I will need somebody later to test some pdaemon counters on kepler/maxwell cards
06:06Agiofws: karolherbst, i have found mesa-packages for jessie: http://kanotix.com/files/fix/mesa.jessie/backports/ can you tell what to install ?
06:06Agiofws: and how to enable nouveau then and check if it works ok
06:06Agiofws: too many packages
06:07Agiofws: do install all for arch?
06:07karolherbst: Agiofws: libdrm and mesa
06:07karolherbst: I guess libvdpau, too
06:07Agiofws: ALL of them
06:07Agiofws: many packages
06:07karolherbst: you won't need the intel ones
06:07Agiofws: i already have libdrm
06:07Agiofws: how do i install nouveau now ?
06:08karolherbst: it is a kernel module, it is already installed
06:09Agiofws: karolherbst, ls -ltrs | pastebinit
06:09Agiofws: http://paste.debian.net/333318/ please take a look and tell me what to install
06:09Agiofws: karolherbst, how do i know which package is the kernel module?
06:10karolherbst: none is
06:10karolherbst: it is part of the kernel package
06:11Agiofws: libgbm-dev_11.0.4-1-bpo8+0_i386.deb ?
06:12karolherbst: why don't you just upgrade to sid?
06:12Agiofws: they told me not even dpkg works in sid
06:12karolherbst: "who" told you?
06:13Agiofws: from debian
06:13Agiofws: too unstable maybe
06:13Agiofws: mesa-vdpau-drivers_11.0.4-1-bpo8+0_i386.deb ?
06:13karolherbst: by now you could also already downloaded a live usb stick with recent software and try it out there
06:14karolherbst: to say it bluntly: nobody has the time and motivation to teach you every bit about which package to install and how to do it on debian and stuff like that, we already suggested to you easy ways to check if newest nouveau helps. If you want to stick with debian, ask debian guys how to get the newest versions of mesa and the kernel
06:15Agiofws: thats what i did
06:15Agiofws: i found ready debs
06:16karolherbst: if there is no user friendlier way of doing that, how do you plan to proceed later?
06:16karolherbst: imagine it works, do you want to update all those debs package by hand every so often?
06:17towo^work: the user friendly way would be, that url is a repo, it can be added to sources.list
06:17karolherbst: towo^work: right
06:17towo^work: but it would depend on an user, whch has a little clue about debian basics
06:19karolherbst: towo^work: does that look like a deb repository? http://kanotix.com/files/fix/mesa.jessie/ I have no big clue, but it kind of does
06:19towo^work: it is a repo
06:19karolherbst: Agiofws: yeah, so you have to add this repository to apt and update your packages through apt
06:19towo^work: deb http://kanotix.com/files/fix/mesa.jessie ./
06:19karolherbst: sounds easier to me then downloading all those deb files
06:19Agiofws: ok then will do
06:20karolherbst: Agiofws: I don't want to be evil or nasty or anything, I just try to be as honest as possible
06:23Agiofws: ok upgrading
06:23Agiofws: towo^work, you think it will work?
06:24towo^work: what is "it"?
06:24Agiofws: nouveau update ?
06:25towo^work: i don't get, from where you will get an update of xserver-xorg-video-nouveau
06:26Agiofws: well i inserted the repository
06:26Agiofws: now is nouveau installed or do i have to enable from synaptic or something ?
06:26towo^work: that repo does not contain xserver-xorg-video-nouveau
06:26towo^work: mesa != nouveau
06:27Agiofws: well i installed vers. 11 from synaptic
06:27Agiofws: thank you
06:28Agiofws: uninstalled vesa
06:28Agiofws: ane reboot
06:28towo^work: i would never uninstall vesa
06:28towo^work: it's a nice fallback, if nothing other works
06:28towo^work: oh, he is gone
06:30karolherbst: towo^work: nobody needs vesa if you have modeset :p
06:30towo^work: will modeset work even if there is no KMS kernel driver? i think no
06:31karolherbst: ohh right, I use efifb as a fallback :/ this has kms support afaik
06:37karolherbst: meh, we have to do something about those lose IRQs from the pmu
06:37karolherbst: if the pmu sends something to the host and it get's lost, we mess up big time the next time we send something to the pmu and wait on a reply
06:38karolherbst: there could be something queued and we get data we parse the wrong way :(
06:40Agiofws: karolherbst, ok its working
06:40karolherbst: Agiofws: nice
06:41Agiofws: ok it worked i put the repo towo^work suggested in apt/sources and upgraded and the 3d accel glitch or bug went away
06:42Agiofws: makehuman just warned me about openshading or something like that
06:45Agiofws: hmm bvhacker still does not want to display nicelly though
06:56karolherbst: mupuf: 0x1000 bit in pdaemon counter might help us determining the cpu waits on memory operations. antichamber runs stable at 60 fps in 0a and 0f pstate. But, the core counters and 0x1000 drop by half the value when going to 0xf compared to 0xa
06:58karolherbst: mupuf: in pixmark piano with no noticable fps change (gpc capped) the 0x1000 value drops by around 20% only
06:58karolherbst: so both 0a and 0f give me 17 fps
06:59karolherbst: and antichamber is also fine with a really low cstate (like 500MHz is enough on 0f for 60 fps)
07:00karolherbst: mupuf: also core load doesn't change at all, when I clock from 862MHz down to 405MHz in antichamber in 0a pstate, the counters are showing the same values baiscally
07:50karolherbst: nice, I actually prefer nouveau over blob now with wine stuff :)
07:50imirkin_: karolherbst: with st/nine?
08:00karolherbst: imirkin_: yes
08:00imirkin_: cool :)
08:03karolherbst: yeah, seems to work pretty well now
08:03karolherbst: and the cpu load is soo low
08:03karolherbst: around 50% for most of the games
08:03karlmag:can like stuff that works pretty well :-)
08:03karolherbst: without nine I have usually like 150%+
08:06karolherbst: okay, now figuring out the pmu stuff :/
08:06imirkin_: karolherbst: and moar fps?
08:06karolherbst: imirkin_: didn't check
08:06karolherbst: but the graphics are much better
08:07imirkin_: "enough fps" :)
08:07karolherbst: there are now shadows! :D
08:07imirkin_: i like shadows
08:07karolherbst: this d3d9=>gl wrapper seems to miss a lot of stuff
08:07karolherbst: for some games the difference feels like 5 years of game development
08:07imirkin_: well, i doubt that it misses a feature like "shadows", it's probably something way more subtle
08:07karolherbst: so even when the fps would be a little bit lower, the details are much better
08:08karolherbst: so it's fine
08:09karolherbst: imirkin_: by the way, I've implemented a really trivial dynamic reclocking thing, which seems to work for _my_ gpu
08:10imirkin_: very cool :)
08:10karolherbst: yeah, besides that we have to figure out these pdaemon counters more
08:10karolherbst: core waiting on memory is a big pain
08:10karolherbst: we need to figure out how to get this information
08:11karolherbst: or to say it more data based: when does increasing memory clock reduces gpu core load
08:11karolherbst: this is a critical thing otherwise the algorithm won't do anything good
08:13karolherbst: imirkin_: you do have a kepler card, don't you?
08:13imirkin_: karolherbst: yeah, i have a GK208
08:14karolherbst: desktop or mobile?
08:14imirkin_: but secondary, with i965/hsw as the thing driving the monitors
08:16karolherbst: imirkin_: could you do this? nvapoke 0x10a504 0x1000 && nvapoke 0x10a50c 0x2 && nvapoke 0x10a508 0x80000000 && sleep 0.1 && nvapeek 0x10a508
08:16imirkin_: what do you expect this will do?
08:16karolherbst: this sets a pdaemon counter
08:16karolherbst: and prints the data collected after 0.1 seconds
08:16karolherbst: I hope it will return 0
08:17karolherbst: if not, then meh
08:17imirkin_: yep, 0
08:17imirkin_: the GPU is idle
08:18imirkin_: urgghhhh... just realized that stupid soma trace is causing GPU errors
08:21imirkin_: "multiple warp errors". great. thanks for letting me know.
08:21imirkin_: couldn't *actually* tell me what the error is, could you?
08:21karolherbst: ohh I know those, I ask always about them
08:22karolherbst: currently I let my pmu bomb my kernel with an IRQ every 0.1 seconds :/ but when I change the pstate while the pmu does that, my kernel goes useless
08:24karolherbst: imirkin_: if you want, you could try out my branch, it should work for you as long as you don't change the pstates yourself :D
08:25imirkin_: no thanks, i'll wait for it to come out on dvd
08:27karolherbst: ohhhhhhh wait, I think I know what's going on
08:28karolherbst: maybe I have to wait a little longer
08:51karolherbst: imirkin_: I think this works now. with antichamber, my code reclocks to pstate 0f and 7th cstate, and the games runs at 60 fps :)
08:51karolherbst: and 50% core load, which is the target I choose
08:52imirkin_: why would the target not be 100%?
08:52karolherbst: and I have 36 cstates
08:52karolherbst: imirkin_: to smooth unstable loads
08:52karolherbst: sometimes you need more power <0.1 seconds later
08:52imirkin_: karolherbst: does your thing iterate cstates?
08:53imirkin_: so the % load target is its "just-in-time"ness, right?
08:53karolherbst: it also switches to higher pstate, when the request one isn't available for the calculated pstate
08:53imirkin_: e.g. 100% gives you the best power efficiency, 0% gives you the best response time
08:53karolherbst: something like that
08:53karolherbst: with constant load, a target of 90% would be fine too
08:53karolherbst: 18W power consumption with antichamber
08:54karolherbst: 15W actually
08:54karolherbst: imirkin_: I also wait 3 seconds on the pmu before I request a reclock after the load droped
08:54imirkin_: probably a good idea not to go too crazy :)
08:54karolherbst: loading screens ^^
08:55karolherbst: the blob also does this
08:55karolherbst: but I think the blob waits much longer
08:55karolherbst: maybe 10 seconds=
08:55karolherbst: the algorithm itself I use is pretty small
08:55imirkin_: well, they don't get dinged for using up an extra W here and there, but they do get dinged for having less fps :)
08:56karolherbst: int needed_change = (cur_load * 0xff) / target_load; int speed_change = (check * 0xff) / (cur + ((check - cur) / 4)); int score = speed_change - needed_change;
08:56karolherbst: and the pstate or cstate with a score of 0 is the best
08:56karolherbst: and this algo works with pcie speed or memory speed
08:56karolherbst: doesn't matter
08:58karolherbst: now we would have too benchmark this to check if this works well enough across everthing
08:58karolherbst: and before doing that, I want to increase the stability of the pmu communication
09:01karolherbst: imirkin_: yeah well, ...
09:01karolherbst: I don't think anybody will complain more than usual about nouveau whatever happens anyway :D
09:47RSpliet: Agiofws: sorry, I didn't have time to try and help you earlier, glad to hear a lot of problems disappeared with a newer mesa
09:47RSpliet: would you mind, for verification, to first paste the output of glxinfo onto a paste website of choice and share the URL?
09:50Agiofws: RSpliet, it does work BUT for example as i can see youtube videos display green screen
09:50Agiofws: image link: https://i.imgur.com/qM1i72H.png
09:51imirkin_: Agiofws: uninstall any vdpau libraries... it just plain won't work on nv3x... chances are its presence will cause more harm than good.
09:51Agiofws: glxinfo | pastebinit
09:51RSpliet: okay, that looks all right
09:51Agiofws: image link: https://i.imgur.com/V2iDQGf.png
09:51imirkin_: very nice, so something got fixed with new version?
09:51RSpliet: then now listen to imirkin_ please :-P
09:52imirkin_: Agiofws: remove mesa-vdpau-drivers
09:52Agiofws: imirkin_, all of them ^^
09:52imirkin_: just mesa-vdpau-drivers should be enough
09:52imirkin_: [the rest do become somewhat useless, but they won't harm anything]
09:52imirkin_: [but given that it's a binary distro, they may prove tricky to remove]
09:53Agiofws: anything else you would like me to try ?
09:53imirkin_: can you describe the remaining issue you have with bvhacker?
09:53imirkin_: there are a handful of glaringly bad problems with the driver that i'm aware of
09:53Agiofws: let me try again
09:53imirkin_: which could cause renders to basically not happen
09:53imirkin_: if one uses a depth format that's "incompatible" with the color format
09:54Agiofws: image link: https://i.imgur.com/qRYXG1Y.png
09:54imirkin_: heh. i guess that's not supposed to be blue?
09:54Agiofws: imirkin_, there should be a stick man there in the blue background that works with vesa driver
09:55Agiofws: BUT this app is running through wine
09:55imirkin_: yeah.... i bet it's the issue i'm thinking of :(
09:55imirkin_: sorry, no workarounds for now
09:55Agiofws: no BG is blue floor is a grid and there should be a stick man there maybe vdpau driver are to blame ? reboot ?
09:56imirkin_: totally unrelated to vdpau
09:56imirkin_: basically the hardware only supports 16-bit color with 16-bit depth and 32-bit color with 24-bit depth. can't mix and match.
09:57imirkin_: in a perfect world, we (a) wouldn't expose visuals that encourage this sort of thing and (b) handle it with shadow textures when someone wants it real bad
09:57Agiofws: what could the problem be anD i used this repo http://kanotix.com/files/fix/mesa.jessie/backports/ imirkin_
09:57imirkin_: Agiofws: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv30/nv30_state.c#n385
09:57imirkin_: i bet you're hitting that condition
09:58imirkin_: this disables the depth buffer, which in turn causes various misrender
09:58Agiofws: can i do anything ?
09:58imirkin_: Agiofws: well, if you wanted to check whether it's that particular issue, you could make a mesa build with --enable-debug -- this should cause that print to appear
09:58imirkin_: (if it's that issue)
09:58imirkin_: however that will in no way fix anything
09:59Agiofws: any other test ?
09:59imirkin_: nothing offhand...
10:00imirkin_: it's been on my list to fix for like... over a year
10:01Agiofws: have to reboot to see if ytube works
10:01imirkin_: i realize this is of little consolation to you :)
10:01imirkin_: nah, merely restarting the browser should be enough
10:04Agiofws: imirkin_, bvhacker is a simple program why does vesa display and not nouveau?
10:05imirkin_: Agiofws: because it uses software accel
10:05imirkin_: Agiofws: you can also run with LIBGL_ALWAYS_SOFTWARE=1 bvhacker
10:05Agiofws: imirkin_, nope restarting browser still gives me green screen
10:05imirkin_: which should give you the same behaviour
10:05imirkin_: hmmm.... weird. no idea why that'd happen =/
10:06simonpatapon: can someon confirm I cant xinerama with an integrated card and one PCI-e
10:06Agiofws: hhmm let me try thna imirkin_
10:06simonpatapon: someone says it dont work anymore need to pci-e with SLI
10:06imirkin_: simonpatapon: i dunno what people have been telling you
10:06imirkin_: simonpatapon: but that sounds like pure BS
10:07RSpliet: imirkin_: trouble with Xv(MC), unsupported buffer format
10:07Agiofws: LIBGL_ALWAYS_SOFTWARE=1; wine bvhacker ?
10:07simonpatapon: imirkin_: thx!
10:07simonpatapon: i'll continue to try to make this work
10:07imirkin_: RSpliet: hm? xvmc should work... but it won't get used for any web videos
10:07imirkin_: Agiofws: lose the ;
10:08imirkin_: simonpatapon: however if you use xinerama, you lose 3d acceleration. this may be fine for your use-case, but just want to mention it.
10:08imirkin_: simonpatapon: here's an example of how to set up xinerama: http://nouveau.freedesktop.org/wiki/MultiMonitorDesktop/
10:09imirkin_: simonpatapon: and here's an example of how to do it with reverse prime: http://nouveau.freedesktop.org/wiki/Optimus/
10:09karolherbst: well there is always reverse prime too, but this is another kind of evil
10:09simonpatapon: imirkin_: i dont do games thx
10:10imirkin_: simonpatapon: yeah, unfortunately a modern desktop wants accel for just about everything.
10:10simonpatapon: i'll try it anyway
10:11vita_cell: karolherbst your fix still work fine
10:11simonpatapon: I dont want to buy another card + SLI + power supply
10:11vita_cell: I tryesome Steam games too
10:11karolherbst: vita_cell: nice
10:11vita_cell: all with 770
10:12karolherbst: simonpatapon: nouveau doesn't support SLI anyway
10:12imirkin_: simonpatapon: SLI is unrelated to multiple displays... it's related to splitting a single workload on multiple GPUs
10:12vita_cell: I want to ask some question, has AMD GPUs better performance in games (using open-source drivers) that Nvidia GPUs?
10:12simonpatapon: ok thank you.. i'm a total new
10:13vita_cell: using open-source drivers both
10:13imirkin_: vita_cell: depends which gpu's you're comparing, right?
10:13Agiofws: image link: https://i.imgur.com/3IlfGnp.png
10:13simonpatapon: last time I used xinerama, was with AGP and PCI :)
10:13vita_cell: 770 vs r9 390
10:13vita_cell: open-source drivers
10:13Agiofws: imirkin_, THANKYOU ^^
10:13imirkin_: vita_cell: ok, so both reasonably modern ones... i suspect that radeon will get you the better support, including, but not limited to, "maor fps"
10:15karolherbst: thought with kepler it isn't as bad as with others, ohh and tesla is usually in a good state
10:15imirkin_: however i'd bet on the 770 over, say, a ATI Radeon 7000 ;) [aka R100]
10:17imirkin_: vita_cell: the radeon driver has professional support behind it, i think it's pretty much a given that it'll be better.
10:17vita_cell: the bad is. that AMD gpus are very very loud and hot
10:18imirkin_: well, with some recent changes from karolherbst, we're able to squeeze a lot more perf out of kepler GDDR5 gpu's
10:18karolherbst: :) and dyn reclocking is on its way too
10:18vita_cell: gtx770 works very very fine
10:19imirkin_: but it'd be disingenuous to suggest that we're (a) anywhere near what nvidia blob does or (b) properly-supported radeon chips of comparable "raw" performance
10:19vita_cell: karolherbs is a genius
10:19karolherbst: imirkin_: it seems my stuff works, I found a example where my stuff clocks to 0a, max cstate, and clocking to 0f doesn't make any difference
10:19karolherbst: imirkin_: this saves around 3.5W
10:20karolherbst: mhh 10% here
10:20imirkin_: vita_cell: clock-for-clock, nouveau is in the vicinity of 60-80% of blob perf
10:20Yoshimo: karol , you don't own a maxwell card by chance do you?
10:20vita_cell: yes I know, I am very happy with gtx770, but, yes, I want some card with better performance, but using only open-source
10:21karolherbst: I have fermi here though too
10:21karolherbst: vita_cell: the 770 is plenty fast
10:21karolherbst: vita_cell: even with nouveau
10:21karolherbst: or with what do you have problems?
10:21karolherbst: vita_cell: I have a 770m here and I am quite happy with nouveau now
10:21vita_cell: I have no problem, it does work very well,
10:22karolherbst: yeah when you have no problem, why do you need more perf? :p
10:22karolherbst: you still use my branch I assume?
10:23vita_cell: yes, I tested it on other GNU/linux distros, but I must to recompile nouveau.ko for every distro
10:23karolherbst: there isn't much on this branch
10:24karolherbst: I could add some more stuff, which may give you even more perf
10:24imirkin_: it has the pcie thing too right?
10:25karolherbst: only a voltage fix
10:25imirkin_: ah, that's good for some perf increase right?
10:25karolherbst: and gddr5 fix
10:25vita_cell: putting nouveau.ko alredy compiled in Trusquel 7 to Linux Mint 17.2 it goes unstable, it goest above 7010mhz, so unstable
10:25karolherbst: 5% maybe on a desktop system?
10:25vita_cell: but recompiled, it does work
10:25karolherbst: vita_cell: okay so unstable with nouveau from trusquel, but stable with my branch?
10:26karolherbst: I think I will put the pcie stuff there
10:26karolherbst: then you can recompile
10:26vita_cell: only I got stuck at 1032mhz of core, but I don't know if higher will be stable
10:26karolherbst: and see a little perf boost
10:26imirkin_: if he has the pwm voltage thing, make sure that includes the voltage setting fix
10:26imirkin_: i.e. http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=a539a9802af38236101de6ae8d9b827544de0f72
10:27vita_cell: do not reclock memory, I think that 7010mhz is the highest stable
10:27karolherbst: imirkin_: no
10:27karolherbst: imirkin_: he has a stupid vbios
10:27karolherbst: imirkin_: he needs this: https://github.com/karolherbst/nouveau/commit/a23cdce8aef69a95851f200ebd414d4a01a20e84
10:27imirkin_: yeah. it's the vbios that's stupid :p
10:27karolherbst: basically his voltabe table header is empty
10:27vita_cell: I only have the latest fix, this is yours
10:28imirkin_: karolherbst: you should rebase on ben's latest... has some locking fixes too
10:29karolherbst: imirkin_: this is my base branch: https://github.com/karolherbst/nouveau/commits/master
10:29karolherbst: yeah okay
10:29karolherbst: will do
10:29imirkin_: ben was able to run piglit in parallel mode on a GK110 to completion. it still dies for me though.
10:30imirkin_: skeggsb: any progress on that btw? were you able to repro my woes?
10:31karolherbst: mhhh how does someone cherry-pick a branch again :/
10:33imirkin_: is that what you want to do?
10:33imirkin_: you should just fetch and then 'git rebase darktama/origin'
10:33karolherbst: cherry-pick master..$branch_name
10:34karolherbst: imirkin_: no, I wanted to cherry-pick one local branch on vita_cells stuff
10:34karolherbst: the pcie stuff
10:34karolherbst: imirkin_: I have to remove 4.3 incompatible patches from bens master
10:34karolherbst: which is only one commit
10:34vita_cell: I am on 4.3
10:34karolherbst: vita_cell: go into the nouveau repository pls
10:34karolherbst: there are some updates for ya
10:35vita_cell: what is the repository?
10:35karolherbst: you should have it already
10:35karolherbst: from where you compiled nouveau
10:35vita_cell: the git clone command?
10:35vita_cell: wait, I will search the repository
10:36imirkin_: karolherbst: yeah, i have to revert the "drm-next a76edb8cec0cc864c8b72fa7e84a72336e033e23" commit
10:36vita_cell: I cant understand what it is
10:37karolherbst: imirkin_: well I simply rebase -i and remove it
10:37karolherbst: vita_cell: when you are in the source directry do: git fetch origin
10:38karolherbst: then: git reset --hard origin/nve7_vita_cell_voltage
10:38karolherbst: and compile and install nouveau again
10:38vita_cell: https://github.com/karolherbst/nouveau.git -b nve7_vita_cell_voltage
10:38karolherbst: vita_cell: did you remove it?
10:38karolherbst: you should still have it somewhere
10:38imirkin_: karolherbst: probably not called 'origin' for him ;)
10:38karolherbst: imirkin_: I gave him the git clone command
10:38karolherbst: and origin is the remote name by default
10:38vita_cell: this is the repository?
10:39vita_cell: git clone https://github.com/karolherbst/nouveau.git -b nve7_vita_cell_voltage
10:39karolherbst: vita_cell: well yes, but I thought you have a clone already locally
10:39karolherbst: if not, that command alone will do the trick
10:39vita_cell: Yes. I have save source of this nouveau folder
10:39karolherbst: yeah, then go into it
10:39karolherbst: and do this git fetch and git reset command I told you
10:41karolherbst: rather do git log
10:41karolherbst: and give me the top line
10:41vita_cell: what coomand?
10:41karolherbst: git log
10:44vita_cell: some trouble
10:44karolherbst: what is inside it?
10:44karolherbst: ls -la
10:45karolherbst: you have to switch into nouveau first
10:45karolherbst: vita_cell: okay
10:45karolherbst: git log | head -n1
10:46karolherbst: ahhh the new github design is finally better
10:46karolherbst: git fetch origin
10:46karolherbst: git reset --hard origin/nve7_vita_cell_voltage
10:46karolherbst: git log | head -n1
10:48karolherbst: seems about right
10:48karolherbst: now you can compile nouveau again and do all the other stuff to install it
10:49vita_cell: now, the nouveu folder it is the same or it is another one?
10:50vita_cell: or I must to do "cd" to another folder?
10:50karolherbst: like you built id before
10:50karolherbst: cd drm
10:51karolherbst: all that copy and initramfs crap
10:52vita_cell: what it fixes? or what new?
10:52karolherbst: basically I just added some upstream commits and pcie "reclocking"
10:53karolherbst: you should get a little bit of more perf from that
10:53karolherbst: but don't expect wonders
10:53vita_cell: yes I know lol
10:53karolherbst: still nearer to the binary driver
10:54vita_cell: I must to copy
10:54karolherbst: imirkin_: you said something about this Z thingy waaaay back, z curling or something like that. Any plans to do something about that? Because if not, maybe I could try to figure it out or something
10:54imirkin_: curling... heh. i like it.
10:54karolherbst: yeah, just overwrite your old nouveau.ko fil there
10:55imirkin_: i think the technical term is 'culling'
10:55karolherbst: ahh culling
10:55karolherbst: this could give us some overall perf
10:56karolherbst: imirkin_: is it this? http://http.developer.nvidia.com/GPUGems/gpugems_ch29.html
10:57imirkin_: karolherbst: all i know about it is that it exists and we don't support it
10:57vita_cell: to reboot
10:57imirkin_: karolherbst: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c#n8
10:57imirkin_: karolherbst: presumably that's commented out for a reason
11:00vita_cell: already did,
11:03karolherbst: vita_cell: dmesg | grep pci
11:05karolherbst: you have either a cpu with only pcie 2.0 support or a motherboard
11:05karolherbst: if not, you could just tell me what cpu and motherboard you have
11:06vita_cell: the problem is, that I damaged my i5-3570k
11:06vita_cell: board supports 3.0
11:06karolherbst: what is your current cpu?
11:06vita_cell: but now I using i7-2600
11:06vita_cell: board Asrock z77 extreme4
11:07vita_cell: board supports 3.0. But CPU doesn't I think
11:07karolherbst: usually boards only provide 2.0 stuff
11:08vita_cell: not, this board is 3.0, I think that it stucks at 2.0, cuz CPU
11:08karolherbst: yeah, because the board takes the lanes from the cpu
11:08karolherbst: the question is if the board itself has a chip which provides pcie 3.0
11:09vita_cell: No idea,
11:09vita_cell: I think that CPU and board must support 3.0
11:09vita_cell: but I have no idea
11:09karolherbst: yeah okay, but then it is right that nouveau only detects 2.0
11:10vita_cell: yes I think. this is why
11:10imirkin_: says it only does 5GT/s
11:11vita_cell: 5gt/s vs...?
11:11imirkin_: which is what PCIe 3.0 gets you
11:12vita_cell: I read some info, that performance is like the same
11:12vita_cell: but personally I have not tested it
11:12imirkin_: it just explains why it only went up to pcie2 5gt/s instead of pcie3 8gt/s
11:13karolherbst: imirkin_: the print is part of the init stuff
11:13vita_cell: yes, my CPU limited, but do you think that 3.0 will make some difference?
11:14karolherbst: I check there already what the card thinks the system supports
11:14imirkin_: er hrmph.... perhaps that's the wrong thing to look at
11:14imirkin_: ok yeah. it says you only get PCIe 2.0
11:14vita_cell: if I gaming, I will gain some fps with 3.0, but not much I think
11:14imirkin_: while with a i7-3xxx you'd get PCIe 3.0
11:14vita_cell: that it is
11:15imirkin_: so all good
11:15imirkin_: the amount of extra perf would likely be minimal
11:15vita_cell: it worth to upgrade to 3xxx series?
11:16karolherbst: maybe +2% top
11:16vita_cell: yes, that is I think
11:16karolherbst: I did the pcie stuff mainly, because the difference for me was between +5% and +25%
11:16karolherbst: but I have a laptop
11:16karolherbst: ohh wait, with glxgears it was +250%, but that doesn't count
11:17imirkin_: not to mention glxspheres
11:17vita_cell: 2.0 vs 3.0?
11:17imirkin_: more like 1.0 vs 3.0 :)
11:18vita_cell: did you know that there are some devices to plug in to yoour laptop's pcie?
11:18imirkin_: most of these cards boot up in pcie 1.0 or if in 2.0, still only 2.5GT/s
11:18vita_cell: for plu external gpu
11:18imirkin_: yeah... MXM
11:21vita_cell: so, that latest fix/update does nothing for me?
11:21imirkin_: no, it flips you to 4GT/s
11:22imirkin_: er, 5GT/s
11:22vita_cell: and with previous version?
11:23vita_cell: huge fix
11:23imirkin_: not so much a fix
11:23imirkin_: as implementing a feature
11:24vita_cell: you guys, are genius
12:18rardiol: I'm having trouble with https://bugs.freedesktop.org/show_bug.cgi?id=92438 .Is the patch on comment 27 a proposed fix or a workaround? Can I do something? imirkin_, could you help ?
12:19imirkin_: rardiol: not 100% sure :) i need to think harder about it
12:20imirkin_: rardiol: will def push something out in time for 11.1
12:20imirkin_: rardiol: are you the original bug filer, or just someone else with a similar issue?
12:20rardiol: someone else
12:21imirkin_: are you sure it's the same issue?
12:21imirkin_: i'm not convinced that the second guy's issue is the same as the first's in that bug
12:21rardiol: glium's (from rust) programmer said so
12:22imirkin_: oh, you're also use glium? then def yes ;)
12:22imirkin_: at least your issue is the same as the other glium guy's
12:24rardiol: ok. so the problem is defitively with nouveau? would a apitrace or something help you? or testing that mesa patch?
12:25imirkin_: rardiol: the prob is definitely in nouveau. you can use that mesa patch, it should fix the issue for you.
12:25imirkin_: rardiol: but i need to think if it'll actually work ok in all cases or not, esp for nv30 which shares that buffer creation logic
12:26imirkin_: if that patch doesn't help, make an apitrace
12:27imirkin_: rardiol: if you know the glium guys, make sure they look at my aside in my last comment
12:27imirkin_: rardiol: also i propose a way to disable using the feature in glium, so you can test that out as well
12:27imirkin_: (in comment 30 of that bug)
12:32karolherbst: vita_cell: the pcie speed only effects data transfered to the gpu, it doesn't effect the speed of the gpu itself, it rathers let data be transfered earlier, so the gpu can start to do something earlier too
12:33karolherbst: it also helps with prime, because with prime you copy from one gpu to the other over the pcie bus, so you get a general speed up there, because additional to all the textures and gpu commands you also have to transfer every frame
13:06karolherbst: imirkin_: which email address do I have to use to ask stuff to nvidia?
13:07karolherbst: I think I will ask about those pdaemon counters and how we can now which part of the gpu is currently too slow for the current load
13:07imirkin_: gpu-public-documentation <email@example.com>
13:07karolherbst: or something like that
13:08imirkin_: please write a thought-out email that asks everything you need in a logical manner, one that doesn't require them to know the details of nouveau or our naming convention.
13:09karolherbst: though they also use the reg for gk20a already
13:10imirkin_: like all of nvidia knows about this?
13:10karolherbst: ohh okay
13:11karolherbst: could I ask about bit 0x1000 in reg 0x10a504 for kepler cards? Or is this too vague
13:11imirkin_: i would assume a minimum of knowledge on the receiver's end... they're well-meaning, and have access to docs, but aren't necessarily experts on all aspects of every gpu family
13:11imirkin_: no, that's quite specific enough
13:11imirkin_: you could even ask for the whole reg :)
13:12karolherbst: sadly the gk20a pmu counters code isn't the best :/
13:12karolherbst: it has to be used for gk20a anyway
13:12karolherbst: so maybe chances are high they actually provide answers
13:13karolherbst: imirkin_: any idea how the pmu binary is uploaded in the android driver?
13:13karolherbst: ohh wait, I could check there
13:13karolherbst: good idea
13:13rardiol: imirkin_: patch works, thanks. do you need anything else for the real fix or just think more?
13:14imirkin_: rardiol: just time to think ;)
13:16imirkin_: rardiol: thanks for confirming that the fix works for you though!
13:16imirkin_: rardiol: if you could mention that in the bug, that'd be super
13:16karolherbst: imirkin_: do you have the android source at hand? I try to find it, but I fail :/
13:16imirkin_: karolherbst: nope
13:17imirkin_: karolherbst: "android gk20a" -> https://android.googlesource.com/kernel/tegra/+/b445e5296764d18861a6450f6851f25b9ca59dee/drivers/video/tegra/host/gk20a
13:17karolherbst: ahh thanks
13:19karolherbst: I don't feel like dissassemble the falcon blob for the pmu :D
13:21karolherbst: there is powergating stuff though
13:21karolherbst: there are those counters
13:23karolherbst: imirkin_: I am stupid, of course the source doesn't help with memory related counters :/
13:43Agiofws: karolherbst, would you know why i am getting green screen in you tube videos ?
13:44karolherbst: Agiofws: no idea, I would say I am usually the one with the smallest knowledge about nvidia gpus here currently (maybe that changes later :D )
13:44imirkin_: ftr, green is the color you get if you have all 0's and convert from YUV to RGB
13:45imirkin_: that in no way explains this particular failure.
13:46Agiofws: a fix ?
13:49Agiofws: do i have to remove all vdpau packages ?
13:49Agiofws: image link: https://i.imgur.com/ZTwvQH3.png
13:49imirkin_: it must be doing something odd
13:50Agiofws: maybe try another browser?
13:50imirkin_: i'm sure that LIBGL_ALWAYS_SOFTWARE=1 will fix it right up
13:50Agiofws: on browser?
13:50imirkin_: looks like it's doing a blit but its texture coordinates are messed up? probably doesn't deal with the lack of npot
13:50imirkin_: yeah, on the browser
13:51imirkin_: if that helps, create an apitrace and we can see if it's our fault or the browser's
13:51Agiofws: image link: https://i.imgur.com/nDwOsmO.png
13:51Agiofws: imirkin_, it works with iceseale any ideas ?
13:52imirkin_: it = ?
13:52Agiofws: iceweasel == firefox
13:52imirkin_: right, so it's unclear to me what works, what doesn't
13:52Agiofws: no green screen videos in youtube something to d owith html5 or flash ?
13:52imirkin_: can you elaborate as to what it is that works and what it is that doesn't?
13:53Agiofws: why does it work in one browser and not in chrome?
13:53imirkin_: ok... so chrome is where it doesn't work?
13:53Agiofws: link: https://i.imgur.com/ZTwvQH3.png <--- green screen in chrome
13:53imirkin_: ok, can you try running chrome with LIBGL_ALWAYS_SOFTWARE=1 ?
13:53imirkin_: (make sure you exit all chrome windows first)
13:56RSpliet: (also, please clarify whether this is Google Chrome or Chromium, and what your source is (repository, website?))
13:56imirkin_: RSpliet: shouldn't matter
13:57RSpliet: imirkin_: sure? does Chromium ship with "Pepper" Flash? Same HTML5 video codecs?
13:58imirkin_: RSpliet: thoroughly unlikely to matter.
13:59Agiofws: ok imirkin_ it still goes green ; google-chrome is installed via synaptic
13:59imirkin_: Agiofws: hmmmmm ok.
13:59imirkin_: Agiofws: i got nothin'
13:59imirkin_: use firefox ;)
14:00Agiofws: that is
14:00Agiofws: maybe try beta ?
14:01imirkin_: dunno, i doubt that'd change anythign
14:02RSpliet: Agiofws: if you go to youtube.com/html5, you can toggle HTML5 video
14:02Agiofws: Are you able to hear the audio of a YouTube video on your computer, but the video player is completely green? If so, try watching the video in a different browser. If that doesn’t work, here are some additional troubleshooting tips. Disable hardware acceleration Update your graphics driver
14:03RSpliet: Agiofws: yes, it's likely that there's a bug in the driver that only shows for your class of hardware, doesn't mean that toggling HTML5 on or off could circumvent your problem :-)
14:04imirkin_: well, it's odd that LIBGL_ALWAYS_SOFTWARE=1 didn't fix it
14:04RSpliet: Chrome does weird sandboxing, it might lose env variables in the process
14:04imirkin_: i could def imagine chrome failing for non-npot-capable drivers, but... software should work fine with it
14:04imirkin_: ohhhhhhh yeah
14:17Agiofws: imirkin_, how can i get green screens in vimeo and youtube with chrome how can this be mesa driver related?
14:17Agiofws: image link: https://i.imgur.com/tzSAnTb.png
14:17Agiofws: take a look ^^
14:18imirkin_: right click, disable acceleration?
14:18imirkin_: dunno if that's an option
14:21Agiofws: can't see the right click menu its black
14:22Agiofws: It appears that the change is causing the shader version to be incorrectly parses as 1.50, which should equate to a OpenGL core profile version of 3.2 rather than the correct 3.3.
14:22Agiofws: See "Detecting the Shader Model" on the OpenGL site here:
14:22imirkin_: your GPU only gets GL 1.5, and GLSL 1.10 (or maybe 1.20)
14:22imirkin_: Agiofws: go to chrome://flags
14:22imirkin_: and see if you can just disable gpu accel
14:26Agiofws: can't in linux
14:26imirkin_: there are a bunch of things in there about disabling various gpu things
14:27karolherbst: that's in chrome://flags
14:27imirkin_: isn't that what i said?
14:27karolherbst: somehow I read gpu
14:27karolherbst: my mistake
14:40Agiofws: karolherbst, imirkin_ disabled h/w accel and now it works
14:40imirkin_: probably a bug in chrome, it's probably not expected to run with such old GL versions
14:40Agiofws: is this mesas fault or chromes or debians ?
14:41imirkin_: you'd have to make an apitrace to be sure
14:41Agiofws: it worked with mesa 10.3.2
14:41imirkin_: it's unlikely to be debian's fault though :)
14:41imirkin_: with the same version of chrome?
14:51marcosps: hi guys :)
15:13marcosps: imirkin_: I'm studying shaders and things related, so I'll try to send my task until Friday :)
15:44simonpatapon: re guys
17:24marcosps: imirkin_: around?