01:43 tertl3: hi I would like to casual chat about this option in gnome 40 - "launch using discrete graphics card"
01:44 imirkin: they just mean secondary graphics card
01:44 imirkin: making that the primary rather than the main display card
01:44 imirkin: useful if you have an optimus-type setup and don't care about battery
01:44 imirkin: (or vsync)
01:54 tertl3: so it runs it on the cpu instead of the 1060 when I choose that?
01:54 imirkin: should run on the 1060, assuming primary is intel or whatever
01:55 tertl3: so if I dont choose that then it runs it on the cpu?
01:55 imirkin: it runs on the intel *gpu*
01:55 tertl3: it even lets you choose for chrome
01:55 imirkin: "run on the cpu" implies it's running software rasterization, which is something different
01:56 tertl3: do you notice a difference?
01:56 imirkin: software rast is super-slow
01:56 imirkin: and very power inefficient
01:56 tertl3: but it wouldnt do that either way right?
01:57 tertl3: unless you didnt have a gpu at all
01:57 tertl3: of either type
01:57 tertl3: discrete or otherwise integrated
02:00 imirkin: right, you'd have to go out of your way to make that happen
03:02 tertl3: interesting
03:02 tertl3: im watching this dude https://www.youtube.com/watch?v=x1oXByIJcHU
03:02 tertl3: its a fosdem talk Back to the Linux Framebuffer! Linux Framebuffer support in free software by Nicolas Caramelli
03:03 tertl3: he is obsessed with the frame buffer
03:03 tertl3: i do want to try out his examples though
03:03 tertl3: where is the frame buffer stuff in the kernel source?
03:05 tertl3: oh here we go https://github.com/torvalds/linux/tree/fcadab740480e0e0e9fa9bd272acd409884d431a/drivers/video/fbdev/nvidia
03:06 tertl3: nvidiafb occurs 77 tiems in this file
03:07 imirkin: nouveau provides a fbdev as well
03:09 tertl3: ah ok
03:09 tertl3: it would be "nice" if linux folders to have a read me in github
03:10 imirkin: send patches.
03:11 tertl3: or even for the files too
03:11 imirkin: see above.
03:11 tertl3: i think Torvalds would yell at me
03:11 tertl3: for being so naive
03:11 imirkin: doubtful.
03:11 imirkin: you'd have to do something much more actively dumb to get yelled at
03:12 tertl3: like if this file had a README, i might be able to learn something from it nv17_fence.c
03:12 imirkin: unlikely.
03:13 tertl3: no comments or anything
03:14 tertl3: i do notice that the fbcon.c and fbfense.c only go up to nvc0
03:16 tertl3: there are some questions I have seriously, like, have the nouveau devs attempted to make power and video decoding acceleration for my card/generation or are they worknig there way towards the newer cards?
03:17 tertl3: or is there something complicating adding those features to the pascal and newer card
03:18 imirkin: what card do you have again?
03:18 tertl3: 1060 6GB, GP106, nv136
03:18 imirkin: video decoding accel: nope
03:19 imirkin: no plans on it ever being implemented
03:19 tertl3: what do yo umean nope?
03:19 tertl3: oh
03:19 imirkin: power states: requires signed firmware from nvidia, and there are additional complications that would make this tricky even if we had that
03:19 tertl3: ah ok
03:20 imirkin: video decoding should be achievable
03:20 imirkin: it's just that nobody's stepping up to the task
03:20 imirkin: i'm probably the best person to do it (since i did VP2, and a bunch of fixing on the vp4/5 stuff)
03:21 imirkin: but i've lost any sort of motivation for it
03:22 tertl3: oh nice
03:22 tertl3: the H.264 acceleration is big
03:23 tertl3: i think thats what my screen recorder uses
03:23 imirkin: video encoding is another one that needs doing
03:27 tertl3: ive been using wf-recorder on my sway setup to record my music production program
03:27 tertl3: obs-studio is just now getting wayland support
03:27 tertl3: so its not working on my machine yet
03:28 tertl3: hopefully when fedora 34 ships it will be all good
03:28 tertl3: to be honest, wf-recorder works pretty snappy on this machine
03:35 tertl3: https://usercontent.irccloud-cdn.com/file/hF8thQsP/output.gif
06:40 pmoreau: imirkin: I probably need something similar for loads, but so far the issue is with stores (which is why I’m mentioning `combineSt()` and not `combineLd()` 😉). So I guess your comment from a month ago was also about loads which makes more sense, but even flipping the values (i.e. setting dType to U8 and sType to U32) still results in an error as `sizeSt = typeSizeof(st->dType)` but then it subtracts `st->getSrc(s +
06:40 pmoreau: 1)->reg.size`.
06:53 pmoreau: imirkin: I added both MRs to my to-do list, and rebased my compute branch on top of yours.
07:00 imirkin: pmoreau: cool
07:00 imirkin: pmoreau: it'd probably be helpful if you could provide a sample program pre-memory opt
07:00 imirkin: since it's not immediately clear to me what the situation is
07:00 imirkin: and a program is worth a thousand words :)
07:01 imirkin: (or dwords?)
07:02 pmoreau: :-)
07:02 pmoreau: Sure, one sec
07:09 pmoreau: imirkin: Here we go: https://gitlab.freedesktop.org/pmoreau/mesa/-/snippets/1861; note that this is without the changes to dType and sType.
07:10 imirkin: pmoreau: ok, and is %r106 a 32-bit ssa value or 8-bit?
07:10 pmoreau: Should be a 32-bit one
07:11 imirkin: are 8-bit l[] stores possible?
07:11 imirkin: (i don't know offhand)
07:13 pmoreau: I don’t think the hardware complain about those, as some of the tests using them do succeed.
07:13 imirkin: pmoreau: ok, so i think using ->reg.size there is wrong
07:13 imirkin: i think it should be looking at the sType / dType
07:14 imirkin: but ... it's slightly tricky
07:14 pmoreau: I assume there are no load/store op that could take differently-sized arguments, right?
07:14 imirkin: well, load/store do a single op
07:15 imirkin: the problem
07:15 imirkin: is that you have a bunch of u32 values where you only care about the lower u8
07:15 imirkin: and then you e.g. want to load that whole range
07:15 imirkin: the memoryopt logic is likely to get quite confused
07:15 imirkin: honestly i'd just run purgeRecords() anytime i saw a < 32-bit load/store
07:16 imirkin: and leave solving it to another day
07:17 pmoreau: Could do that 👍️
19:41 imirkin: pmoreau: btw, heads-up, i moved the offset stuff into nv50_ir_from_tgsi, so you'll need to make an analogous change in from_nir
19:42 pmoreau: 👍️ I saw your change, and I had already a similar change locally so I’m already ready for it. 🙂
19:44 imirkin: cool
19:45 imirkin: i think we're getting closer
19:48 pmoreau: Currently going through your series
19:50 imirkin: the only stuff after that are "bug fixes" at least as far as core goes
19:51 imirkin: and i can start looking at your work getting CL going
19:52 imirkin: but let me know what to look at :)
19:56 pmoreau: Sounds good! Branch-wise, it would be the nv50_compute_support branch. Feature-wise, I am mostly trying to at least get the basic test from the OpenCL CTS to fully run without errors (ignoring running out of reg space for now).
19:57 imirkin: which ones concretely?
19:57 imirkin: (which basic tests)
19:58 imirkin: i picked a random basic-seeming test and it was prettyc omplete fail
20:15 pmoreau: The one called test_basic :-) (which does test quite a few things and is made of sub-tests that one can run individually).
20:16 pmoreau: I do not remember what the current status is with that test, but it definitely got some pass.
20:16 pmoreau: I see I will need to implement something similar to “nv50: add remapping of buffers/images into unified space” for the NIR frontend.
20:28 pmoreau: https://github.com/KhronosGroup/OpenCL-CTS/blob/master/test_conformance/basic/main.cpp is the one I am referring to, which indeed does quite a few things. You might want to grab https://github.com/pierremoreau/OpenCL-CTS/tree/support_opencl_1.0_and_1.1 rather than the version from Khronos, as I added a couple missing version restrictions.
20:35 imirkin: pmoreau: ah ok
21:03 pmoreau: imirkin: I’m setting a list of all the current fails with basic on my G96 here https://gitlab.freedesktop.org/pmoreau/mesa/-/snippets/1865. So far it seems to mostly fall into 1) uses too many registers, or 2) indexing issues for non-32-bit values to/from local or private memory.
21:04 imirkin: pmoreau: cool
21:04 imirkin: well let's not worry about fixing everything at once
21:04 imirkin: i'd rather get your stuff in which gets it this far
21:05 imirkin: and then we can evolve a common base
21:05 pmoreau: A few missing features as well such as u2u16, or SV_WORK_DIM in `getSRegEncoding()`.
21:05 imirkin: what's SV_WORK_DIM?
21:05 imirkin: it's that stupid extra arg, right?
21:05 imirkin: can we pass it in via the argument param?
21:06 imirkin: if it's 16-bit then it fits
21:06 pmoreau: I think it says whether the grid is 1D, 2D, or 3D.
21:06 imirkin: oh, so literally "1, 2, 3"?
21:06 pmoreau: If it’s what I believe it is, yes
21:06 imirkin: heh ok
21:06 imirkin: yeah, that should be easy
21:06 imirkin: worst case we burn an extra user param
21:06 imirkin: we could pack it along with the 'z' value
21:06 imirkin: which doesn't need all 32 bits
21:07 pmoreau: Seems reasonable
21:18 imirkin: pmoreau: btw, i dunno that you need to do anything right now for the gmem index remapping stuff -- until you hit images, it's all out of g15 for now, which is special
21:20 pmoreau: Ah okay, then that will be for later as I haven’t started looking at images yet.
21:22 imirkin: for GL, you have multiple buffers, all in their own happy g[] spaces
21:23 imirkin: but in CL, it's all one happy space
21:29 pmoreau: There we go, snippet updated with all the sub-tests from basic now, and the overall picture does not change: the two main sources of failures are 1) using too many regs, and addressing issues in local memory for non-4-byte values. If ignoring images, it seems like very little is otherwise missing feature-wise, and there might be an issue or two that lie in clover.
22:13 imirkin: pmoreau: "nv50: add compute support" -- did you mean "nv50/ir: offset accesses to shared memory"?
22:17 imirkin: (for the patches which i should add your r-b to)
23:46 karolherbst: why is this hda discussion running into red herring arguments again? : *sigh*
23:46 karolherbst: :/