00:32 imirkin: austriancoder: which one?
01:29 anarsoul: karolherbst: if I understand correctly all you have to do is to use consistent buffer format for MOD_INVALID
06:28 austriancoder: imirkin: that one https://pbs.twimg.com/profile_images/1175149674497531906/luM3v8gi_400x400.jpg
06:30 austriancoder: aha.. https://www.phoronix.com/scan.php?page=news_item&px=MTg0MjA - I might want one for etnaviv too :)
12:00 karolherbst: anarsoul: ahh... yeah, we don't
12:00 karolherbst: anarsoul: so whenever we allocate INVALID we either have to make it always linear or tiled or whatever?
12:33 karolherbst: austriancoder: then create one :p
15:52 anarsoul: karolherbst: depends on flags. For shared buffers it should be the same format that you use for importing BO with MOD_INVALID. For private you can do whatever you want
15:54 karolherbst: okay
15:54 karolherbst: I think we don't do that yet, so let me try it and see how that goes
20:25 qeeg_: hey, i have an issue in my riva 128 emulation where the correct values for ramin are written there first, but then soon after overwritten with all 0s, TWICE in a row
20:26 qeeg_: and i have no idea why this is happening
20:26 qeeg_: this happens with multiple oses drivers
21:34 qeeg_: yeah, it writes the correct values to ramht, and then IMMEDIATELY clears it???
21:43 Lyude: qeeg_: what's the name of your project btw?
21:44 qeeg_: 86box, why?
21:44 qeeg_: it's not MY project, i just contribute to it :p
21:46 Lyude: ah
21:47 Lyude: no
21:47 qeeg_: ?
21:47 qeeg_: what's wrong? o.o
21:49 Lyude: heads up to anyone else moderating this channel - if you see them again please remove them, they're not allowed in here
21:54 RichardG867: hey all, is C61 known to work ok on recent versions of nouveau? last I tried was some old debian version, kernel 4.9.0 I believe, where X would bring down the entire system right after starting
21:54 RichardG867: C61 geforce 7025 to be exact
21:55 Lyude:looks
21:57 Lyude: ahhhh, here we go - Geforce 7025/7050, nForce 630a - NV68 MCP68
21:57 RichardG867: oh that, sorry.
21:57 Lyude: hehe, it's np
21:57 RichardG867: I would always use the proprietary driver on these systems, but with modern distros no longer supporting 304.xx, nouveau is the only solution
21:57 Lyude: RichardG867: -technically- it should at least be supported in the kernel but no idea about mesa ( imirkin / karolherbst ?)
21:57 RichardG867: don't really need mesa/3D
21:59 Lyude: RichardG867: alright-my advice then would be to file an issue on the kernel.org bugzilla with some X.org/dmesg logs
22:00 Lyude: It is quite an old card though, so I don't know if anyone's going to have the time to take a look - but it's probably worth filing anyway
22:00 RichardG867: I'll look into it, thanks... I did find some MSI related issues on the tracker, but I have no way of logging my issue really because that issue brings the system down quickly
22:01 RichardG867: maybe netconsole
22:01 Lyude: RichardG867: was about to suggest that - netconsole usually does the trick with that sort of thing
22:01 Lyude: kdump might as well if you blacklist nouveau, but mileage may vary
22:02 karolherbst: Lyude: we do 3d on all nearly GPUs
22:02 Lyude: karolherbst: ah, figured that might be it but wasn't sure
22:02 karolherbst: nv68 should be nv30
22:02 karolherbst: which is.. GL1.4?
22:02 karolherbst: something like that
22:43 karolherbst: imirkin: we can't render depth buffers into a linear buffer, can we?
22:43 karolherbst: uhm...
22:43 karolherbst: render into linear depth buffers I guess
22:55 RSpliet: NVS68 should be able to do GL 2.1
22:55 RSpliet: Pardon
22:55 RSpliet: MCP68S