04:54 joi: imirkin: https://github.com/envytools/envytools/commit/9a0e74241ff834674030e49ac6ae40d36797a2ee & http://people.freedesktop.org/~mslusarz/demmt/not_mapped.png, enjoy ;)
08:23 imirkin: joi: nice!!
08:36 imirkin: joi: one potential issue is that it probably doesn't check previously-written values
08:36 imirkin: but that may be harder to keep track of
09:10 imirkin: joi: also, there can be 16 diff constbufs bound... or actually 16 * pipelines
09:34 qqz: can anyone tell me whether a „NVIDIA GF 8600M GS“ card would be supported properly by nouveau i.e. providing DRI support?
09:36 qqz: I have an ATI Radeon Mobility HD 2700 and it is not even supported (no DRI support) until these days.
09:37 RSpliet: qqz: should work
09:37 qqz: good to know
09:37 RSpliet: but unlikely to be clocked at full performance in nouveau
09:37 tobijk: qqz: that really surprises me, ever bothered to ask about the HD2700?
09:38 RSpliet: but you should get 2D+3D acceleration, OpenGL 3.3 I think
09:39 qqz: I believe it has some special driver needs and was at first not even well-supported by the proprietary driver
09:39 qqz: no grpahics acceleration at all for this card; no 3D gaming
09:40 qqz: I have asked a lot some years ago; but I believe they have forgotten about this model; nonetheless may ask in the radeon channel.
09:41 xexaxo: hmm that sounds very strange (the HD2700 case). iirc it should just work with recent enough graphics stack.
09:43 qqz: … and if I wanna buy a 4K notebook, what about the NVIDIA® GeForce® GTX 850M card?
09:43 imirkin: qqz: HD 2700 should work just fine, as should the GeForce 8600. both should provide OpenGL 3.3
09:43 imirkin: GTX 850M is unlikely to work out of the box right now
09:43 xexaxo: actually you do have a point there - some of the HD series did not have 100% support from day one with the radeon binary drivers.
09:44 qqz: the book has an intel graphics card as well which should be well supported; nonetheless it would be good to know whether the card will be supported in the future
09:45 imirkin: the 850M is a GM107 (in all likelihood) which in turn requires some not-yet-upstream patches to make context switching work
09:45 imirkin: even when it does work, it is unlikely to provide a performance boost over the intel gpu (if you're using nouveau) as there is no reclocking support for maxwell at present
09:47 imirkin: [and some tbd bug which causes visual glitches in xonotic sometimes...]
09:50 tobijk: mh 860m is nve4, maybe 850m is one as well :/
09:50 imirkin: tobijk: sadly there's little correlation between marketing names and the gpu's they represent
09:50 imirkin: i went by pci.ids info, but who knows
09:50 tobijk: hehe
09:50 imirkin: there tends to be a lot of overlap, esp in mobile models
09:52 qqz: good to know; however with an additional intel card I am always save :).
09:59 qqz: HD 2700 should work with the newest mesa, they told me; however it does not work with the three-year-old one from Debian stable.
10:00 imirkin: yes... they...
10:00 qqz: would you still recommend me to replace that card by a NVIDIA GeForce 8600M (which has twice as much RAM and a lower power consumption) if I have the opportunity to do so?
10:01 imirkin: pretty sure mesa 8 had r600 support though, but perhaps that particular one had some special issues. or you have some sort of issue with your setup
10:01 imirkin: well, it's not like nouveau had particularly great support in kernel 3.2.0 or mesa 8 either :)
10:02 imirkin: things have come a long way in the past 3 years
10:02 qqz: gonna use Deb. testing with mesa 10.3.2-1 anyway in the future
10:29 RSpliet: oh btw
10:29 RSpliet: I had this in my dmesg today
10:29 RSpliet: http://hastebin.com/gatupefire.css
10:30 imirkin: RSpliet: downgrade libdrm to 2.4.59
10:30 imirkin: mlankhor1t killed it :(
10:30 RSpliet: oh dear
10:31 RSpliet: sounds like a job for yum downgrade... thanks
10:59 mlankhorst: imirkin: seems to me bo's should be kicked on unref to 0
11:00 imirkin: i'm not sure what that means...
11:01 mlankhorst: imirkin: if a pushbuf references a bo and refcount drops to zero, then the pushbuf should be flushed out..
11:01 imirkin: i'd rather an assertion be raised
11:01 mlankhorst: or that..
11:01 imirkin: that should never happen afaik
11:01 mlankhorst: but it does ;-)
11:02 imirkin: then we should fix it
11:02 imirkin: i suspect your change is entirely correct and reveals a pre-existing bug
11:02 imirkin: however the old code limped along, whereas with your changes, it mega-dies
11:02 imirkin: (and in a weird way, too -- how does that conflict happen...)
11:03 mlankhorst: imirkin: because I create a new bo when refcount drops to zero. :P
11:03 mlankhorst: the old bo has refcount zero, so it should die..
12:11 joi: imirkin: can you elaborate on what do you mean by "previously-written values" and "bound constbufs"?
12:48 joi: imirkin: or rather, why do you think it matters? addresses are checked at the moment they are used in the command stream
12:53 joi: if demmt would validate all address methods when they are needed by other ("render") methods, then yes - previous values would matter
13:59 imirkin: joi: well i can write a buffer address and push it out, and it gets validated
13:59 imirkin: all is well
14:00 imirkin: but if i then do another draw and don't touch that value at all, it still holds the old value
14:00 imirkin: but i might have accidentally freed the buffer by then
14:01 joi: right
14:02 joi: but that's different bug detector ;)
14:03 joi: to detect this kind of bug someone would have to first map which addresses are used by which methods
14:30 joi: for various upload/copy/query methods it's obvious (and driver code using those should be bug free), but I
14:30 joi: 'm not sure which method eg uses *_3D.CB_ADDRESS_*