00:00 karolherbst: Walt: not at all
00:00 imirkin: Walt: there's an d3d9 api impl which uses internal gallium APIs to accelerate
00:00 Walt: Why does Mesa advertise it then?
00:01 imirkin: karolherbst: mesa definitely does expose some of d3d9
00:01 karolherbst: because wine implements d3d9 and makes use of mesa APIs ;)
00:01 karolherbst: ehhh
00:01 karolherbst: there are APIs
00:01 karolherbst: but
00:02 karolherbst: I still wouldn't say that mesa interfaces with d3d9
00:02 karolherbst: that's all inside wine
00:02 Walt: Oh, then how would you interface with gallium/mesa apis?
00:03 imirkin: Walt: these are general mesa questions, perhaps better directed at #dri-devel
00:03 karolherbst: Walt: soo.. for d3d9 we actually created a custom mesa API, which wine uses
00:03 imirkin: Walt: or #d3d9
00:03 karolherbst: we do fully implement most of the other APIs, d3d9 is just special here
00:03 karolherbst: and ehh.. some other stuff
00:03 karolherbst: I think for android we also have custom APIs?
00:04 imirkin: and xvmc only works with libXvMCW
00:04 Walt: Wait, then why dont you guys use gallium+mesa apis to interface with it?
00:04 imirkin: coz so many people care about xvmc these days :)
00:04 karolherbst: Walt: gallium API is private
00:04 karolherbst: well
00:04 karolherbst: we as in nouveau make use of it
00:04 karolherbst: but that's all mesa internal
00:04 imirkin: Walt: again, unclear what your goal is... what problem are you trying (to help) solve?
00:05 Walt: Nothing, im just curious
00:05 imirkin: ok. i don't understand the question then.
00:05 imirkin: mesa implements a libd3d9adapter.so
00:05 imirkin: there's a wine-nine-standalone which makes enough glue between that .so and "dll" land
00:06 karolherbst: well.. and I think wine included some changes to use that instead of their own stuff
00:06 karolherbst: so you can replace it
00:07 imirkin: there was a time when you had to patch wine.
00:07 imirkin: that was a long time ago
00:07 imirkin: wine-nine-standalone is, afaik, the preferred mechanism these days
00:07 imirkin: it acts as a dll override, i think?
00:07 karolherbst: yeah
00:07 Walt: imirkin: my question is why isnt there an effort to use Mesa apis to vulkan
00:07 imirkin: Walt: vulkan and gallium aren't a great match
00:07 imirkin: the point of vk is to be very direct to the hardware
00:07 Walt: imirkin: noted
00:08 imirkin: mesa does house a number of vulkan drivers
00:08 karolherbst: and we don't want to maintain APIs
00:08 imirkin: they share compilers/etc with their gallium backend counterparts
00:08 karolherbst: because if you want to have special mesa APIs to imeplent random APIs instead of using vulkan, we would have to maintain it
00:08 karolherbst: and if we have to make changes, everybody shouts at us
00:08 imirkin: Walt: most importantly, the way that vulkan wants to handle resources doesn't work too well with gallium.
00:08 karolherbst: maintaining APIs is not fun
00:09 imirkin: this is also why step 1 is what i mentioned. the resource allocation stuff is fundamentally different.
03:01 karolherbst: can we ban email addresse from the ML?
03:01 karolherbst: I have a candidate
03:02 imirkin: i've been approving thos eemails
03:02 imirkin: seem pointless
03:02 karolherbst: quite so
03:02 imirkin: but i also didn't feel like acting as a censor
03:02 imirkin: and it wasn't outright spam
03:02 karolherbst: I was mainly annoyed by the colors
03:02 karolherbst: which you might have not seen.. dunno
03:02 imirkin: i can start rejecting that guy
03:03 imirkin: i didn't when approving.
03:03 karolherbst: yeah.. dunno
03:04 karolherbst: from some people I start feeling this "this sounds liek some rogue AI doing _something_" vibe, but.... maybe some people are also just like this?
03:04 karolherbst: I have no idea
03:04 imirkin: hard to tell.
03:04 imirkin: which is why i hit the approve button :)
03:05 karolherbst: seriously though: https://i.imgur.com/Wx6GKxf.png
03:06 karolherbst: I mean.. if you send out emails like this, you don't expect answers, do you?
03:06 imirkin: dunno, it's never come up for me
03:06 imirkin: where i've sent emails like that
03:06 imirkin: ;)
03:06 karolherbst: I just checked what emails I have in my mailbox from that account :D
03:06 imirkin: so can't tell you whether i'd expect a reply
03:06 karolherbst: :D
03:08 karolherbst: I actually replied once and the response I got wasn't necessarily a nice one
03:09 karolherbst: maybe I wasn't as nice to begin with either though
03:09 imirkin: http://jni.sdf-eu.org/trolls.html :)
03:10 karolherbst: I guess
16:50 imirkin: karolherbst: you're not going to solve that DMA_PUSHER thing. but how on earth are you running out of vram running gtk4-demo? dunno.
16:50 imirkin: even before it's run?
16:50 karolherbst: it did run
16:51 karolherbst: but the GPU isn't.. well.. the best one
16:51 karolherbst: I suspect there is some memory management related bug
16:51 imirkin: dude wtvr. it's totally fine. if you can't run on a G92 you're in serious trouble.
16:52 karolherbst: the DAM pusher thing is this bug where we push to fast or something?
16:53 karolherbst: although...
16:53 imirkin: if i knew precisely, i'd have already fixed it
16:53 imirkin: my theory
16:53 imirkin: is that we don't do fifo context switching correctly
16:53 karolherbst: ahh
16:53 imirkin: and so we switch some fifo thing incorrectly
16:54 imirkin: and then the DMA_PUSHER makes it even worse :)
16:54 imirkin: so all the methods are desync'd etc
16:54 karolherbst: I really should finish this detect broken channel work...
16:54 karolherbst: but the channel doesn't die...
16:54 karolherbst: argh..
16:54 RSpliet: all channels are broken with nouveau, right?
16:55 karolherbst: no idea, the screen is frozen
16:55 imirkin: RSpliet: esp this one :)
16:55 karolherbst: let me kill the process
16:55 karolherbst: ahh nice...
16:55 karolherbst: hung task
16:55 karolherbst: ahh no
16:55 karolherbst: nouveau starts to kill the channel
16:55 karolherbst: okay...
16:55 karolherbst: back to normal
16:56 karolherbst: imirkin: I don't think the firmware is to blame here.. sounds like a normal mesa mess up actually
16:56 karolherbst: or _something_
16:57 imirkin: not firmware
16:57 imirkin: kernel.
16:57 imirkin: we don't do the right dance
16:57 karolherbst: ahh
16:58 karolherbst: nice
16:58 karolherbst: random screen corruptions
16:59 karolherbst: the method is NV50_3D_RT_TILE_MODE though
16:59 karolherbst: data... 002073c0
16:59 karolherbst: mhh
17:00 karolherbst: looks bonkers
17:00 karolherbst: let me dump the pushbufs and see if we are safe there or if it's all garbage
17:00 karolherbst: worst case it's just multithreading again or other random shit
17:00 imirkin: like i said ... it gets desync'd
17:01 imirkin: "this is not the error you are looking for"
17:02 karolherbst: yeah.. and maybe not. I can just check if the pushbuf is alright or not. If it isn't alright, then.. cool.. another mesa bug to fix, if it is then.. yeah well.. screw the kernel or something
17:02 karolherbst: multithreading can lead to such corrupted buffers though
17:04 karolherbst: especially given that there are indeed new threads spawned.. let's see
17:35 karolherbst: imirkin: so uhm.. there are 5 active OpenGL contexts...
17:36 imirkin: the more the merrier!
17:36 glennk: five GL contexts walk into a bar
22:39 karolherbst: nv50 is wild
22:39 karolherbst: I think mesa is quite terribly broken :D
22:40 karolherbst: now I get random https://gist.githubusercontent.com/karolherbst/6dd685050c87ffd74d32a53157357416/raw/533a24d985769f191422a3135dd9a09c25230746/gistfile1.txt
22:40 imirkin: yeah, that shit happens
22:44 karolherbst: sad...
22:49 imirkin: welcome to nv50
22:49 karolherbst: yeah.. I kind of start to love nvc0
23:03 karolherbst: imirkin: okay soo uhmm.. my threading fixes are actually fixing the gtk4-demo thing, but.. it seems like there are a few remaining issues in terms of graphical glitches in that series :D
23:04 karolherbst: but I also only fixed that state tracking stuff for nvc0
23:04 karolherbst: so kind of expected
23:07 imirkin: yeah, nv50 is variously flaky
23:07 imirkin: i think it has more to do with larger GPUs
23:07 imirkin: i barely ever hit it
23:07 imirkin: but i dunno
23:07 imirkin: actually i don't think i hit it on my G92 either and that was large-ish
23:07 imirkin: some people just know how to tickle those texture errors
23:07 imirkin: they're generally non-fatal though
23:08 karolherbst: well.. the glitches I am talking about are just regressions from my threading fixes now.. but at least it kind of means we might see those issues more and more often if more applications are starting to use gtk4
23:08 karolherbst: but the texture thing?
23:08 karolherbst: yeah......
23:09 karolherbst: maybe I run deqp and hope it hits something...
23:10 imirkin: i never was able to _repro_ it
23:10 imirkin: i've had it happen
23:10 imirkin: but it's not like a well-defined thing iirc
23:10 karolherbst: well
23:10 karolherbst: I just saw it happen because I forgot to shutdown my deskop
23:11 karolherbst: 3177.652448 seconds after boot
23:11 karolherbst: not toooo long
23:38 imirkin: the latest entries in my dmesg have the timestamp "8556579.782866" :)
23:49 karolherbst: mhh my laptop: "1268950.500881" .. guess your desktop runs a little longer :D