03:15 damo22: i have an existing linear framebuffer set up by grub, and i want to use it as a mesa surface. What do i need to implement? I looked in libdrm and found omap driver that looks pretty simple but it doesnt refer to anything drawing to the screen, it only mentions buffers and how to allocate them
03:16 damo22: i get that drm passes ioctls to hardware for acceleration, but i dont need any of that, i just have a fb
03:18 airlied: damo22: what do you mean by a mesa surface?
03:19 airlied: the only think I can think off is simpledrm
03:19 damo22: for example, can i use the linear framebuffer as a place to draw opengl swrast
03:20 airlied: yeah then I think you just want simpledrm
03:20 damo22: i dont have a linux kernel
03:20 airlied: then you should get one of them first :-P
03:21 damo22: im implementing this for GNU/Hurd
03:21 damo22: we already have an existing framebuffer set up with a width and height, and a video memory address
03:24 damo22: ideally we could port drm from the linux kernel but im not ready to attempt all that, it should be possible to implement swrast backed by a dumb framebuffer
03:26 airlied: what API do you want to access mesa with though? OpenGL, Vulkan?
03:26 airlied: you need something to bind the "framebuffer" to the API
03:26 damo22: could i implement the gbm interface?
03:27 airlied: yeah gbm seems like where you'd do it
03:28 airlied: but without any sort of vblank or pageflip it'll tear
03:28 damo22: so i would swap out the gbm_dri with a gbm_dumbfb
03:30 airlied: someone else might have a better clue if you hang around, maybe someone from weston or another compositor
03:31 damo22: i thought i could implement a dummy drm driver, that would allocate buffers in cpu memory instead of using gpu
03:31 airlied: that might be easier
03:31 damo22: but i cant seem to find any calls that actually draw anything
03:32 airlied: well you don't need calls to draw anything in the kernel if it's all in software
03:32 damo22: it needs to write the memory to the framebuffer though to make it appear on the screen
03:35 airlied: I think we usually do writes to the frontbuffer in the kernel using dirty handlers
03:35 damo22: what is an example of an ioctl that writes to the frontbuffer
03:36 airlied: drm_mode_fb_dirty_cmd
03:36 airlied: sw renders to the buffer, and that will sync dirty regions to hw
03:37 airlied: I think we must have some use case that direct renders to the scanout, but I'm not exactly sure what that looks like
03:40 damo22: ok thats helpful
03:50 damo22: could i implement page flipping in software by copying a complete frame from another memory location?
03:51 airlied: yup
03:51 damo22: :D
11:06 dualperform: what i think is the win comes compared to hw, that the result can yield a smaller value, so how the hw sees it, is that we have no 33+1 but have 34+2, and inverted index causes a invariant sum, so it sorta like uses the offset from collisions even if we never use a count based resulting, the internal adder of sub and add would count the offset. and decoder would add the weights, so i
11:06 dualperform: would not see where the entropy comes from if you pin the results correctly, it's more like lynne told, that those guys were so hell of a smart they preserved a large entropy in the hw for the sake of the future gates and this scenario is more plausible than that being a side effect of electron shells being too small to be not doing it. But my explanations are not so understandable as i
11:06 dualperform: have noticed. But Claude Elwood Shannon is no longer alive, maybe Peter Shor or someone more experienced could try to explain this. The way i see is that it can shift the spectrum by having vision to the both sides of the polarities, hence i would expect the sw sides of things to have no entropy if you order the results at correct indexes, empirical entropy aka Shannon entropy, they
11:06 dualperform: regard him as the informatics father, likely was an amazing man as how it seems.
12:37 alyssa: glehmann: so I did start looking into int16 stuff and ugh it's turning into a mess
12:38 alyssa: giant pile of patterns for things like `u2u16(iadd(x, y)) -> iadd(u2u16(x), u2u16(y)`
12:38 alyssa: but for iadd/isub/imul/ixor/iand/ior/inot/ineg (at least)
12:38 alyssa: and really u2u16 also u2u32 for x is 64
12:39 alyssa: and really why not u2u16 with x 64? idk if llvm generates that ever
12:39 alyssa: and then we really *do* need to do something about shifts. not sure how to get around the current sm5 definition but yeah
12:40 alyssa: and fundamentally the problem here is C's stupid constant promotion rules means that CL C code that uses exclusively 16-bit, actually uses 32-bit with a gigantic pile of conversions
12:40 alyssa: and I'm.. trying to figure out if nir_opt_algebraic is even the right tool for the job, vs some clever handrolled pass
12:41 alyssa: we can generate all the permutations but if it turns into 100+ patterns, that seems... substantial
12:42 alyssa: and then 8-bit is a whole other can of worms, that I won't open because AGX doesn't have real 8-bit arithmetic (so these patterns would just undo the 16-bit lowering) and because 8-bit arithmetic is mostly pointless on Mali which does have it
12:44 alyssa: I can't tell how much of this is "not useful for other backends" vs just "nobody is very focused on OpenCL"
12:44 alyssa: I could easily believe that HLSL/GLSL does't hit any of this and it's only CL C because of the const promotion rule
12:45 alyssa: er, integer promotion rather
12:50 alyssa: https://reviews.llvm.org/D133668 has some interesting discourse
13:16 karolherbst: alyssa: yeah.. austriancoder ran into the same issue, but undoing integer promotion is a huge pita
13:17 karolherbst: for some operations it's super safe e.g. add
13:17 karolherbst: but for others it's not
13:17 karolherbst: though.... if all operands are converted then maybe it's fine
13:18 karolherbst: the biggest problems just arise if you have constants in the mix
13:24 austriancoder: alyssa: it's fun
13:32 austriancoder: Vivante can do 8-bit arithmetic
13:32 alyssa: austriancoder: don't bother, it's not worth it :shrug:
13:37 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/65870229#L2671
13:38 alyssa: well that's... exciting
13:38 alyssa: "can't run CTS, ethernet driver panicked"
13:40 zmike: CTS has to connect to the khronos servers to verify that you have a legiimate vulkan installation
13:42 alyssa: ah yes forgot about the DRM
13:44 pinchartl: whaaat ? the CTS can't be run freely ? :-(
13:45 alyssa: pinchartl: zmike and i were doing sarcasm
13:45 zmike: sometimes I ask myself whether I have shitposted too hard
13:45 zmike: then I shitpost harder
13:46 Ermine: You can never shitpost too hard I'd say
13:47 pinchartl: :-)
13:47 pinchartl: you scared me for a moment
13:49 Ermine:wants more DRM puns
13:49 MTCoster: How about... more DRMa?
13:49 MTCoster:leaves
13:54 daniels: in the future we'll be able to transfer dEQP to the device through vibes and good intentions, but itmt we're stuck with NFS
13:57 DemiMarie: dEQP?
13:58 daniels: DemiMarie: not being funny, but the search engine of your choice should tell you exactly what dEQP is
14:04 alyssa: daniels: oh ye I get it, I just was not expecting a kernel panic in an ethernet driver of all things xD
14:09 alyssa: I think I once panicked btrfs...
14:09 alyssa: and it was going so well
14:10 alyssa: "it?" "running x86_64 dEQP-VK on an arm64 box"
14:45 sima: alyssa, the kernel has other duties than to panic for max entertainment?
14:47 alyssa: sima: well sometimes it needs to hang without panicking
14:49 sima: ah right
15:09 Ermine: Kernel wants to rest sometimes
18:40 DemiMarie: daniels: sorry, the way you wrote your sentence made dEQP seem more exotic than it is
19:34 dcbaker: zmike: I heard that you wanted to push the release by another week?
19:34 zmike: dcbaker: I think so cc Danct12
19:34 zmike: daniels:
19:34 daniels: yes please
19:35 dcbaker: that pushes the release back almost a month, in a three month cycle, and means that we'll be trying to do RC work during US Thanksgiving
19:43 dcbaker: zmike, daniels: is this related to the wayland-protocols changes?
19:45 daniels: why does it add a month?
19:46 daniels: or do you mean that adding a week makes the delays, cumulatively, a month
19:46 dcbaker: mumulatively
19:47 dcbaker: *cumulatively
19:47 dcbaker: We already pushed the branchpoint two weeks out to today, it was originally planned for the 16th
19:48 daniels: ack