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