02:10 imirkin: gnarface: no, h264 on G92's never worked
02:11 gnarface: no? oh, i thought it did
02:21 imirkin: not accelerated, at least with nouveau
02:21 imirkin: i could never track down what i did wrong with engine init
02:22 imirkin: the xtensa chip is running fine, but the underlying decoding engine isn't =/
04:16 HdkR: imirkin: What is using an xtensa chip?
04:16 imirkin: pre-falcon
04:16 imirkin: they used xtensa
04:16 imirkin: to drive the VP2-era decoding engines
04:20 HdkR: interesting
04:21 imirkin: same general idea as the falcon chips, just ... xtensa.
04:21 imirkin: i guess they didn't want to pay the licensing fees, or ... who knows
04:22 HdkR: TFW Im working on an xtensa llvm backend that is unrelated
04:22 imirkin: mwk decoded a good chunk of the vp2 firmware
04:23 imirkin: iirc i did a bit of it too
10:27 Lyude: btw mupuf, alyssa is outside the auditorium if you would like to meet then
10:27 Lyude: *them
10:27 mupuf: Sure!
10:27 mupuf: coming in 5
13:58 karolherbst: imirkin: so I gave fixing our multi context issues a shot and came up with basically moving the channel into the context and just have one channel per context, but the patch size got kind of out of hand and there are still some issues about the screen having to know something about future contexts we might create
13:58 karolherbst: anyway, here is the patch: https://github.com/karolherbst/mesa/commit/0d44298e6624430576a086ccc622763aa44b8a8d
13:58 karolherbst: I am sure I broke nv50 and video acceleration
13:59 karolherbst: but I kind of prefer to have smaller patches, but I don't see a reasonable way to split it up without having intermediate states being more broken
14:01 karolherbst: at least I got passed the crashes inside dolphin and it still renders, so I think this approach would work in general
14:02 karolherbst: and I think we could even remove all the screen->cur_ctx stuff, because it doesn't make sense to track the current context if each contexts has its own channel anyway
14:02 karolherbst: and the saving state stuff
14:02 karolherbst: "nvc0_graph_state" and so on
14:12 imirkin: karolherbst: that's not workable... can't have multiple hw contexts
14:12 karolherbst: imirkin: why not?
14:13 imirkin: switching is slllloooooooowwwwwwwwwww
14:13 karolherbst: I know
14:13 karolherbst: but... well
14:13 Sarayan: so no memory protections between gl-using applications and the gl-compositing windows manager?
14:13 imirkin: Sarayan: if they're running in the same process, then no.
14:13 karolherbst: multiple gl applications use multiple contexts anyway
14:14 karolherbst: I doubt it is a big issue though
14:14 karolherbst: as you have couple of applications with multiple contexts
14:14 karolherbst: and most applications only have one
14:14 karolherbst: there is just a handful of applications really doing it
14:14 imirkin: karolherbst: applications use multiple threads for speed
14:14 Sarayan: ok, it's multiple contexts sharing textures/framebuffers/targets?
14:14 karolherbst: and for example dolphin only uses 1 effecitvly
14:14 imirkin: (multiple contexts, etc)
14:14 karolherbst: imirkin: depends on how
14:14 karolherbst: dolphin only compiles shader in multiple threads etc...
14:15 karolherbst: and I doubt that you can actually use multiple contexts for speed
14:15 karolherbst: how should that even work?
14:15 karolherbst: you still have just one GPU
14:15 karolherbst: you can reduce API overhead, but you have 0 automatic state sharing through APIs
14:15 karolherbst: so you end up copying from one context to the other anyway
14:15 imirkin: the solution is to stop using libdrm_nouveau
14:16 imirkin: the way that kick is implemented is what makes all this unworkable
14:16 karolherbst: why do we even want to share the pushbuffer?
14:16 imirkin: basically any action might trigger a kick
14:16 imirkin: we don't, it's just a side effect
14:16 imirkin: but with a single hw context, you effectively only have 1
14:17 imirkin: you could make multiple ones, but they still have to account for what was submitted previously
14:17 imirkin: and in effect you're back to having one
14:17 karolherbst: well, we would have to resubmit all state basically everytime then
14:17 karolherbst: I don't see how to get around that problem
14:17 karolherbst: each context has its own state
14:17 imirkin: which is still way faster than an hw context switch
14:17 imirkin: we do this now anyways
14:17 karolherbst: uhm, no
14:18 karolherbst: we don't
14:18 imirkin: we do.
14:18 karolherbst: no, we just overwrite the old state
14:18 karolherbst: there is some "state saving"
14:18 imirkin: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c#n873
14:18 karolherbst: but it doesn't really work
14:18 Sarayan: isn't MT GL mostly a way to reduce the single-core driver overhead actually?
14:19 karolherbst: applications wanting to actually draw on multiple contexts will be slow one way or the other
14:19 imirkin: basically you want to serialize everything. but given the libdrm_nouveau architecture with kicks coming in at random times, it's impossible to get the locking right
14:19 karolherbst: it makes 0 sense to use that to get more performance
14:19 imirkin: i know coz i tried.
14:19 Sarayan: to allow building what's essentially commands list while waiting for the previous draw to finish?
14:19 imirkin: i ended up with situations that were unsolvable without api changes.
14:19 karolherbst: imirkin: yeah, I saw that issue and thought it wouldn't really be manageable
14:19 imirkin: so the solution is ... stop using libdrm_nouveau
14:20 imirkin: and make an architecture where it *is* possible to get the locking right
14:20 karolherbst: I don't see how that will help as you basically have the same issues
14:20 imirkin: part of the problem is that we end up doing cpu-based sleeps
14:20 imirkin: which is why i wanted the syncfd/whatever logic to become available
14:20 karolherbst: okay sure
14:20 Sarayan: imirkin: events?
14:21 imirkin: Sarayan: waiting for the gpu to complete stuff.
14:21 karolherbst: but in the end, if we share one channel, we basically have to resubmit all state on each flush and whenever we actually detect that we switch the API context
14:21 imirkin: karolherbst: not on each flush, any time that a different thread "takes over"
14:21 karolherbst: or add bunch of code to actually detect where the states diverge
14:21 imirkin: which is what we do now anyways.
14:21 imirkin: the problem isn't the multiple threads -- that all works fine
14:21 imirkin: the problem is the concurrent access.
14:22 karolherbst: sure
14:22 karolherbst: but
14:22 karolherbst: most of my patch isnt really about just using one channel, that's just an easy solution to use
14:22 karolherbst: but the focus on moving alls tate from screen to the context
14:23 imirkin: yeah
14:23 imirkin: but that state is attached to the hw context
14:23 imirkin: of which there should be 1
14:23 imirkin: hence screen makes sense.
14:24 imirkin: (so your patch is mostly about using separate hw contexts)
14:28 karolherbst: well, it might also be a good idea to have buffers for each contexts so that we don't have to synchronize on those as well
14:28 karolherbst: which is actually what dolphin also triggered
14:29 karolherbst: anyway, we track state on screen level
14:29 karolherbst: but we have to do it fully on a context level
14:29 karolherbst: I see now way how to get around that
14:33 karolherbst: imirkin: but, big questions, how do you know a context "took over" the GPU? (It isn't about threads here really)
14:34 karolherbst: sure, we could set screen->cur_ctx on literally every function which may submit something to the GPU and resubmit everything whenever we have that (+ waiting on everything being done on the GPU)
14:35 karolherbst: but... how can this be even faster if you end up stalling and waiting on other contexts being done with their work
14:35 Sarayan: urgh, sounds nasty
14:35 karolherbst: or maybe it is always slow
14:35 karolherbst: and we just can make it less slow but using one hw context
14:35 karolherbst: *by
14:48 karolherbst: imirkin: but... why do you think context switching is _that_ slow? I am sure it is quite fast on at least the newer GPUs
14:48 karolherbst: maybe it was slow on tesla or something
14:49 karolherbst: RSpliet: I think you have some data on that, don't you?
19:21 gst568923: Hi guys
19:22 gst568923: Does anyone know the implementation status of open source firmware in order to use Nvidia PureVideo technology with the VP5 engine?
20:17 gst568923: For extract the Nvidia Firmware for PureVideo VP5, I have to use mmiotrace with Proprietary Driver and run Vdpau?
20:19 gnarface: the firmware cutter tool won't just let you extract it from their installer?
20:19 gnarface: if not, yea probably something with mmiotrace...
20:21 gst568923: hi gnarface, I am looking on the internet, if there is someone who has managed to extract it
20:22 gst568923: I read this https://nouveau.freedesktop.org/wiki/NVC0_Firmware/
20:23 gst568923: It's a bit difficult
20:24 gnarface: if you have a working install somewhere you can just copy the files from the firmware directory too
20:25 gnarface: i forget where it puts them but i thought it was something like /usr/lib/nvidia/firmware/
20:25 gnarface: as just loose files in a directory
20:25 gnarface: but maybe they've changed that
20:30 gst568923: Can I extract Nvidia blob firmware from the VirtualBox machine? because in the current linux distro I installed nouveau and I would like to avoid uninstalling it and then install the proprietary drivers
20:34 gnarface: i don't know for sure but i assume so
20:34 gnarface: i'm having trouble finding the exact path for you
20:35 gnarface: hmmm, maybe it's been moved to the initrd.img
20:37 gst568923: gnarface Are you a maintainer of the nouveau project?
20:54 gnarface: gst568923: sorry, no.
20:55 gnarface: just trying to help you find that firmware and now i can't find mine here anymore either
20:55 gnarface: but it has to be somewhere...
20:57 gst568923: I ask you, because you are the only one who is giving me support, all the others and the mantainers where they are? I'm posting at a wrong time (here in Italy it's 11pm)?
21:03 gst568923: gnarface in xorg.log I have found this string:
21:03 gst568923: [ 15.103] (--) NOUVEAU(0): Chipset: "NVIDIA NVD9"
21:03 gnarface: gst568923: i'm not sure where they are but i assume somewhere in europe
21:04 gnarface: gst568923: the nvidia official installer just dumps all the same giant ball of firmware files for all the supported chips
21:04 gst568923: that it is a confirm that my video card is:?
21:04 gst568923: NVD9 (GF119) GeForce 410M, 510 (?), GT (520, 520M, 520MX, 610), 610MQuadro NVS 4200M
21:04 gnarface: uh, i would assume so
21:06 gst568923: because https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units#GeForce_7_(7xxx)_series
21:06 gst568923: The GeForce GT 705 (OEM) is a rebranded GeForce GT 610, which itself is a rebranded GeForce GT 520.
21:06 gst568923: so I can confirm NVD9 (GF119)
21:07 gnarface: yea, i think that's a safe assumption
21:07 gnarface: but now that you bring it up, it could mean that you need firmware from the *legacy* nvidia drivers
21:07 gnarface: since it's not clear to me if that card counts as a 600 or 500 for support
21:07 gst568923: why legacy?
21:08 gnarface: the 500 series was recently deprecated by nvidia for their main driver
21:08 gnarface: 600's are barely hanging on
21:08 gnarface: so even if you find the *current* firmware from them, it could already be missing support for that card
21:09 gnarface: but i don't know how likely that is one way or another
21:09 gnarface: it could be like a 1% risk or a 50% risk
21:09 gnarface: someone else would know
21:09 gnarface: someone who has hacked on this firmware before
21:09 gnarface: but i suspect they're all still asleep or at work right now
21:11 gst568923: There are 2 sets of firmware for video decoding, one for kernel and one for userspace. Only nvc0 series need the userspace firmware. Kepler, and also nvd9 do NOT have userspace firmware
21:13 gst568923: https://www.phoronix.com/scan.php?page=news_item&px=OTQ4NA
21:14 gnarface: hmmmm
21:14 gnarface: interesting
21:14 gnarface: i think that would mean the firmware IS in initrd.img if indeed it's kernelspace only
21:15 gnarface: at least on a typical distro package setup
21:15 gnarface: ymmv there i suppose
21:15 gnarface: it won't be identical for every distro, i don't think
21:20 gst568923: gnarface I found this https://ubuntu.pkgs.org/18.04/ubuntu-multiverse-amd64/nouveau-firmware_20091212-0ubuntu1_all.deb.html
21:20 gst568923: but there is not NVD9
21:39 gnarface: gst568923: yea, i see. honestly i would just try dropping them all in that directory at once anyway to see if any get picked up at boot up/
21:39 gnarface: it's grasping at straws though, i know
21:42 gst568923: gnarface I have download this https://github.com/imirkin/re-vp2
21:43 gst568923: and I have download NVIDIA-Linux-x86_64-340.32.run
21:43 gst568923: then I have run: sh *.run --extract-only
21:43 gst568923: then I have run python2 ./extract_firmware.py
21:44 gst568923: this is the output:
21:45 gst568923: Uploaded file: https://uploads.kiwiirc.com/files/9921b3e06b112f95bd37f98df8d0590e/microcode.png
22:03 gst568923: good night