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