00:25karolherbst: imirkin: oopsie https://patchwork.freedesktop.org/patch/135797/
00:25karolherbst: ahhh skeggsb_ wanted to debug this bug...
00:26imirkin: yeah, i mean i have zero additional information
00:26imirkin: iirc, the situation was that the user was helped by NvForcePost?
00:26imirkin: i haven't looked at the bug :)
00:26karolherbst: might be
00:26imirkin: it was some time ago, so my memory is hazy
00:26karolherbst: it was bisected anyway
00:26imirkin: thankfully there's a bz reference
00:26karolherbst: there are soooo many patches we didn't apply
00:27karolherbst: I am sure I wrote this one for a reason as well: https://patchwork.freedesktop.org/patch/151794/
00:27imirkin: well, your last message makes it sound like the bug was elsewhere
00:27karolherbst: I guess
00:28karolherbst: maybe it even landed
00:28imirkin: hard to tell.
00:28karolherbst: well, not anymore
00:29karolherbst: imirkin: https://patchwork.freedesktop.org/patch/151948/
00:29karolherbst: I assume this might be the fix...
00:29karolherbst: given the same day and stuff
00:29imirkin: the dates appear to line up
00:30karolherbst: even mentions the same error
00:30imirkin: i think you can declare that mystery 'solved'
00:30imirkin: obv my patch has the potential to screw a lot of stuff up
00:30karolherbst: Rejected the last patch now
00:31imirkin: we added that 2240c-based thing for a reason
00:31imirkin: iirc it was gnurou who dropped it in
00:31karolherbst: anyway.. I see 7 kernel patches from you which aren't resolved :D that was one of them
00:31imirkin: ok. lmk if you have questions about any of them
00:31karolherbst: ahh.. make that 6
00:31karolherbst: one is for the ddx
00:31karolherbst: the mmx/sse stuff
00:33karolherbst: and two are superseded
00:33karolherbst: seems like the overlay stuff also landed...
00:33karolherbst: damn scripts
00:34karolherbst: ehh different hash and different title...
00:36karolherbst: imirkin: seems like there is really just that one patch left
00:38imirkin: ok. the kvmalloc one landed too somewhere?
00:38imirkin: anyways, i have nothing really to say about that patch. i don't have hw which needs it.
00:38imirkin: any information is in that bz.
00:39karolherbst: pushed it... yesterday or so?
00:39imirkin: ok cool
00:39imirkin: i'm not keeping track, as it's probably apparent
00:39imirkin: been hacking on A420 - trying to get compute / images / ssbo up and running. with some success, it seems.
00:39karolherbst: yeah... I spent some time to get patchwork into shape, so the tracking now _almost_ works automatically
00:40karolherbst: roughly 600 patches left to review
00:40imirkin: big fan of anholt's deqp-runner program btw
00:40karolherbst: or well.. "patches"
00:40karolherbst: it's great
00:40karolherbst: would be even greater if nouveau wouldn't crash running it :D
00:40imirkin: it crashes? :(
00:41karolherbst: well.. parallel execution is kind of ... well.. it can trip over the kernel
00:41imirkin: (i haven't tried it with nouveau, just freedreno atm)
00:41imirkin: ah right
00:41karolherbst: so I can only use it with a single job..
00:41imirkin: that was sorta implied ;)
00:41karolherbst: and I have this script
00:41karolherbst: runnning _all_ tests based on gles/gl version or whatever
00:41karolherbst: takes like half a day
00:43karolherbst: you know what's great? people resending their massive patch series over and over again: "37 patches updated" :D
00:45karolherbst: what the..
00:45karolherbst: copy paste fail
00:45karolherbst: "void *map = map;"
00:46karolherbst: how lucky we are that people clean up after us
01:04karolherbst: I think I should start doing this in smaller batches again....
01:04karolherbst: now I collected 26 patches from the ML
23:30Walt: Is anyone logged on?
23:31karolherbst: Walt: a few persons as it seems. What's the issue or why are you asking?
23:32Walt: I have a question regarding the nouveau driver set
23:32karolherbst: yeah, just go ahead
23:32Walt: What apis do the nouveau drivers support?
23:32Walt: and how does the driver connect to those apis
23:33karolherbst: atm mainly OpenGL. There is also some support for VDPAU, VAAPI and OpenCL, but that's for more adventurous kind of people
23:33karolherbst: well it's all inside mesa
23:34Walt: I heard d3d9 is supported?
23:34karolherbst: ah yeah, that as well
23:34karolherbst: but not directly
23:34Walt: how then?
23:34karolherbst: the d3d9 implementation is still inside wine
23:34karolherbst: mesa just advertises some APIs wine can make use of
23:36Walt: Are there any apis that wine can make use of? A later version of d3d?
23:38karolherbst: currently there is more motivation to use vulkan to implement all versions of d3d on top of
23:38karolherbst: with great success
23:39Walt: But vulkan isnt supported at all yet
23:39karolherbst: not for nouveau
23:41karolherbst: well.. there is some work done towards this, but nothing submitted/public yet
23:41Walt: If there was motivation to do so how would someone start implementing a new api such as nouveau
23:42imirkin: step 1: adjust the kernel driver to enable userspace to allocate different page types at fixed addresses
23:43karolherbst: where step 1 is probably already too much for any newcomer
23:43karolherbst: UAPIs are an annoying topic
23:43karolherbst: kind of need the full thing before you can add new UAPI
23:43imirkin: even just implementing it is pretty intense, forgetting about picking a good uapi.
23:44karolherbst: you need an implementation before you can even get people to discuss your new uapi is probably the most annoying part here
23:45karolherbst: anyway... I think I will discuss with skeggsb_ how we want to progress here anyway :D
23:45karolherbst: doesn't really make sense to have new people wrking on it if there is something almost working already. but never published, because...
23:45karolherbst: distributions are annoying
23:47karolherbst: imirkin: talking about distributions being annoying I will probably rewrite my mt fixes again :D
23:47karolherbst: but this time will be the last time (tm)
23:47imirkin: next time someone else will do it ;)
23:47Walt: Couldnt you guys send basic patches to distrubution devs?
23:48karolherbst: Walt: the issue is that distributions just pick up random shit
23:48imirkin: karolherbst: i sorta see it as the inverse problem :p
23:48imirkin: distributions just pick up random shit :p
23:48imirkin: Walt: we are the owners of the code. we have no trouble making updates to it.
23:49Walt: I see that
23:49imirkin: although i did shut down my attempt at fixing mt things because distros started picking up my buggy patches.
23:49karolherbst: imirkin: yeah well... the next idea is to have really just one pushbuf think, but inside some submission queue and contexts just have a bo they write commands into... we do have the APIs for doing it like that and this will fix the one issue I have in my current version
23:49karolherbst: but ufff...
23:49imirkin: which was just going to cause me more headaches
23:49karolherbst: it won't
23:49imirkin: and they wouldn't remove them, so ... i stopped doing it.
23:49karolherbst: that you meant
23:50karolherbst: although my patches are working.. mostly
23:50karolherbst: I do submit more often though
23:50karolherbst: and that breaks nv50...
23:50imirkin: yeah, i mean my stuff mostly worked too
23:50imirkin: except when it completely deadlocked the process
23:50karolherbst: nono, I mean it really works
23:50imirkin: other than that it was perfect ;)
23:50karolherbst: I had 0 deadlocks :)
23:50imirkin: yeah, i'm sure your attempt is _much_ further along than mine by now
23:50karolherbst: something something with fences isn't working alright and I have no idea what it is
23:50imirkin: anyways, sounds like you're going to implement my original suggestion then?
23:50Walt: Why dont you guys use a basic distrubution install a de and develop for that then submit your patch then tell the distrubution maintainers to fix the bugs and shit
23:50karolherbst: imirkin: nope :p
23:50imirkin: if you're back to the single pushbuf
23:51imirkin: Walt: i don't understand what problem you're trying to solve?
23:51imirkin: are you trying to help us get code to distros?
23:51imirkin: are you trying to help us learn how to develop?
23:51karolherbst: imirkin: sooo.. assume we have a bo cache. Then each context just gets a plain bo. no pushbuf
23:51karolherbst: writes command to it
23:51karolherbst: "submits" it
23:51karolherbst: and then we collect those bos in a queue
23:51Walt: The distros adding stuff is the headache
23:52karolherbst: when we have to flush, we use nouveau_pushbuf_data to put them all into a pushbuf
23:52karolherbst: and submit it to the kernel
23:52Walt: so its their issue not yours when it breaks everything on their distro
23:52karolherbst: still need some locking in regards to state tracking and shit, but this will be saner than my current approach
23:52imirkin: karolherbst: a pushbuf is just a plain bo.
23:52imirkin: Walt: no, it's our issue. people come here with nouveau issues, not the distro.
23:52karolherbst: yeah well.. but currently I submit to sync between contexts
23:53karolherbst: and instead of that, I just enqueue batches of work
23:53karolherbst: and maybe have a pushbuf worker thread submit those or whatever
23:53karolherbst: or just do that from within a context
23:53karolherbst: not quite sure on how that will look like
23:53karolherbst: but it was skeggsb_ idea to use nouveau_pushbuf_data
23:53karolherbst: wanted to try it out at least
23:53imirkin: his ideas are generally pretty well-reasoned
23:54karolherbst: so using nouveau_pushbuf_data is mainly to fix this "my bo is full, I have to submit" problem
23:54karolherbst: but that doesn't really help if you have multiple contexts still
23:54karolherbst: because.. hw state
23:54karolherbst: so I want to have a state lock, context fills in command, submits the new state, unlocks and then another thread can pick up the lock and do the same or whatever
23:55karolherbst: and at some point we just flush it out
23:56karolherbst: I am still not quite sure how that works out in regards to bos and whatever other random stuff we have...
23:56imirkin: so it's almost like you have a single pushbuf :)
23:56karolherbst: and if I still need a pushbuf per context, but just have it all queued up in the correct order or whatever...
23:56karolherbst: yeah... maybe
23:56imirkin: anyways, wtvr
23:57karolherbst: just that the interfaces around pushbuffers are.... anoying as hell
23:57imirkin: i'm not picky
23:58karolherbst: maybe I just do the full lock approach first and try to speed it up later... no clue
23:58imirkin: so ... what you _really_ want to avoid
23:59imirkin: and i _will_ be picky about
23:59imirkin: is spinning under a lock
23:59imirkin: right now fence_wait (or similar) spins
23:59imirkin: definitely can't be doing that with a lock
23:59karolherbst: we have simple_mtx_t
23:59Walt: How does Mesa interface with d3d9?
23:59karolherbst: which is this basically free when nobody took the look yet impl