00:06 tobijk: going to bed, gn8 :)
05:46 kloofy: morning, i got bit overwhelmed yestirday, got sober now, i have tried to drink lot less and generally have succeeded but yestirday was one of the other days
05:49 kloofy: if i talk one to one with those persons i always get information that is something new to me, to add into my theories, so people here are still rather smart to me despite that i can read stuff from internet too
06:52 kloofy: in computer science knowing a bit about filosofy should be a good thing, that means how you deal with things which granularity you do not precisely know, you vaguely know the end result or key frames and live without knowing the low level physical gate level details
06:54 kloofy: i think when this phisophical truths are not well studied, it would drain humans psychology in too large degree instead
07:17 karolherbst_work: neoraider: there is no memory reclocking on fermi yet and engine reclocking is also disabled, though it won't give you much of a performance boost usually
07:17 kloofy: there is a fuzz around the net that design in programmable device is 40times buliker and what not, while controversiely there are reports that state the other, and we had to use a little bit common sense to understand which theory is correct
07:17 kloofy: and it's i came up long time with a thoery that transistor is a transistor no matter if that is on asic or fpga
07:19 kloofy: you still end up feeding it with a memory and keyboard input which are pulled up to digitally either open the switch or close
07:24 kloofy: imo so to speak doing preprogramming the state in larger degree upfront from the memories, is much more intelligent
07:25 kloofy: and in that sense yanks formed hall of fame , the fpga inventor or theory received a larger kudos, it has bit weaknesses in security perhaps but..it's wiser
07:29 kloofy: so i think that kinda of theory where fpga is just a little slower and by no means design being bulkier is the correct theory, wheras i don't intend to refigure out the rough gate level details, how the logic is configured and reconfigured
07:30 kloofy: some sort of geniuses allready did that
07:33 kloofy: yeah the capacitor is the one that controls the switch, we know that capacitors could store energy to close the switch or by emptying it and opening hence, independantly it can be predone
07:34 kloofy: so in sense of philosophy definitely i could say that this kind of prograbbility wise approaching to the stuff is lot more elegant and definitely correct way of doing things
07:41 kloofy: but such a die nowdays can be formed/designed without acquiring companies patent portfolios, especially fabless company ones i belive
07:42 kloofy: overall it's fascinating world there , and i am trying to state that people would filter what they read
07:45 kloofy: i could be bit off there now, life has been critically tense, i've forgatten the details i had read but vaguely remember, that bigger vendor dies had some sort of tech breakthrough at transistor level, starting from spartan and cyclone series of some sort
07:46 kloofy: which rather more closed the gap in perf against asics
07:47 kloofy: it was something about introducing new pass-on transistor technology, but i ccould be slightly off there, anyhow it was an improvement i can't remember what was the nature of it in litography sense
08:10 kloofy: anyways off to sleep, and karolherbst_work it's still nice that you have continued working on reclocking, i am not bullying with you world is rich , explaining a bit i have my own troubles that originate from other people troubles, if we manage to understand that we are so rich with our planets resources
08:10 kloofy: things would go better i assume
08:13 kloofy: i came across a need to earn some money my own, i'll be putting together a team where i am also one of the chief archidects just for the mission, i hope it turns out well
08:23 karolherbst_work: ezbench
08:23 karolherbst_work: ...
08:23 karolherbst_work: ctrl+f didn't work
08:25 karolherbst_work: mupuf: is ezbench able to read out the fan speeds/temperature from nvidia? Otherwise I don't really think it makes that much sense to compare anything besides plain opengl performance with nvidia
08:29 karolherbst_work: mupuf: but to be honest, I think I will just stick to the gputest benchmarks for now, cause I don't see the point in showing results of complex benchmarks. I talk about the kernel space in the end and poor performance in heaven or somewhere else is highly related to poor OpenGL/shader-compiler implementation
08:29 karolherbst_work: showing the difference in power consumption though might make sense
08:37 kloofy: i am bit lonely at times though, did not yet manage to go to sleep, to make the 3d firmware i would need play with interrupts a bit, i can see the rasterizer kernel on intel's code, normally ff happens behind the scenes like clipping, blending, rasterization and tessellator, last time i looked
08:38 kloofy: the code for them was possible to be fetched, another possible issue is hardware one, if there are powerful devices, to really make them power effecient
08:38 kloofy: and i think for that i need proper batteries and get someone to make me a circuit too
09:07 pmoreau: karolherbst_work: Actually, I could include one of your branch onto the image if you think it could be useful (just saw Elias’ comment on Phoronix).
09:08 pmoreau: karolherbst_work: I haven’t tested the reclocking yesterday: I came back home late and went straight to bed…
09:11 karolherbst_work: pmoreau: no problem
09:11 karolherbst_work: pmoreau: I didn'T tell you how anyway :p
09:11 pmoreau: Well, I was supposed to ask you when I had time to test it :-)
09:11 karolherbst_work: right
09:12 karolherbst_work: pmoreau: my master_work branch usually contains useable code on top of my master_$current_kernel_version branch
09:13 karolherbst_work: and I don't update it that often
09:13 pmoreau: So, kepler+maxwell reclocking at least?
09:13 karolherbst_work: yeah, and pmu counters
09:13 karolherbst_work: and minor things
09:14 pmoreau: Ok. The automatic recloking as well?
09:15 karolherbst_work: nope
09:16 karolherbst_work: before I include that, I want a switch to default disable it first :D
09:16 karolherbst_work: usually you can rebase all of my branched of current nouveau-master, because at least I keep that updated
09:19 pmoreau: Is it much work to disable it?
09:21 pmoreau: I’ll have a look over the weekend to add your master branch.
09:27 karolherbst_work: pmoreau: well, I would need to add a switch for the module and just ignore the pmu events on the host. the pmu will still the host to reclock though
09:29 mupuf: karolherbst_work: no, there is no support to read from nvidia yet, but it can be added
09:29 mupuf: but we would need to name metrics in the same way
09:30 pmoreau: karolherbst_work: Ok
09:31 karolherbst_work: mupuf: reading out power consumption from nvidia is annyoing anyway :/
09:52 karolherbst_work: pmoreau: so, I do think it might make sense to have something like nouveau-staging, so that interested users can try out stuff faster, even if that's just to confirm a fix or so. But how would we want to manage it? Just a collection of patches you would apply on top of master and deploy it as a live system?
09:53 karolherbst_work: or even a repository every of us can push stuff to?
09:53 pmoreau: Maybe
09:53 karolherbst_work: mhh I like the repository idea more somehow :D
09:53 pmoreau: (Just finishing something first, before thinking abou tit)
09:53 pmoreau: *about it
10:09 mupuf: karolherbst_work: yeah, it is, but there is a library interface
10:11 karolherbst_work: mupuf: right, which we can use on so many gpus :p
10:11 mupuf: ah ah, we can use it on all the gpus
10:11 mupuf: it just is ... unstable :D
10:12 karolherbst_work: ohhh right, you meant the nouveau interface
10:12 karolherbst_work: I thought you meant the nvidia library
10:12 mupuf: I did mean the nvidia library
10:12 karolherbst_work: mhh
10:12 mupuf: whatever nvidia-settings is using to get access to the information
10:13 karolherbst_work: but I thought only titans/quadros can use it
10:13 karolherbst_work: I mean for power consumption
10:13 karolherbst_work: bbl: launch
10:14 mupuf: yeah
10:14 mupuf: and all maxwells
10:14 mupuf: but still, useful information anyway
10:34 karolherbst_work: mupuf: every maxwell? nice
10:34 karolherbst_work: ohh right, you mentioned it before I think
10:35 mupuf: that was why I bought my maxwell in the first place
10:36 karolherbst_work: I see
10:36 karolherbst_work: and then I REed it on the titan anyway…
10:36 karolherbst_work: somehow I wasn't aware of that
10:39 karolherbst_work: mupuf: I was thinking to add a graph for stock/reclocked nouveau + nvidia results of gputest for kepler and maxwell. I could do that with the titan, then we would have nvidia provided power consumption for both
10:39 karolherbst_work: I doubt there are any differences between maxwell1 and maxwell2 on the performance side, so I just use a maxwell2
10:40 karolherbst_work: would that be better suited for the status talk or my talk?
10:45 mupuf: well, this the status update is more functional
10:45 mupuf: and yours is more perf ...
10:45 mupuf: maybe samuel will want to make use of it
10:55 karolherbst_work: well, mine is more about dfvs :p
10:56 karolherbst_work: but I was thinking about it this way: since last year we can fully reclock those gpus and this leads us to performance comparable to nvidia on kepler and still bad on maxwell
10:56 karolherbst_work: also a reclocked maxwell2 gpu is good enough for a status update I guess :p
10:58 RSpliet: karolherbst_work: make sure to phrase it as a "we are working on X, made progress y, need to do z before bringing it upstream, expect that to be useful to the users at time t"
10:58 karolherbst_work: RSpliet: sure, I will make it very clear, that we aren't able to control the fans, so that this is pointless for general usage
10:58 RSpliet: that's more useful - user-oriented than "look at how cool y is, which works only under conditions c1, c2, c3, c4, c5, c6 and c7 with branch b1 on github!!!"
10:59 karolherbst_work: RSpliet: right
11:00 RSpliet: I know it's tempting to show off all the tricks, but think of all the phoronix readers who then feel like we have everything ready but just keeping it for ourselves :-P
11:00 karolherbst_work: :D
11:00 karolherbst_work: that's how I work
11:01 karolherbst_work: but yeah, I know
11:01 RSpliet: ;-)
11:01 karolherbst_work: but I made it very clear in my last cover-letter what the status is I think
11:01 RSpliet: sorry, hope I don't sound too bossy, just trying to be helpful :-)
11:02 karolherbst_work: nah, I am already aware after I was unclear like 3 times and phoronix assumed "too much"
11:02 karolherbst_work: mhh, maybe I should be even more precise in the future about that
11:03 RSpliet: I think it's safe to assume that people have more difficulty understanding the conditions under which "feature X" works than "feature X"
11:03 karolherbst_work: right
11:04 RSpliet: there's no general sentiment on how large the percentage of cards is that fulfil the conditions :-)
11:04 karolherbst_work: when I talk about maxwell2 reclocking I will state: 1. no working fans 2. not possible to give any ETAs
11:04 karolherbst_work: mhhh true
11:04 karolherbst_work: but for maxwell2 it is easy: every gpu with a fan
11:04 karolherbst_work: :D
11:04 karolherbst_work: OHHHHHH
11:04 RSpliet: for maxwell2 reclocking, how hard are we pursuing NVIDIA atm with our cyberblowtorch?
11:04 karolherbst_work: how slow am i
11:04 karolherbst_work: ....
11:05 karolherbst_work: mobile chips are EC controlled
11:05 karolherbst_work: so the fans are working there
11:05 karolherbst_work: ....
11:06 RSpliet: gnurou: do you have any updates on PDAEMON firmware releases?
11:07 RSpliet: I was thinking about in a not-so-distant future to harmonise memx script format with nvidia opcodes to a certain extent
11:07 karolherbst_work: yeah, that would make sense
11:07 karolherbst_work: I think it wouldn't do any harm, if we would make our pmu stuff compatible with nvidias
11:07 karolherbst_work: even if they change something, we can still use nvidia pmu for older chips hopefully
11:08 karolherbst_work: maybe
11:08 karolherbst_work: if that makes sense
11:08 RSpliet: well, there's the script opcodes (which erm... well, the memory training opcode I introduced for efficiency and to avoid having to implement branching could become interesting) and there's the FIFO communication methods
11:09 RSpliet: opcodes are probably not so difficult
11:09 karolherbst_work: sadly we can't know for sure when a fan is EC controlled, so I don't plan to upstream a solution like: enable reclocking on maxwell, when there is no fan
11:09 RSpliet: surely the VBIOS have some info on that
11:10 RSpliet: so that's not entirely infeasible as a stop-gap
11:11 RSpliet: but I think the more correct way to go is "enable DRAM reclocking when using nouveau firmware for PDAEMON", and "only upload nouveau PDAEMON firmware on Maxwell1 and older, and Maxwell2 if we don't have to control the fan"
11:12 RSpliet: anyway, I should go back to work ;-)
11:14 karolherbst_work: yep
11:15 mupuf: karolherbst_work: yeah, how about just showing at the end that it unfortunately does not fix all the issues on all the platforms
11:17 karolherbst_work: mupuf: yeah, I'll try to be as precise as possible
11:18 karolherbst_work: but maxwell1 reclocking will come, hopefully even with 4,9
12:10 dcomp: will the maxwell reclocking branch mean I dont have to boot with NvClkMode and runpm=0
12:11 pmoreau: dcomp: Why do you need to boot with runpm=0?
12:12 dcomp: I think after suspend it doesnt reclock correctly or something. without NvClkModr to force a reclock VRAM doesnt work
12:12 dcomp: (vbios doesny bring up ram)
12:12 pmoreau: Oh, doesn’t sound good… :-/
12:14 pmoreau: I think only the `dynamic_reclocking` branch will do dynamic reclocking, for the other ones you still need to manually reclock, so in your case you will still need the boot options.
12:16 pmoreau: karolherbst_work: The repo is going to be highly annoying to deal with, as there will be a lot of rebasing and force pushing going on.
12:17 karolherbst_work: pmoreau: exactly
12:18 karolherbst_work: but ben also force pushes
12:18 karolherbst_work: :D
12:18 pmoreau: And so do I :-D But the difference is that only Ben pushes to his repo, and same goes for me.
12:19 pmoreau: If we have 5 devs force pushing to the same repo, this is going to be a completely different story
12:19 pmoreau: (or even 2)
12:20 karolherbst_work: mhh right
12:20 karolherbst_work: then we do merges :p
12:20 pmoreau: --"
12:21 pmoreau: I don’t want to look at the history of that repo! Ever! :-D
12:21 karolherbst_work: then we could do a repository like wine-staging
12:21 karolherbst_work: with a script
12:22 karolherbst_work: just a bit annoying to deal with
12:22 karolherbst_work: but so would be a repsotiory with merges or force pushes :D
12:22 pmoreau: There won’t be that many patches going to the staging area, it will mostly be series, and there won’t be that many either, right?
12:22 karolherbst_work: right
12:22 pmoreau: So I could build one module per such serie, and have an extra one which would combine them all.
12:22 karolherbst_work: one issue though: some series might depend on each other due to conflicts
12:23 pmoreau: Hum
12:23 karolherbst_work: pmoreau: a list of the series names to apply as a txt file
12:23 karolherbst_work: and then we have an explicit order as well
12:23 pmoreau: Yep
12:24 pmoreau: Might want to do the same for Mesa as well
12:24 karolherbst_work: good idea too
12:24 karolherbst_work: and then we could even create a staging bugzilla :D
12:24 karolherbst_work: or simply github issues?
12:25 pmoreau: I would say just use the same bugzilla, maybe with a prefix and link to the corresponding image.
12:25 pmoreau: Multiplying the numbers of bugzillas to track doesn’t sound like a good idea
12:26 karolherbst_work: well, we could just use the github issues for this
12:26 pmoreau: s/bugzillas/bugzillas & other bug trackers
12:27 pmoreau: I am not sure what we would gain from using the github issues, over using the current bugzilla
12:28 karolherbst_work: mhh, actually right. I just don't want to have buzzillions of bugzilla accounts
12:28 karolherbst_work: and I guess some user think the same
12:28 pmoreau: ;-)
12:28 karolherbst_work: but yeah, we could use the current bugzilla
12:29 karolherbst_work: do we want to make a nouveau github project and move it there?
12:29 karolherbst_work: or just add it to the envytools thing?
12:30 pmoreau: Just prefix everything subject with [STAGING], and in the URL field, you put a link to the image used.
12:30 pmoreau: s/everything/every
12:30 karolherbst_work: I meant github
12:30 karolherbst_work: for the git repositories
12:31 pmoreau: (For the prefix thing, I was still talking about the bugzilla, not the Git repos yet)
12:31 karolherbst_work: I know
12:31 pmoreau: What do you want to move to Github?
12:32 karolherbst_work: the repositories with the patches or where do you want to manage that?
12:32 karolherbst_work: or how
12:33 pmoreau: I was more thiking like, instead of having only the branch names inside the text file, it could also contain the URL of the repo.
12:33 karolherbst_work: mhhhh
12:33 karolherbst_work: I don't think that would work
12:33 karolherbst_work: especially if branches have different bases
12:33 karolherbst_work: I was thinking about something like that:
12:33 karolherbst_work: git repository with folders for each series
12:33 karolherbst_work: text file for order of applies
12:34 karolherbst_work: shell script which clones a given nouveau base (or master) and applies all patches on a new branch created locally in the clone
12:34 karolherbst_work: and this script can be used by your stuff to generate the staging image
12:35 karolherbst_work: this way we know that everything applies well and we can't break stuff by pushing into our own repositories
12:35 pmoreau: So the "rebasing" step is moved to the dev, rather than when applying the patches to generate the image
12:35 karolherbst_work: yeah, if you update a series, you have to make sure everything applies well when running the script
12:36 pmoreau: Ok
12:36 karolherbst_work: we could even put a CI on top of that
12:36 pmoreau: Yep, was thiking about it
12:37 pmoreau: brb
12:39 karolherbst_work: and I would say those patches should be all generated through git format-patch, so that one could even bisect the repository
12:39 karolherbst_work: because we can simply apply those patches with git am
12:53 kloofy: i don't have much clue about power management myself on asics, caps to learn have degraded too, and i haven't needed this info, but for asics users it's indeed crucial
12:54 pmoreau: karolherbst_work: How do we pick the basis for the series? (Well, it’s relatively easy to pick the first one) but how do you update the basis?
12:55 pmoreau: And I was wondering: do we want an image containing those modules and so on? Or rather provide them as packages instead? Cause they should probably be tested in some environment, be it to benchmark them, or to check whether they fix a bug.
12:56 pmoreau: And I feel that the image is already big enough. Plus, if it’s a serie which is often updated, you don’t want to dl a > 1GB image every week.
12:59 karolherbst_work: mhhh
13:00 karolherbst_work: pmoreau: base should be current nouveau master
13:00 karolherbst_work: we just need to update it from time to time then
13:00 karolherbst_work: as for the image
13:00 pmoreau: And do you wait for everyone to update their serie before switching to the new base commit?
13:01 kloofy: btw: this pascal could have some sort a new memory on board right, stuff is prolly different there, hbm or what they called it?
13:02 kloofy: karolherbst_work: have you had access to pascal too allready?
13:03 karolherbst_work: pmoreau: it should be fine most if the time
13:03 pmoreau: kloofy: The P100 has HBM2, while the Titan X and 1080 have GDDR5X, and 1060 and 1070 have GDDR5.
13:03 karolherbst_work: pmoreau: when I rebase on bens newest master I have to adjust mabe with a 2% chance
13:04 karolherbst_work: so it would be mainly: change base, see if everything works, fine
13:04 karolherbst_work: if not, see if the change is trivial
13:05 karolherbst_work: pmoreau: and for the repository: maybe you could do somethig like that
13:05 karolherbst_work: mhh, wait
13:05 karolherbst_work: maybe we could clean up the history up to the base in git?
13:05 karolherbst_work: then the git repository should be rather small
13:06 kloofy: pmoreau: ok, the chips i plan to assemble into solutions, possible options are bit shallower, ddr3 ddr3 or hybrid memory cube, last one being equivalent to medium level gddr5
13:06 karolherbst_work: mhh but well
13:06 karolherbst_work: but you are right, if we update it often...
13:10 kloofy: *ddr4
13:12 kloofy: anyhow i received a comment on #asm that i am stalker and harrash irish and my old girlfriend, i understood that i get such claimes , but it is not all the way it went down, i was stalked and harrassed myself humiliated violated and with absolute miracle shit went to also took a blame for it, and was rotting in the instution
13:12 kloofy: if such scams are continued with things will get very very serious
13:23 kloofy: it's ok let them live their own life which they haven't managed so far, totally wasting my life i can not tolerate taking a blame for this, and respective actions will be taken in that case quite soon if such an attitude continues, like fabricating entirely false claims
13:25 kloofy: i come here because i see potential in you, where as there are also bit depressive signs, the intelligence should be enough to get my point of views
13:25 kloofy: here where as i gave up on many persons here allready
13:25 kloofy: i mean in my country, it was a hopeless case nontheless
13:27 kloofy: i have my own long time friends who are tested, and i bit ignored gangs here where i just did not see the logics in their commited actions to see any potential
13:30 kloofy: and it also affected me being treated in a way, that me who has potential to talk about things so others understand, i composed letters during such mental breakdowns that noone really was able to understand like ajax, cause i was severely shocked about their activity
13:35 kloofy: i mean when it was all done to affect my thinking in a bad way, of course i took a hit too, but wether i want to heal/cure those things in mental institution is totally another thing, i understood how i was dicketed and i did not want that
13:41 kloofy: anyways enough of that, now i head out to meet my old friend, the losses have been immense , maybe i prove to be a strong person and get over it, it was kinda it was kinda predicted my some whiches too that no matter how hard i got, with that time i probably have allready compiled a break
13:41 kloofy: through
13:44 kloofy: where the sociaty has screwd me and fullfilled my life with scams and lot of depression, i mean nothing to do i just i just have to face it, and that all without injecting stuff
13:54 kloofy: one more thought what i had, i could had taken to the same muddy level all the stuff, with my nerves beaten them without injurying myself, one mistake what here people tend to do, that they forget the outer world how it destroys the image, because whole lot of people look what the hell are those idiots doing chest ahead fighting with eachother like cocks, for me it was too embarrasing
13:54 kloofy: but for non-existant people they did not care as long as i get injured
13:59 kloofy: for people who lack amounts of feedback and attention in life, in out country which lonely and with sparse density, forms an imagination for those i belive, that noone sees that i am a moran and noone cares, actually outer world still sees all that silliness still
14:01 kloofy: cheers, and for me it is was long time embarrassing for them they have spotted it recently that it become "suprisingly" embarrasing even for them in the end
14:01 kloofy: bye
14:09 karolherbst_work: pmoreau: do you want to create those repositories or should I do it (and write the script)?
14:09 karolherbst_work: I would add both repositories to the envytools github organization for now
14:17 pmoreau: I won't have much time to take care of it: I need to work hard on the SPIR-V stuff, plus look at the G96 screen resume bug.
14:17 pmoreau: So, if you have time to take care of it, great.
14:18 pmoreau: Otherwise, we can postpone it by a couple of weeks.
14:20 imirkin: dcomp: no, your issue is that your card doesn't come up the way nouveau expects. nothing to do with reclocking. reclocking is just a workaround for the issue.
14:32 karolherbst_work: pmoreau: my stuff for xdc is pretty much done, so I have time
14:32 pmoreau: Cool! :-)
14:33 karolherbst_work: (even most of my talk is already on paper :D )
14:33 karolherbst_work: pmoreau: any prefered CI system? I would use travis-ci otherwise
14:34 karolherbst_work: it also has a secret storage to store passwords without putting them in the config
14:34 karolherbst_work: else we could put up something else on your build thingy
14:34 pmoreau: No, no preferred one. I haven’t used any, so…
14:35 karolherbst_work: k
14:35 pmoreau: A tiny bit Harbormaster from Phabricator, but really tiny bit
14:35 karolherbst_work: in the end it would just trigger a build on your build system for the image, allthough we could do that on travis too if it doesn't take too long
14:35 karolherbst_work: how long does it take?
14:36 pmoreau: How long does what take?
14:36 pmoreau: Generating the whole image?
14:37 vileperson: good morning
14:38 karolherbst_work: pmoreau: yes
14:40 pmoreau: Quite some time, apparently the last one took about 9h, sometimes it takes only 4h.
14:41 pmoreau: vileperson: good morning
14:41 pmoreau: karolherbst_work: But I think that it comes from running out of RAM, and needing to swap.
14:41 karolherbst_work: pmoreau: uhhh, that's too long for travis
14:41 karolherbst_work: :D
14:42 karolherbst_work: I see
14:43 pmoreau: I have 4GB, but almost a whole GB is taken by MySQL.
14:44 vileperson: I have an Optimus enabled Laptop, Dell E6530. I am running Arch with Nouveau. I have Optimus enabled in the bios and am trying to use Prime to have use of the 2 display ports and the VGA port on my dock, simultaniously. Even after I turn off the LVDS with xrandr, I still get crtcs errors when trying to turn on the 3rd display.
14:46 imirkin: vileperson: can you pastebin xrandr output so i have a better idea of your setup, and also which nvidia gpu do you have?
14:48 imirkin: note that pre-kepler nvidia gpu's (and post GeForce 2) only have 2 CRTC's. kepler+ have 4.
14:50 imirkin: if you have a mega-new X server, you may need https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=b824d36c28124955eda4aced5e637aa75eea4d6c
15:06 vileperson: imirkin: It'll take me a bit. I'm just getting this Arch system set up (it's been years) and I need to google my way through redirecting output to pastebin. The card is the NVS 5200M.
15:06 imirkin: vileperson: lspci -nn -d 10de:
15:06 imirkin: [i have no clue what a NVS 5200M is]
15:07 imirkin: i'm looking for GFxxx or GKxxx
15:07 vileperson: gotcha... its a GF108GLM
15:07 imirkin: ok, so that only has 2 CRTC's
15:08 imirkin: which means you can only drive 2 outputs at a time off the nvidia gpu
15:08 imirkin: you should, however, be able to drive 1 (or more) outputs off the intel chip, and up to 2 off nvidia at the same time.
15:09 imirkin: vileperson: as for "redirecting" to pastebin, i like the cut & paste method ;)
15:09 vileperson: so I could use reverse prime to switch my VGA port to the Intel card, freeing up a crtc on the Nvidia... maybe
15:09 karolherbst_work: it depends on how the ports are hard wired
15:09 vileperson: lol... true
15:09 imirkin: ports are connected to the gpu they're connected to
15:10 imirkin: no amount of prime or reverse prime will change the wiring
15:10 karolherbst_work: except on macs :p
15:10 imirkin: well, except for hard muxes
15:10 karolherbst_work: right
15:10 DottorLeo: hi!
15:10 imirkin: but i'm guessing there isn't one when "optimus" is enabled
15:10 karolherbst_work: some laptops have a bios based mux for the integrated display
15:10 imirkin: yes
15:10 imirkin: most, in fact
15:11 karolherbst_work: mine hasn't :O
15:11 vileperson: fyi, it lets my clone the other Display port with --auto just throws the crtc error when trying to --right-of and what not
15:11 imirkin: but only to allow completely disabling igpu (or dgpu)
15:11 karolherbst_work: but I also have no ports on the nvidia gpu
15:11 DottorLeo: reclocking is supported on Fermi? My laptop card is a 610M (rebranded 520)
15:11 imirkin: DottorLeo: no.
15:11 karolherbst_work: Doctors: no memory reclocking
15:11 imirkin: vileperson: when you say 'Display port', are you talking about a port on which a display is connected, or DisplayPort ?
15:11 DottorLeo: even experimental? i can give feedback if needed
15:12 imirkin: DottorLeo: no
15:12 karolherbst_work: well, engine reclocking might work
15:12 karolherbst_work: but this is rather pointless
15:12 karolherbst_work: except for a few situations like pixmark_piano benchmark
15:12 vileperson: im sorry... yeah DisplayPort... with Optimus and Prime running, they are DP-1-1 and DP-1-2 in xrandr
15:13 karolherbst_work: DottorLeo: it is considered WIP without any ETAs
15:13 DottorLeo: so what is the best solution for an intel igpu(sandybridge)+dgpu(nvidia 610m)? Optimus? Prime works only with noveau if i understand correctly
15:14 vileperson: they are unavailable to me without Prime, when Optimus is enabled.
15:14 imirkin: vileperson: and does your xorg log have an error along the lines of "Cannot do multiple crtcs without X server dirty tracking 2 interface"?
15:14 karolherbst_work: DottorLeo: use the intel gpu
15:14 karolherbst_work: the 610m is… trash
15:14 imirkin: karolherbst_work: snb ain't exactly perfect either
15:14 karolherbst_work: the intel gpu should be faster
15:14 karolherbst_work: :D
15:14 imirkin: karolherbst_work: and it only does GL 3.3
15:14 karolherbst_work: true
15:14 karolherbst_work: but the 610 has like 140 GFLOPS
15:15 imirkin: DottorLeo: you can, like karol said, get engine reclocking, which could, potentially, increase perf by like ... 2x maybe.
15:15 DottorLeo: karolherbst_work: even with both the appropriate driver ( nvidia closed)? I can ditch the card if you say that the HD graphics on the sandybridge is better :)
15:15 karolherbst_work: 25% in avarage
15:16 karolherbst_work: Doctors: 2000 or 3000?
15:16 DottorLeo: wait a sec
15:16 imirkin: iirc HD 3000 is sandybridge
15:16 karolherbst_work: 2000 is GT1 snb
15:16 vileperson: imirkin: no
15:16 karolherbst_work: like the 2500 is ivb GT1
15:16 karolherbst_work: 3000 is snb GT2
15:17 DottorLeo: 3000
15:17 karolherbst_work: k
15:17 karolherbst_work: the 3000 should have around 130 GFLOPS
15:17 DottorLeo: (i'm writing from windows but i want to ditch it)
15:17 imirkin: vileperson: hrm... let's get back to ... can you pastebin xrandr output, and also xorg log while you're at it
15:17 karolherbst_work: so not really much slower
15:17 vileperson: http://pastebin.com/biPUJpz0
15:18 karolherbst_work: DottorLeo: the performance with nouveau will be worse, even fully reclocked, cause of reasons. You will be better off with the intel gpu
15:18 DottorLeo: ok
15:18 karolherbst_work: DottorLeo: otherwise you could do some benchmarks with bumblebee to verify this
15:18 karolherbst_work: anyway, the pcie overhead will most likely eat any more performance of the nvidia gpu here anyway
15:19 karolherbst_work: it is silly to do a high tier intel gpu + 610m hybrid system to begin with :D
15:19 karolherbst_work: guess the 10$ for a 620m wasn too much
15:20 imirkin: vileperson: and xorg log
15:20 imirkin: DottorLeo: only use the nvidia gpu if you really need GL 4.x
15:21 DottorLeo: imirkin: nah, only newer games need GL 4x and both cards sucks for them :)
15:21 karolherbst_work: :D
15:21 karolherbst_work: I just wanted to say something like that too
15:22 vileperson: http://pastebin.com/UVWTeUqq
15:22 vileperson: imirkin: ^^
15:23 imirkin: there are plenty of reasons to need it beyond running the latest and greatest game...
15:23 imirkin: vileperson: that's like the first few lines
15:23 imirkin: i want the whole file
15:23 imirkin: vileperson: cat the file
15:23 imirkin: and then you can copy it from the console
15:23 imirkin: or you can do something fancier which redirects the contents of a file to the clipboard
15:25 DottorLeo: imirkin, examples? I don't know any Linux program except games that requires such a high GL level. Art program like blender and krita are targeting 3.x.
15:25 DottorLeo: Dolphin require 4.x but like i said this laptop is a bit slow either for emulators
15:25 imirkin: DottorLeo: like let's say you're trying to develop a compute program that will run on a bigger dataset on a bigger gpu
15:26 vileperson: imirkin: gotcha, yeah I used to use some Curl script, I think, but here it is... and yes, It does have the error you mentioned.
15:26 karolherbst_work: then you are smart and start with opencl to begin with, and if that's your business you use nvidia anyway :p
15:26 imirkin: vileperson: ok, then you need the patch i pointed out
15:26 vileperson: imirkin: http://pastebin.com/sCCqFZ3c
15:26 imirkin: vileperson: try to get the arch guys to include it in their pkgbuild thingie
15:27 imirkin: vileperson: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=b824d36c28124955eda4aced5e637aa75eea4d6c
15:27 DottorLeo: Optimus is still developed by nvidia or is it stopped?
15:27 karolherbst_work: optimus is a laptop technology, which is implemented by laptop manufactures
15:27 DottorLeo: too much unreliable on my setup?
15:28 karolherbst_work: huh, what do you mean?
15:28 vileperson: imirkin: how do I implement it?
15:28 imirkin: vileperson: sorry, i don't do distro support
15:29 imirkin: my assumption is that you chose $distro because you know how to operate it. i don't know how to operate it :)
15:29 DottorLeo: well...reading some wikis about intel+nvidia laptop, usually they says that Optimus (that is the closed one solution) is not working perfecly, and they suggest PRIME if you don't care about using nouveau (with its limitation)
15:29 vileperson: imirkin: ah... so it's a direct patch to nouveau. I need to patch it and recompile it?
15:30 imirkin: vileperson: it's a patch to xf86-video-nouveau
15:30 karolherbst_work: DottorLeo: prime is a lot of ideology above user friendlyness bs, so nvidia can't use it the way they want :p
15:30 imirkin: vileperson: there hasn't been a release yet that includes it
15:30 DottorLeo: BTW still on windows i have to FORCE many programs and steam games with the NVIDIA panel to use the dGPU so....even here is not ideal :D
15:30 karolherbst_work: and the way they can, is bs too
15:30 imirkin: vileperson: but if you want to use nouveau with xorg 1.18.x, it's probably a good idea to have it
15:30 vileperson: imirkin: yeah. O.k. Thanks, man. I will see what I can do.
15:31 karolherbst_work: DottorLeo: is the nvidia gpu significantly faster at all?
15:31 DottorLeo: problem is on windows intel is GL 3.1
15:32 Calinou: DottorLeo: no, they offer 4.1 now
15:32 Calinou: at least on recent hardware
15:32 DottorLeo: Calinou: i have a sandy bridge
15:32 imirkin: Calinou: not on snb
15:32 karolherbst_work: :D
15:32 Calinou: yeah, not SNB
15:32 imirkin: they never bothered to implement geometry shaders, i think
15:32 karolherbst_work: DottorLeo: but on windows, dx is a thing, isn't it? :D
15:32 DottorLeo: for example Doomday crashes on SBN but works fine on nvidia
15:33 karolherbst_work: nice
15:33 karolherbst_work: I heard that intel win driver suck by a large margin
15:33 DottorLeo: probably a limitation of intel's driver
15:33 DottorLeo: well...i'll try with the latest Ubuntu l
15:33 DottorLeo: LTS
15:33 karolherbst_work: that will help for sure
15:34 DottorLeo: and see what i can setup
15:35 DottorLeo: thanks for the answers karolherbst_work and imirkin
15:35 DottorLeo: bye!
15:38 karolherbst_work: wut… powershell on linux
15:39 mlankhorst: makes sense, sql server for linux too
15:39 karolherbst_work: if you want burn money that is
15:39 karolherbst_work: :p
15:39 karolherbst_work: but yeah, and windows 12 will have a linux kernel
15:39 mlankhorst: nah
15:39 karolherbst_work: sure
15:40 karolherbst_work: and their NT API will be a layer on top of linux, which they also open source due to the kernel license
15:40 karolherbst_work: and windows 11 will have a linux/NT hybrid kernel
15:40 Calinou: [17:33:05] <karolherbst_work> I heard that intel win driver suck by a large margin
15:40 Calinou: much better performance than on Linux (easily 20% faster) :/
15:41 Calinou: that remains to be solved by Intel team
15:41 karolherbst_work: Calinou: opengl vs opengl?
15:41 Calinou: yeah
15:41 karolherbst_work: mhhh
15:41 karolherbst_work: odd
17:44 kloofy: anyhow it seems that people ignore me and that is how things are suppose to be when someone wants to deal with their own things, but things are getting better i see, that i am not majorly disguising anymore on nouveau that i'd receive bans and such
17:48 kloofy: basically meething was brief, very likely i am starting to work on writing software for different chips, do the similar work as you have done
17:50 kloofy: i was asked if you know how to do such things , my friend being shocked a little about my talks, would not it be that some vendor would be interested to hire you
17:50 kloofy: and i answered with an honesty, that i actually get more bans
17:57 kloofy: bye for now, i will be squeezing the last juices out of myself, hoping to meet persons who are in sync with my thoughts, as i am not really on mailing lists, what those intel programmers talk, yanks it's most of the time hard to get any clue about subjects
17:58 kloofy: not to mention to work in callobration with them, the driver work is a teamwork and it's rough
18:12 jrun: is it possible to run X off nvidia-drivers and kmscon off nouveau?
18:13 imirkin_: jrun: on separate boots, yes :)
18:13 imirkin_: jrun: i believe, but i'm not sure, that the newest nvidia drivers actually make some attempts to play nice with kms, so you may be able to get what you need that way
18:14 imirkin_: skeggsb: what do i have to do, in theory, to get a NV25 graph channel context up and running on NV34?
18:15 jrun: imirkin_: apparently not on legacy cards, no kms.
18:15 imirkin_: jrun: which cards are "legacy" by now?
18:15 imirkin_: like Riva TNT?
18:16 imirkin_: skeggsb: in theory, should i just be able to add it to the sclass list and be good to go? or is it likely that there's more to it?
18:17 jrun: http://www.nvidia.com/object/IO_32667.html
18:18 imirkin_: right. tesla and earlier.
18:18 imirkin_: anyways, yes, 340.x has no kms support
19:26 urjaman: http://i.imgur.com/FtjbXKS.png i decided to see whether 16bpp would be faster, but transparent glxgears wasnt what i expected :D
19:26 imirkin_: i think that's normal
19:26 imirkin_: and is a side-effect from the specific glxfbconfig that's picked
19:27 imirkin_: i guess it ends up with a rgb5_a1 config or something
19:27 ajax: not really
19:27 urjaman: i guess this also has something to do with the no longer white but blue conky
19:28 ajax: ends up with the composite synthetic visual
19:28 ajax: where alpha is significant
19:28 imirkin_: urjaman: pastebin full glxinfo output?
19:28 ajax: so clear to black means clear to transparent
19:28 mupuf: ah ah, that reminds me of some fun with an internal driver we have :p
19:29 imirkin_: ajax: "not really" in reference to it being normal?
19:29 imirkin_: or in reference to the cause i made a guess about?
19:29 ajax: imirkin_: in reference to r5g5b5a1 not being the cause
19:29 imirkin_: ah ok. but it's still not surprising, right?
19:29 ajax: i mean, one would reasonably be surprised by it, but it's what the code implements ;)
19:30 imirkin_: hehe
19:30 urjaman: http://pastebin.com/Pky8reGC
19:30 ajax: i should probably nerf the visual select rating for that config so libGL won't stumble onto it
19:30 imirkin_: but *you* aren't surprised to see it given a 16bpp config selection, and given that the app is glxgears
19:30 ajax: right, it's precisely as dumb as i'd expect
19:31 imirkin_: now... if only some day i could understand wtf a glx visual is, and how it relates to a glxfbconfig
19:31 imirkin_: every time i try to understand it, they appear to be identical
19:31 mupuf: ah, the joy of fbconfig selection ... so random
19:31 imirkin_: and yet they are somehow different
19:31 ajax: they mostly are identical tbf
19:31 ajax: but
19:31 ajax: visuals, strictly speaking, only apply to windows
19:32 imirkin_: do they link to one another, or are they totally parallel concepts?
19:32 karolherbst: mupuf: how do I have to start ezbench to run the gputest benchmarks + record power consumption?
19:32 karolherbst: .. ohh right, we have a channel for that
19:32 mupuf: yep :p
19:33 ajax: they do link to each other. the GLX_X_VISUAL attribute of an fbconfig is set to the ID of the corresponding glx visual (if any, and if GLX_DRAWABLE_TYPE for that fbconfig has the WINDOW_BIT set)
19:33 urjaman: this might be accidental but these transparent glxgears are kinda cool :P
19:33 imirkin_: some day i should also upstream the patch to avoid exposing 16bpp + 24depth or 32bpp + 16depth configs on nv3x/nv4x...
19:34 imirkin_: ajax: ok, so multiple fbconfigs can link to a single visual?
19:34 ajax: the idea being you can have fbconfigs for depth 16 or 30 pixmaps and pbuffers even when you have a depth 24 screen
19:34 ajax: imirkin_: or to no visual at all
19:34 imirkin_: i see.
19:34 ajax: this was all faintly misguided, back in the day when fbo's weren't a concept
19:35 ajax: and people still thought drawables were always window system objects
19:35 imirkin_: right
19:35 ajax: so misguided that EGLConfigs are seen as a mistake at this point
19:36 ajax: but yeah, if you wanted to render to a YUV pbuffer, you needed an fbconfig to express that, because there's no way to say that for an X visual (which every GLX visual must correspond to)
19:36 imirkin_: and X visual == X window? or also pixmap?
19:36 imirkin_: or is it its own concept?
19:37 ajax: pixmaps in X don't have colors
19:37 ajax: or channels
19:37 ajax: they're just piles of bits
19:37 ajax: visuals are what define how those bits are interpreted (either as cmap indices or rgb channels), and only windows have them
19:37 ajax: X's rendering model: also somewhat misguided
19:37 imirkin_: :)
19:38 imirkin_: ok, so i can only render to a window, not to a pixmap directly? (with X drawing ops)
19:38 ajax: no, X drawing ops will draw to either
19:39 ajax: but
19:39 imirkin_: don't you have to have format info to go with the pixmap?
19:39 ajax: imagine you have two visuals with opposite-ordered color channels (xrgb vs xbgr)
19:39 imirkin_: [i realize a pixmap can back a window]
19:39 ajax: you would draw to the pixmap "as if" you knew where the bits would end up when blitted forward to a window
19:39 ajax: but if you blitted the same pixmap to two different windows with opposite channel orders
19:40 ajax: you'd see r/b swapped
19:40 imirkin_: right, but how does the drawing op know any of this?
19:40 imirkin_: or is it all sufficiently generic that the drawing ops don't even need to know the underlying format since the color/whatever they're given is all they end up using
19:41 imirkin_: someone needs to make a docs.x11 to go with docs.gl :)
19:41 ajax: you set the fg/bg color to correspond to the channel config of the visual you will eventually use.
19:41 ajax: don't think about it too much tbh
19:41 imirkin_: right ok
19:42 imirkin_: hehehe
19:42 glennk: this gets weird with xrender doesn't it?
19:43 ajax: glennk: render draws to Pictures, which are a combination of a drawable (window or pixmap) plus a format to define how to interpret the bits
19:43 ajax: but still
19:43 ajax: a Picture has colors. a Pixmap just has bits.
19:46 glennk: which reminds me to inquire what the support for 30 bit rgb framebuffers is these days?
19:46 ajax: supported in Xorg for a very very long time now
19:46 imirkin_: on nouveau, or in general?
19:46 mupuf: glennk: ah! That's how people get 10 bpc!
19:46 mupuf: 2 bits for alpha :p
19:46 mupuf: not that it is useful anyway
19:47 ajax: whether individual drivers support it is another matter
19:47 imirkin_: glennk: i think on nouveau it's mostly untested
19:47 glennk: yeah, not a whole lot of use for destination alpha on your main composited framebuffer
19:47 imirkin_: i'd be happy to investigate any issues you run into should you obtain the relevant hw
19:48 ajax: actually that's an interesting question
19:48 ajax: is there hardware that can dither down a depth-30 framebuffer to a depth-24 scanout pipe
19:48 ajax: or do you really need depth-30 support in the sink to make it go
19:49 ajax: 30 bit monitors being, erm, pricey
19:49 glennk: actually 30 bit aren't that pricy any more
19:49 glennk: or at least 8 bit + 2 bit frc
19:49 ajax: huh, right you are
19:49 ajax: found an hp dreamcolor for like 600$
19:50 glennk: one has gotten so used to displays sitting still for ten years on resolution and bit depth its a surprise when things got moving again
19:50 ajax: the LP2480zx was north of two grand when it first came out
19:53 glennk: 30 bit, swap tear, freesync, somewhat unexplored territory on xorg
19:54 ajax: we definitely got 30 bit working with i915 at one point, at least as far as kms was concerned
19:55 ajax: and you could in fact tell the difference, with an undithered black-to-white horizontal gradient
19:55 glennk: i've seen patches floating around for 30 bit on radeon
19:56 ajax: where in 24 bit that's like 7.5 pixel wide stripes on 1920x1200
19:57 mupuf: at least, the good thing is that it does not use more memory bandwidth ... sort of (compression, blabla)
20:02 glennk: i think fwiw nv and radeon can dither 10 bit down to whatever the output bpc is
20:02 karolherbst: can somebody run a gputest pixmark_piano benchmark on a fully reclocked kepler gpu vs nvidia?
20:02 karolherbst: I have something odd I need to investigate, but can't do it on my machine
20:16 karolherbst: Tom^: do you mind doing a simple benchmark on your system? Will take 10 minutes top
20:16 tobijk: the benchmark is certainly not the problem, still the nvidia driver is :/
20:17 karolherbst: why's that?
20:17 tobijk: it never works on my system :/
20:18 tobijk: and to be fair, i'm not investing much time in solving that problem :)
20:21 vileperson: I forget who it was that provided me with the patch for the ctcs errors I was getting with multiple displays and xrandr, but... Thank you very much. It's working great.
20:21 karolherbst: mhh odd
20:21 karolherbst: seems like nvidia does something odd when there is no output
20:22 karolherbst: or not
20:31 urjaman: but yeah the good (well, expected...) news is that 16bpp is faster :)
22:10 tobijk: orbea: if you are there: is it possible to start openMW without morrowind additions?
22:11 tobijk: nad if yes, can you test if the problem with the cursor still persists...
22:16 karolherbst: am I stupid? I want to write a bash function like this:
22:17 karolherbst: function git { ... git -C nouveau $@ }
22:17 karolherbst: the thing is, what has to be the ... ?
22:17 karolherbst: exec won't fly and I don't want to hardcode the thing
22:17 karolherbst: and sh -c is kind of ugly
22:17 orbea: tobijk: it has no assets/game data, let me try to see if I can reproduce the crash without them
22:18 imirkin_: karolherbst: /usr/bin/git instead of ...
22:18 imirkin_: or, `which git` if you feel like being all generic
22:18 karolherbst: ...
22:18 karolherbst: mhh
22:18 karolherbst: hardcoded path: bad
22:18 karolherbst: which, also kind of bad
22:19 imirkin_: how is which bad?
22:19 imirkin_: it finds the binary in your path
22:19 karolherbst: because it is a hardcoded path
22:19 karolherbst: ahh which
22:19 karolherbst: mhh yeah
22:19 karolherbst: well
22:19 imirkin_: which is precisely what bash would do
22:19 karolherbst: which can deliver multiple results
22:19 imirkin_: really?
22:19 karolherbst: afaik yes
22:19 imirkin_: i did not know...
22:19 imirkin_: only if you pass -a, according to the man page
22:19 orbea: tobijk: nope, needs the game data to crash, otherwise it closes with "ERROR: Archive 'Morrowind.bsa' not found"
22:19 imirkin_: solution: don't pass -a
22:19 karolherbst: or was it whereis?
22:20 imirkin_: oh yeah, whereis is like locate
22:20 imirkin_: you don't want that
22:20 karolherbst: yep
22:20 karolherbst: then which should be fine
22:20 mupuf: yep, which is an acceptable solution
22:20 tobijk: orbea: mhpf damn morrowind
22:21 mupuf: locate and whereis == bad idea
22:21 imirkin_: i suspect also doing exec "git" would have worked
22:21 imirkin_: but i don't know for sure
22:21 karolherbst: $(which git) -C nouveau $@ >/dev/null :D
22:21 karolherbst: imirkin_: nope
22:21 karolherbst: exec won't work
22:21 karolherbst: it creates a new process
22:21 karolherbst: and if git returns without 0
22:21 karolherbst: the shell is gone
22:22 karolherbst: which git usually does
22:22 imirkin_: why not
22:22 imirkin_: exec does the opposite of creating a new process
22:22 imirkin_: it calls execve :)
22:22 karolherbst: try it and you will see
22:22 karolherbst: it garbage, because it stops executing the shell script
22:22 imirkin_: yes
22:22 imirkin_: that's precisely what exec does
22:22 karolherbst: right, but maybe I want to do multiple exec gits
22:22 imirkin_: exec calls execve
22:22 imirkin_: so you can't have "multiple" ones
22:23 karolherbst: but I wanna
22:23 imirkin_: then you can't use exec
22:23 karolherbst: exactly
22:23 imirkin_: coz you want it to fork, not exec
22:23 tobijk: orbea: yay, i have just found my brothers morrowind :)
22:23 orbea: cool :)
22:23 orbea: their openmw-wizard should install the data pretty easily
22:24 imirkin_: tobijk: an awful amount of effort going into helping a project that explicitly wants nothing to do with nouveau...
22:26 tobijk: imirkin_: mh you may be right, but on the other side openmw is using sdl to change the mouse cursor, so it may occur in other programs
22:26 imirkin_: your time - do what you want with it
22:27 tobijk: yeah i'm stuck with iscadd anyway :)
22:30 orbea: could this at all be related in a similar project, but for Arx Fatalis (ArxLibertatis)? http://pastebin.com/0ZmdWSgz No crash here, just the video freezes with DRI3. Eduke32 does it too. Its certainly at least related to sdl2 + dri3 (not sdl1) with arx.
22:30 karolherbst: the heck
22:31 karolherbst: if you use -C with git, you have to adjust the path you give to git am
22:31 karolherbst: ....
22:32 tobijk: orbea: looks like another problem
22:33 tobijk: orbea: you really need to install morrowind with wine to use openmw? thats a nogo for me
22:34 orbea: i didn't have to
22:34 orbea: you just need to point their wizard at the game data
22:35 orbea: i guess wine would just prepare the data
22:35 orbea: i think my data came from gog, I forget, but was just plug and play
22:36 tobijk: ah ok oversaw the wizardy thing
22:48 karolherbst: pmoreau: wanna test something? :p
22:54 karolherbst: pmoreau: https://github.com/karolherbst/nouveau_staging
22:58 tobijk: orbea: the cursor is fine here...do you have a recent graphic stack?
22:58 orbea: mesa-2016.08.17_5de29ae_master-x86_64-1_git
22:58 tobijk: more xserver, libdrm and so on
22:59 orbea: ah
22:59 orbea: xorg-server-1.18.4-x86_64-1 and libdrm-fc09c5a_2016.04.27_master-x86_64-1_gi
22:59 orbea: should I be updating those?
22:59 tobijk: i'
23:00 tobijk: m not familiar with those versions :/
23:00 tobijk: guess we'd have to match git commits
23:01 orbea: i'll try compiling new versions to see if I get a diff
23:22 orbea: tobijk: on libdrm-2016.08.02_b214b05_master-x86_64-1_git and mesa-2016.08.12_07ccec0_master-x86_64-1_git now, no difference, cursor is still ".."
23:23 tobijk: well check dri3 and prensent :)
23:23 tobijk: dont know what it is
23:24 orbea: prensent?
23:25 tobijk: called present-prot here and libxcb-present
23:25 tobijk: *proto
23:25 orbea: oh
23:28 orbea: i have libXpresent-1.0.0, presentproto-1.0 and dri3proto-1.0
23:29 orbea: i can try upgraded various x bits,but will have to be later. I can't restart x without waiting for other things to finish now