00:10 edgecase:bows
00:11 edgecase: looking at GEM docs, might be a good place to put mem accounting
00:15 imirkin: yeah, it's just a tricky topic
00:16 edgecase: hang a struct off each DRM master inode, for all the things
00:16 imirkin: yeah, so ... single inode in a DRI2 environment, among other things
00:17 imirkin: also you might allocate 100tb in textures, but only bind 1kb for a particular shader
00:17 imirkin: and then submit
00:17 edgecase: well haven't read that part yet
00:17 imirkin: and then aother 1kb and then submit
00:17 imirkin: etc
00:17 imirkin: but the submits don't execute synchronously
00:19 edgecase: what determines if dri2 or 3 is used?
00:20 imirkin: client, ddx
00:28 imirkin: unix sockets are used to pass fd around
00:33 edgecase: is there a test suite or demos that show very basic use?
00:39 imirkin: not really ... not for this sort of thing
00:39 imirkin: you can look at
00:39 imirkin: https://github.com/imirkin/re-vp2/blob/master/bsp_test.c
00:39 imirkin: for a very basic application
00:39 edgecase: i will look for a drm hello-world also
00:40 imirkin: which submits commands and whatnot
00:40 imirkin: i used this to prototype the h264 video accel decoding
00:40 imirkin: seemingly some years ago...
00:43 edgecase: nouveau_bo_new() looks interesting
03:46 gry: Map on this page comes out as stripes in Firefox (safe mode, new profile, esr or 73.0.1) https://transportnsw.info/trip#/ . In Chrome it works OK. This is debian buster, graphics card info http://paste.debian.net/plain/1133845 ; 'glxgears' works OK. I already installed updates.
03:56 imirkin: unfortunate the nv30 driver (which covers your board) is fairly shitty
03:56 imirkin: my guess is that firefox has started making use of acceleration
04:05 gry: what other programs use hardware acceleration? I would like to see this issue outside of firefox to confirm
04:06 imirkin: glxgears uses accel
04:06 gry: glxgears shows the gears just fine
04:06 imirkin: but basically the impl isn't 100% conformant
04:07 imirkin: so depending on the features used, you can run into trouble
04:07 imirkin: games developed around that time knew what the constraints were
04:07 imirkin: and used the things the hardware supported
04:07 imirkin: this isn't true of some random webgl application though
04:08 imirkin: looking at that webpage, it does look like it uses webgl
04:08 imirkin: at least it has a canvas called "mapboxgl-canvas"
04:08 imirkin: chrome blacklists all of nouveau for any sort of accel ... a potentially questionable decision, but one that seems to have panned out in your case
04:09 gry: suppose i would like to buy a new laptop
04:09 gry: because this one is 10 years old, and its graphics driver is not very good
04:09 imirkin: you could use blob drivers -- those handle all the cases hw doesn't
04:09 gry: is there a list of good laptops to buy which are debian friendly and nouveau friendly?
04:09 gry: blob drivers meaning properietary nvidia?
04:09 imirkin: well, i'd recommend you stay away from nviida
04:09 imirkin: yes
04:10 gry: something debian friendly whose graphics card works ok
04:10 imirkin: if you just need light graphics, i'd stick to the built-in graphics in modern CPUs/APUs
04:10 imirkin: they're more than sufficient for regular use
04:11 imirkin: modern nvidia boards aren't that great with nouveau
04:11 imirkin: since nvidia has locked down any sort of clock changes
04:11 imirkin: which means that you get like 5-10% of the total possible perf
04:12 HdkR: There we some new Lenovo laptops announced with AMD APUs
04:12 HdkR: s/we/were
04:13 HdkR: Even has Thunderbolt I think?
04:14 HdkR: https://www.notebookcheck.net/Lenovo-ThinkPad-T14-T14s-T15-with-AMD-Ryzen-Pro-4000-and-Intel-Comet-Lake-announced.454393.0.html
04:14 HdkR: Thunderbolt, only limitation is that the AMD variant doesn't have a 4k display
04:14 gry: hmm
04:14 imirkin: too bad they don't make laptops with normal screens anymore
04:14 imirkin: just movie displays now =/
04:15 HdkR: imirkin: What is a normal screen compared to a movie display?
04:16 HdkR: IPS versus TN?
04:16 imirkin: no, 4:3 vs 16:9
04:16 imirkin: back when a 15" screen was big
04:17 imirkin: 16:9 is great for watching movie content
04:17 gry: it is for surfing the web, programming, watching photos
04:17 gry: i dont really need movies on this laptop
04:17 HdkR: ah
04:17 imirkin: well, 16:9 is all you can purchase now
04:17 HdkR: imirkin: My laptop has 3:2 though :P
04:17 gry: graphics card wouldn't matter, but i would just prefer maps to work
04:17 imirkin: they don't make other panels.
04:18 imirkin: HdkR: oh? which one?
04:18 HdkR: Actually, both my laptops have 3:2
04:18 HdkR: Surface Book 2 and Surface Pro X
04:18 HdkR: I think the Surface Laptop and/or Surface Pro also has 3:2?
04:18 imirkin: nice
04:19 imirkin: i guess MSFT has the pull required to get a custom panel made for them
04:19 imirkin: i bet that 15" goes a lot further than a 16:9 15" as well
04:19 imirkin: HdkR: does it run linux well?
04:20 HdkR: For the most part, Book2 has Marvell wifi so it is a bit derpy at times
04:20 HdkR: and the detaching base sometimes loses connection so the laptop version is the better choice
04:21 HdkR: and I have the Nvidia dGPU disabled in bios :P
04:21 imirkin: looks like a shittier keyboard... is that just the screenshot?
04:22 imirkin: like the annoying crap keyboards they've been dumping into ... non-thinkpads
04:22 HdkR: https://www.microsoft.com/en-us/surface/devices/surface-laptop-3/tech-specs yea, 3:2 like I thought
04:22 HdkR: Keyboard is roughly the same between the different variants
04:22 HdkR: Trackpad is one of the best Windows trackpads I've ever used
04:22 HdkR: non-mac trackpad I guess
04:22 imirkin: oh right, trackpad... yeah, sad
04:23 imirkin: not-for-me
04:23 HdkR: Oh yea, I use mouse constantly, but when I'm on a plane I'd rather it not frustrate me
04:23 imirkin: gonna have to stick with thinkpads for now
04:23 imirkin: keyboard + mouse that i like
04:24 HdkR: ah right
04:24 imirkin: uh oh
04:24 imirkin: looking at recent ones, looks like they killed the keyboards too?
04:24 HdkR: I think the only thing that frustrated me with the Surface keyboards is that they don't have an FN lock
04:24 HdkR: Razer keyboard frustrated the hell out of me because the arrows ate the right shift, and the keycap stablization suuuuucked
04:25 imirkin:likes travel
04:25 imirkin: and not the kind in an airplane...
04:27 HdkR: As long as I can get some work done while traveling then I'm happy
04:27 imirkin: i'm talking about the travel of keys on a keyboard :p
04:27 imirkin: i.e. how far down they go
04:28 HdkR: oh
04:29 HdkR: Difficult to get so I''ve adjusted instead
04:31 HdkR: Lenovo has changed travel distance on some of their laptops as well
04:38 imirkin: yeah, looks like they have :(
04:38 imirkin: i'm sure they sit around in a room
04:38 HdkR: Microsoft at least doesn't go as far as Apple with their switches
04:38 imirkin: discussing ways of making laptops that appeal less to me
04:39 imirkin: much like nvidia has a team that sits around in a room discussing ways to reorder tex instruction argument order :)
04:39 HdkR: I've talked to the architecture team, good people :D
04:56 gry: imirkin: so the webgl app behaves differently in firefox and chrome? in the latter it uses only the features which are supported by this driver? or chrome does not use the graphics card at all?
04:56 imirkin: chrome doesn't use 3d accel at all
04:56 gry: ok
04:56 gry: how do I test all the different features? is there an app for that?
04:56 imirkin: there's webgl cts
04:57 imirkin: if you want to crash the comp
04:59 gry: you mean this one? https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html
05:00 imirkin: yes
06:10 lovesegfault: Is there a nice place to ask questions about i915?
06:10 lovesegfault: nice = as helpful and non-aggro as #nouveau
06:10 lovesegfault: I keep getting these:
06:10 lovesegfault: [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=110 end=111) time 292 us, min 2146, max 2159, scanline start 2134, end 2173
06:20 HdkR: lovesegfault: #dri-devel
06:21 lovesegfault: HdkR: thank you :)
06:21 HdkR: Granted it is the weekend, so Intel people are probably off work and sleeping at this point
06:33 lovesegfault: Has anyone here done SW consulting work recently
06:33 lovesegfault: I was contacted yesterday about it and they asked for my rate
06:33 lovesegfault: And... I don't have one?
06:44 HdkR: "Too much for you to handle binch."
06:47 HdkR: That was a bit aggressive, but be skeptical for random cold contacts :)
06:49 lovesegfault: HdkR: Yeah, I am, I said $150 to see what they say
06:49 lovesegfault: should've said more
12:36 AndrewR: ..I think I run into another mesa compilation problem: https://pastebin.com/rvHbaejL Does this mean I need newer python? (currently python 3.6 passes meson configure)
12:55 AndrewR: mesa build was working at least up to commit a19c9290f44e6e73a104067a98420c273d98721b - I looked into cgit and apparently this glthread rework touched those python files ...
12:58 AndrewR: and at least in this version I run into "mplayer: ../src/gallium/state_trackers/vdpau/surface.c:92: vlVdpVideoSurfaceCreate: Assertion `pipe_format_to_chroma_format(p_surf->templat.buffer_format) == ChromaToPipe(chroma_type)' failed." (while trying to play Cinelerra-produced mov file via vdpau, 720x576 Packed YUY2)
13:25 AndrewR: no, even with python 3.7.2 build still fail (on 32-bit)
15:29 karolherbst: ehh our cas implementation is wrong :/
15:40 gsedej_: hi. geforce 840m (optimus) gives enormous ammount of errors in output: nouveau 0000:07:00.0: fifo: SCHED_ERROR 20 []
15:41 gsedej_: log file is 1GB just after few seconds (fast drive)
15:58 karolherbst: gsedej_: that essentially means the gpu context got messed up and indicates a userspace bug in most cases
16:02 gsedej_: is it possible for nouveau to detect and supress the output or give up using it
16:02 gsedej_: ?
16:06 karolherbst: it probably could, but it wouldn't solve the problem as this is something your system logger is supposed to take care of. Journald has a max log size e.g. I can write a patch for that SCHED_ERROR thing but there are other places where nouveau (and other drivers) can spam the log
16:38 gsedej_: karolherbst, i just tried "nouveau.runpm=0" but doen't help
16:39 karolherbst: because it's a userspace bug
16:40 gsedej_: tried again, and this time works
16:40 gsedej_: maybe it was typi
16:40 gsedej_: typo
16:49 diogenes_: Hello guys, is Nvidia 1660 Ti supported?
16:50 HdkR: Supported enough that the kernel will bring up the display if you're running something new enough
16:51 diogenes_: HdkR, which kernek version would be recommended?
16:54 HdkR: https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-TU117-TU116-Firmware Firmwares are super new
16:54 HdkR: Theoretically 5.3 or 5.4 has the code side support
16:54 diogenes_: ok thanks.
16:58 HdkR: Sadly still no 3D acceleration
16:59 gsedej_: karolherbst, before SCHED_ERROR, there is nouveau 0000:07:00.0: bus: MMIO read of 00000000 FAULT at 6013d4 [ IBUS ]
16:59 gsedej_: does this help?
19:25 imirkin: gsedej_: that's a harmless error ... you're probably on a GF117 or something?
19:25 imirkin: or other display-less GPU
19:29 imirkin: AndrewR: which commit are you suspecting? should be easy enough to bisect, but i don't see anything obvious
19:31 gsedej_: imirkin, i am testing ubuntu 20.04 with my old optimus laptop with geforce 840m - GM104
19:32 gsedej_: system logs get quickly filled with SCHED_ERRPR 20
19:32 imirkin: gsedej_: GM104 is not a GPU code that exists
19:33 imirkin: there's GK104, GF104, GM204, but no GM104
19:33 gsedej_: its GM108. sorry
19:33 imirkin: ah ok. so that makes sense - it's a display-less GPU like GF117 is
19:33 imirkin: that's a complaing that we're trying to access some vga-related register
19:33 imirkin: unfortunately it's tricky to avoid, and the only harm is a single such message on boot
19:34 gsedej_: https://pastebin.com/N8CghtPR
19:35 gsedej_: there are more errors
19:35 gsedej_: fifo: fault 01 [WRITE] at 0000000000150000 engine 05 [BAR2] client 08 [HUB/HOST_CPU_NB] reason 02 [PTE] on channel -1 [007fd38000 unknown]
19:35 gsedej_: fifo: fault 01 [WRITE] at 0000000000000000 engine 05 [BAR2] client 08 [HUB/HOST_CPU_NB] reason 0a [UNSUPPORTED_APERTURE] on channel -1 [007fd38000 unknown]
19:36 imirkin: those are much scarier
19:36 gsedej_: found this bugreport https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/175
19:37 imirkin: unsupported aperture? wtf is that =/
19:37 gsedej_: does GM108 have hidden camera (aperture) :D
19:39 imirkin: hehe
19:39 imirkin: yeah, but only f/2.8 apparently
19:48 gsedej_: should I report bug?
20:25 AndrewR: imirkin, https://cgit.freedesktop.org/mesa/mesa/commit/?id=d93f4faefb0a867ea33b9530e9aa67ae1ed60e93 ? (or may be others in same series .... )
20:26 imirkin: AndrewR: i could be wrong, but that seems entirely unrelated
20:27 imirkin: gsedej_: so yeah, those FIFO faults are basically ... not good
20:27 imirkin: unfortunately since the bugzilla shutdown, there's no great place to report nouveau issues
20:27 imirkin: you could just do it on bugzilla.kernel.org
20:28 imirkin: or just send an email to nouveau@lists.freedesktop.org
20:28 imirkin: in the meantime i might recommend you boot with nouveau.noaccel=1
20:29 AndrewR: imirkin, may be generated C file is not very good from old (5.5.0) gcc point of view ....
20:29 imirkin: AndrewR: those scripts are to generate GL dispatch
20:29 imirkin: your bug is in vdpau
20:30 imirkin: and/or vl
20:30 imirkin: i'd be surprised if it worked fine at the commit you emntioned
20:30 imirkin: more likely you built without asserts
20:30 AndrewR: imirkin, yes, I just found uncompileable for me master, because I wanted to see if bug was fixed there or not
20:30 imirkin: this feels like fallout from anholt's series to screw around with formats
20:31 imirkin: ahhhh
20:31 imirkin: ok, yeah, that makes more sense then
20:31 imirkin: you should report the bug
20:32 AndrewR: imirkin, https://pastebin.com/qm0jg0dC - more complete stdout ...
20:32 AndrewR: yeah, I said same thing on #dri-devel, but may be none who can help was awake there at that moment
20:32 AndrewR: should try clang , too
20:34 gsedej_: imirkin, about bugzilla - what is difference with bugs.freedosktop and gitlab.freedesktop?
20:40 imirkin: bz sends emails to nouveau@, gitlab does not
20:40 imirkin: AndrewR: it tends to be quiet on weekends -- it's a mostly professional crowd
20:41 AndrewR: imirkin, yeah, i usually rebuild on weekends because less activity in master ...
20:42 imirkin: AndrewR: ok, so let me look at your underlying issue ... i bet it's some dumb thing in the format conversions a while back
20:43 imirkin: karolherbst: what's wrong with our CAS impl?
20:44 karolherbst: oh, it was just broken for 64 bit types
20:44 karolherbst: I thought there are more issues, but apparently that was everything which was missing
20:45 karolherbst: and... I need atomics for 64 bit on local memory... but that seems to require annoying lowering
20:45 karolherbst: uhm... shared memory
20:46 AndrewR: imirkin, http://samples.mplayerhq.hu/V-codecs/2Vuy2.mov (14 mb!) can be used for reproducting issue ...
20:46 karolherbst: imirkin: https://github.com/karolherbst/mesa/commit/70de73b90b64ccc1b7d157bc53882dccbc2c701d
20:47 imirkin: AndrewR: looks like some code that got added in Feb by pepp
20:47 karolherbst: I might want to guard this code for 8 and 16 bit though...
20:47 imirkin: need to figure out what he was trying to achieve
20:47 karolherbst: not that we should hit that though
20:47 imirkin: karolherbst: hah yeah, that's pretty 32-bit focused
20:48 karolherbst: CL only allows those on 32 and 64 bit types anyway
20:49 karolherbst: anyway, with my patch it works for global memory at least
20:49 karolherbst: shared... needs some strange lowering
20:50 imirkin: cool. there's very likely to be a lot of 32-bit-isms all over that stuff
20:50 imirkin: yeah, there's no ATOMS.CAS
20:50 karolherbst: there is for 32 bit
20:50 karolherbst: ohh wait
20:50 karolherbst: no
20:50 karolherbst: that's lowered as well
20:50 imirkin: the lowering we already do just might not account for 64-bit
20:50 karolherbst: but I mean all ATOMS for 64 bit needs lowering
20:50 imirkin: ahh ok
20:51 karolherbst: nvidia loweres it into global memory
20:51 karolherbst: or... so
20:51 karolherbst: it's a bit weird, didn't understand the code yet
20:51 imirkin: might go through the shared memory window?
20:51 karolherbst: nope
20:51 imirkin: dunno if that sort of cheating works
20:51 karolherbst: they still do LDS
20:51 imirkin: usually it just throws an exception for such an op
20:53 karolherbst: https://gist.github.com/karolherbst/6d757d886ce2b76e1f56f27a647f79f1
20:53 karolherbst: it seems to be lowered in the CL -> PTX path already
20:54 karolherbst: but it's still weird
20:54 karolherbst: especially as there is still an atom.shared.add.u64
20:55 karolherbst: or maybe I just missed something here and there is no lowering required
20:55 karolherbst: but I got traps from the shader
20:56 karolherbst: illegal instruction encoding and stuff
20:56 imirkin: we just might not support it
20:56 imirkin: the encoding of anything not used by GL is iffy
20:56 imirkin: esp on SM50+
20:57 karolherbst: ehh.. I got confused by the PTX code :D
20:58 karolherbst: but still, there is a ATOMS.CAS.64
20:58 karolherbst: yeah.. I should take a closer look
20:59 imirkin: AndrewR: no need for your fancy video... vdpauinfo dies too :)
20:59 karolherbst: imirkin: but I also saw those "return value is wrong" issue in some of the tests and there was a comment referencing those
20:59 imirkin: yeah, i saw that comment, but i have no recollection about it
20:59 imirkin: either i didn't add it, or my memory is starting to become worse
21:00 imirkin: there are indications towards both of these of late...
21:00 AndrewR: imirkin, vdpauinfo still works for me, but it was not latest version (nor libvdpau is latest on my system)
21:03 imirkin: ok, so i think part of the problem is that i have a newer vdpauinfo which probes some of the later formats
21:03 imirkin: in release mode it just returns PIPE_FORMAT_NONE
21:04 gsedej_: imirkin, karolherbst i created new issue on gitlab about my GM108/840m SCHED_ERROR https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/522
21:04 gsedej_: can i provide more info?
21:04 imirkin: gsedej_: ok, that's a pretty good way to ensure no one will ever see it.
21:04 imirkin: like i said, gitlab isn't something we look at
21:05 edgecase: hey what's an example program that uses overlay planes?
21:05 imirkin: edgecase: modetest
21:05 edgecase: sure, but it's boring ;<
21:05 imirkin: kmscube _might_, not sure
21:05 edgecase: mpv teases us
21:05 imirkin: the real target is something like drm_hwc or something
21:05 edgecase: something about drm_prime backend
21:11 gsedej_: imirkin, so how to report ti?
21:12 imirkin: bugzilla.kernel.org or just send email to nouveau@lists.freedesktop.org
21:13 gsedej_: oh, this does work... i misunderstood you
21:15 imirkin: there used to be a bugzilla.freedesktop.org where all this stuff happened
21:15 imirkin: it got shut down (well, it's in readonly mode)
21:22 gsedej_: oh, the kernel.org and freedesktop.org... why it got shut down? financal?
21:23 karolherbst: imirkin: ahh.. so atoms.cas exists, but not the others...
21:30 HdkR: Who needs anything more than CAS? :P
21:32 imirkin: karolherbst: you mean for 64-bit, right?
21:32 imirkin: ATOMS.ADD and so on definitely exist for 32-bit
21:32 karolherbst: yes
21:32 imirkin: with CAS you can implement the other ones =/
21:33 karolherbst: ATOMS.EXCH exists as well
21:34 karolherbst: no surprise though
21:34 gsedej_: ilmostro, which "component" on bugzilla.kernel.org? Video(DRI - non Intel)?
21:34 gsedej_: imirkin, ment tagging you...
21:34 imirkin: gsedej_: yes
21:34 imirkin: should get sent to dri-devel
21:35 imirkin: karolherbst: if you can do CAS, you can do EXCH =]
21:35 karolherbst: yep
21:35 karolherbst: obviously
21:35 karolherbst: I am wondering if I can just use the pre maxwell lowering
21:36 imirkin: you can use the lowering i added for ... something
21:36 imirkin: for maxwell
21:36 imirkin: oh wait, i never pushed it
21:36 karolherbst: :)
21:36 imirkin: but the thing to do f32 adds on atomic mem
21:36 imirkin: er
21:36 imirkin: on shared mem, atomically
21:36 karolherbst: yeah
21:37 imirkin: AndrewR: ok, so ... the situation is a bit dodgy. the software asks for a YUV_422 format
21:37 karolherbst: mhh, handleSharedATOMNVE4 looks actually quite nice... let's see if I can reuse that
21:37 imirkin: whereas we end up giving it a YUV_420 format
21:38 imirkin: karolherbst: i felt like the maxwell situation was going to work better with the new way
21:38 imirkin: but dunno
21:38 imirkin: i forget why
21:38 AndrewR: imirkin, with potential quality loss, even if conversion will be handled transparently?
21:38 imirkin: AndrewR: well, at least as currently implemented, the hw decoding always produces NV12 buffers (aka YUV 420)
21:39 imirkin: there *is* a place where we tell it to do NV12, but we've never seen the blob pass in any other values
21:39 imirkin: so there's a good chance that's just there for fun
21:39 imirkin: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv50/nv84_video_vp.c#n102
21:40 karolherbst: yeah uff... infinite loops ain't so nice
21:40 imirkin: (and obviously all the other logic assumes that it's NV12 throughout)
21:40 AndrewR: imirkin, still, this is presentation part of vdpau on my side ....so, should it suimply refuse request and hope mplayer will cope with situation?
21:41 imirkin: it used to just provide it with a 420 surface, and no one was the wiser
21:41 imirkin: it's a video surface btw, not an output (presentation) surface
21:42 gsedej_: posted "SCHED_ERROR" bug report on kernel.org https://bugzilla.kernel.org/show_bug.cgi?id=206781
21:46 AndrewR: imirkin, then probably driver shouldn't expose 422 8192 8192 UYVY YUYV and 444 8192 8192 Y8U8V8A8 V8U8Y8A8 ? Or this will break something else ?
21:48 imirkin: AndrewR: yeah, probably not
21:51 imirkin: AndrewR: so there's a subtle question here ...
21:51 imirkin: vdpau supports 422 just fine
21:52 imirkin: just the decoder won't be able to decode into those surfaces
21:52 imirkin: so ... should we advertise those or not? dunno
21:52 imirkin: there's been some recent work for adding 444 decoding too, i think
21:52 AndrewR: imirkin, conditionally on what exactly connected to those surfaces (software or hw)?
21:53 AndrewR: imirkin, sorry for such dumb suggestiion...
21:53 imirkin: but you don't know that at the time of surface creation
21:55 imirkin: the current situation is pretty clearly broken
21:55 imirkin: since there's basically no way it can work
21:55 AndrewR: imirkin, and there is no way to re-ask for something else lately when this type of source on hw side will be known?
21:55 imirkin: it queries for one format
21:55 imirkin: and then checks that format against the value that was passed in
21:55 imirkin: so... it's doomed to fail
21:56 imirkin: driver can only return a single value
21:56 imirkin: while userspace can pass in whatever they want :)
22:01 AndrewR: imirkin, guess for testing I can just disable gallium/state_trackers/vdpau/query.c - line 143 ?
22:04 AndrewR: imirkin, also in same folder in decode.c I see " // TODO: Recreate decoder with correct chroma" - line 605 ...
22:20 AndrewR: imirkin, nope, just returning not_supported there will not prevent mplayer crash :}
22:21 karolherbst: imirkin: see anything which might explain an infinite loop?
22:23 imirkin: karolherbst: well, it loops until the condition matches
22:23 karolherbst: right...
22:23 karolherbst: but I am wondering why that never happens
22:24 imirkin: probably the comparison is wrong
22:24 imirkin: doesn't work for 64-bit or something, dunno
22:24 karolherbst: ohh ehh.. right
22:27 AndrewR: imirkin, just commenting out assert makes thing work - as in I see image with correct colors
22:29 karolherbst: imirkin: ohh.. the locked/unlocked stuff doesn't exist with maxwell
22:32 imirkin: karolherbst: right. that's why it wasn't appropriate :)
22:34 karolherbst: nvidia implements it without control flow btw
22:34 karolherbst: ohh wait.. they do
22:34 karolherbst: but only a simple loop
22:34 karolherbst: imirkin: where was your implementation again?
22:35 karolherbst: heh: IADD RZ.CC, -R6, R4 ;
22:35 karolherbst: I doubt we do this kind of opt yet?
22:36 karolherbst: ISETP.EQ.U32.X.AND P0, PT, R11, R7, PT
22:37 imirkin: karolherbst: https://github.com/imirkin/mesa/commits/tmp-for-karol maybe this?
22:40 karolherbst: imirkin: nvidia doesn't load inside the loop
22:41 karolherbst: ohhhh
22:41 karolherbst: they are smart
22:41 karolherbst: imirkin: interested in an impl without the load inside the loop? :p
22:42 karolherbst: so here is the idea: 1. load the value and do the add 2. enter loop 3. ATOMS.CAS and compare 4. if expected value exit 5. if unexpected add again and sync on the loop header
22:43 imirkin: iirc i couldn't quite get the nvidia way to work
22:43 edgecase: where in userspace is the modesetting for egl/drm? kmscube and any egl app has a problem with framebuffer scanline padding and I'm going mad chasing around libgbm, libdrm, mesa, mesa driver...
22:43 imirkin: nowhere. modesetting is in the kernel.
22:43 karolherbst: imirkin: shouldn't be too hard though.. let me try to do that for the 64 bit stuff
22:44 imirkin: karolherbst: go for it
22:44 edgecase: imirkin, dlopen() makes it hard to find... userpace has to ask for mode, to get xdisp, ydisp, xtotal
22:44 imirkin: oh, sure
22:44 imirkin: just look at modetest
22:44 edgecase: modetest does it, so where is that in egl stack?
22:44 imirkin: egl stack doesn't care
22:45 imirkin: something like gbm might
22:45 imirkin: since it provides the winsys
22:45 edgecase: i have an issue where drm "native" apps work, but apps using egl/drm from console, got htotal (padding) wrong
22:46 imirkin: egl has to have a winsys
22:46 edgecase: so, "modesetting" such as it queries kernel to get framebuffer info, has a problem
22:46 imirkin: what winsys are you using
22:46 edgecase: linux fb
22:46 imirkin: the xf86-video-modesetting thing has logic in a file called drmmode_display.c iirc
22:46 edgecase: sorry if egl isn't the right term
22:46 edgecase: it's what kmscube does from console
22:46 imirkin: egl is just a glue api
22:46 imirkin: kmscube uses the gbm winsys
22:47 edgecase: right, and that's where i get lost, does gbm call a backend, or is that obsolete?
22:47 imirkin: right, gbm also has a few variants
22:47 imirkin: one of which is drm
22:47 edgecase: gbm creates a bo from the drm fd, so it must use ioctl to get KMS info
22:48 edgecase: but it calls it from a function pointer gbm->bo_init or such
22:48 imirkin: it's some of the most indirected code i've seen
22:48 edgecase: I Do Not Like It Sam I Am
22:49 imirkin: https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_drm.c
22:49 edgecase: Would you could you with a fox, would you could you in a kmscube?
22:50 edgecase: ok that makes sense, gbm uses drm as backend. I was looking for words like radeon, nouveau
22:55 imirkin: ah yeah, it's all generic
22:56 edgecase: dri2_dpy->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_STRIDE, &pitch); looks promising
22:56 edgecase: does image mean dlopen()'d thing?
22:56 imirkin: no. image = ... image
22:56 imirkin: a thing with format, width, height, stride
22:56 imirkin: and apparently a lot of function pointers
22:57 imirkin: dpy = display btw
22:59 edgecase: it's talking about a loader
23:00 imirkin: probalby some stupid thing in state_trackers/dri/dri_image.c or something
23:56 karolherbst: imirkin: I know why your CAS stuff didn't work
23:56 karolherbst: CAS only takes one source
23:56 imirkin: nv50 ir works a bit different
23:56 karolherbst: sure, but the second source is ignored
23:56 karolherbst: and you have to merge into the first one
23:56 imirkin: but they're merged, so it's OK
23:56 imirkin: (hm, did i forget a step there?)
23:56 karolherbst: yes
23:56 imirkin: perhaps that's not the latest, hold on
23:57 imirkin: $ git branch | wc -l
23:57 imirkin: 69
23:57 imirkin: sigh
23:57 karolherbst: 109 :p