09:30 handsfullof: So the last execution format i described in a slight fuzzed text form (during the XDC as nick clarifiedonce), turned out to be functionally correct if i opened the calculator as well. It's just the data based access i described now some couple of days ago is yet easier to understand. So i am moving into compiler designing now. But today i have handsfullofwork in the garden, and overall in
09:30 handsfullof: general i am extra busy. There is no other complexities, the way powers are skipped based of the offset is a logics function in the hardware internal adder or carry and indexes are precompiled from the Cornell entropy pdf. So the functional specification is there as of now. Now i choose a cross arch disassembler which is the thinnest possible and start to lay out the code. And your
09:30 handsfullof: disrespect towards me has been immense , while terror has been on bar with my other fellowcitizen freaks in life, who have no other achievements whatsoever to show. I would say, you are not very talented in contrast to how your mom or you yourself tend to think, real people need to solve all formulas to you and i had done it in hopes that the terror is dettached from me, but it does not
09:30 handsfullof: seem to work, as leftovers are just so big time abuse oriented. And it seems you need to be handled with force instead still.
09:30 handsfullof: I had a lot of problems with amoral activity done against me by estonians, such as hippocracy, betrayal and kill off attempts.
09:31 handsfullof: it was spread out to all of the world by the original freaks.
10:10 MrCooper: janesma: if I may ask, are you working for AMD now?
12:14 phasta: is it some sort of official policy in DRM to have a patch changelog *within* the patche's commit message, or do some people just do that voluntarily?
12:19 javierm: phasta: usually the changelog is between the --- at the end of the commit message and the start of the diff, since that section is ignored by tools like git-am
12:20 javierm: phasta: but I see that some people add the patch history in the commit messag as well. I would say that's the excpetion rather than the rule though
12:20 phasta: javierm, I know. But in DRM (and other subsystems) some move the changelog into the commit message. Which I think is quite useless. Who cares about what was done before it was merged?
12:22 javierm: phasta: yeah, but as said that's the exception. And I agree that having the patch history in the commit message doesn't add value
12:23 phasta: it does add bytes, though :D
12:23 phasta: not even a joke, my kernel tree is 6.5GB, and 5.0GB of that is git history 0_0
12:30 callonmark: phasta: their compression methods are jokes their execution ways are jokes, and all the people on that channel are though not as even best joke, but just suicidal terrorists. So as to how the indexes come, you could see, that i figured those gaps out in manual ways, but from the pdfd which is entirely correct in it's lemmas and theorems. uniform distribution of 16,17,18 is taken from
12:30 callonmark: formula of binary probability theorem. −16×log2−(1−16)×log(1−16)=12.82+20.47i aka 33.29 i.e rounded to 33 in fixed integer , so 17 is already 35.98 so 36 etc so forth, they can use different theorem, but that definitely works too.
14:25 arnd: tzimmermann: I'm getting a ton of link failures in randconfig builds after dadd28d4142f ("drm/client: Add client-lib module")
14:25 arnd: with CONFIG_DRM=y CONFIG_DRM_CLIENT_LIB=m CONFIG_FB_CORE=m
14:26 arnd: x86_64-linux-ld: drivers/gpu/drm/drm_fbdev_shmem.o: in function `drm_fbdev_shmem_driver_fbdev_probe': drm_fbdev_shmem.c:(.text+0x1fc): undefined reference to `fb_deferred_io_init'
14:26 arnd: I have some local patches that I never mainlined and that could interact with this, but I suspect the same thing happens in linux-next
14:26 tzimmermann: arnd, can you post them somewhere for me to take a look?
14:48 somanoni: Now there is no one having any questions or what now? Might you want to continue those mental illness talks I promise you are dead from the word go soon all? Now i am here the last time to say that i am wastly overqualified to work for AMD/intel/Nvidia to play clown there to mindbuggle people. I earn a lot more money without their presence or having such around me somewhere. The things you
14:48 somanoni: do and talk are so easy concepts and you are entire mental garbagewrecks to me, to say the least out cause i have need for time and effort with it in elsewhere. 8b10b emulation is not in any way as complex as my compression. Maybe you try to say that Grigori Perelman is also mentally ill cause from eastern side born, i do not care about fraud of United States and their jew shit as to how
14:48 somanoni: they pick out winners from their lines and backtrack ideas to their own staff. DMA always works on all chipsets and i already exposed anything needed, you want read-modify-write procedure https://compas.cs.stonybrook.edu/~nhonarmand/courses/sp15/cse502/res/dramop.pdf It is beneficial to di memory ops there , because they are very fast that way and very low power too.
15:08 janesma: MrCooper: no, I am evaluating their platforms for a commercial product
15:10 MrCooper: gotcha
15:27 arnd: tzimmermann: I sent a report in the form of a patch now
15:28 arnd: I would give it a 50% chance of being the correct solution
15:29 arnd: the problem being that it rarely goes wrong in randconfig builds, and my patch makes it less likely to hit the remaining problems if I missed one
15:41 tzimmermann: arnd, thanks
17:23 RossComputerGuy: Hello, I have questions about Mesa and GBM. Is this where I could get some help or is there a different IRC I should join?
17:23 Ermine: this is the place
17:24 RossComputerGuy: Cool.
17:24 RossComputerGuy: I've got a problem where gbm_surface_lock_front_buffer is causing a SEGFAULT and the backtrace has NULL in it. My assert before says the surface != NULL but idk why it would be causing a SEGFAULT.
17:32 MrCooper: can you pastebin the backtrace?
17:33 RossComputerGuy: MrCooper: sure, here you go. https://pastebin.com/Ra1uDEDf
17:33 RossComputerGuy: This is also the exact code where it failed https://github.com/RossComputerGuy/gtk/blob/e16d2f7375745058a704935075f6a32c3883ab36/gdk/drm/gdkmonitor-drm.c#L360
17:48 MrCooper: ah, you're adding a DRM backend to GTK? Does it link libgbm.so.1 directly, or dlopen it? And which GPU driver is it?
17:50 RossComputerGuy: It links directly to libgbm.so.1 directly, I'm running the asahi driver right now.
17:51 RossComputerGuy: And yeah, I'm adding a DRM backend to GTK. Currently developing it on GitHub and will move to the GitLab for GTK once it's ready.
17:51 Company: people are adding lots of backends these days - someone should fix up our backend APIs...
17:52 RossComputerGuy: Heh yeah, the way OpenGL is handed is kinda not what I was expecting lol.
17:53 Company: that's a combination of historic baggage from GTK3 and me not knowing enough about GL when designing that part
17:54 Company: also, the whole drawcontext stuff should be driven by the surface, not vice versa
17:54 Company: ie there should be a surface->draw_context
17:54 RossComputerGuy: Yeah, that kinda threw me off. One of the things I hope to have is a tiny compositor inside the DRM backend so multiple surfaces can exist on a single monitor
17:55 RossComputerGuy: I was surprised that I couldn't just query all surfaces easily.
17:55 Company: that's because GTK3 allowed you to live-switch between GL and non-GL rendering, so we thought we'd keep that
17:55 Company: and make it public API, so people could write more ways to draw with
17:55 RossComputerGuy: Makes some sense, however I do see how that can cause problems. Especially with the DRM backend.
17:56 Company: we only later learned that that's impossible
17:56 Company: because you can't render with GL if you have a Vulkan swapchain - the 2 drivers will fight each other to the death (of the application)
17:58 Company: what I ultimately want is to have a surface->renderer/draw_context that's driven/owned by the backend
17:58 Company: and GTK just does gdk_surface_set_content (surface, rendernode); and then the backend decides by itself when/how to render that
17:58 RossComputerGuy: Oh that would be nice, maybe it could support some primitive rendering commands like compositing a texture into the renderer?
18:00 Company: you could do that by checking if the rendernode is a texture and using that
18:01 Company: though the way we render straight textures is via graphics offloading - see gdksubsurface.c and the wayland impl for that
18:01 RossComputerGuy: Inside GDK? I need a basic compositing layer for the DRM backend so multiple surfaces can render on one monitor.
18:02 Company: yeah, that's why I'm wondering about the usefulness of a DRM backend
18:02 Company: because it needs to implement all the functionality of a simple Wayland compositor
18:03 Company: and it seems much simpler to me to just go with simple compositor + GDK's Wayland backend
18:04 RossComputerGuy: The problem is I'm wanting to build a Wayland compositor using GTK lol. Doing a shell isn't too difficult but wanting to do everything inside GTK and GDK is difficult.
18:04 Company: I've argued that with a lot of people over the years, and my conclusion ois that it should always be 2 processes
18:04 RossComputerGuy: The alternative is each monitor gets one surface, surfaces can expose a texture and it is up to the developer to write the compositor.
18:05 Company: because you want the core loop of the compositor to be fast and simple
18:06 Company: and GTK is complicated and opinionated, so it can provide a simple API for its widget toolkit
18:06 RossComputerGuy: What about when you want the shell to provide window decorations and control the window layout?
18:09 Company: it's a tricky question that I don't have a good answer for - if I were to write it, I'd probably go with an external window manager process that talks a custom Wayland protocol with the compositor process that tells it where windows are and takes cpommands to move them
18:10 Company: don't think that topic has been explored - all compositors I know put the window management into the core process loop
18:10 Company: also, we're vastly off-topic here
18:11 RossComputerGuy: Oh lol, yeah. I need to get that GBM surface lock bug fixed.
18:31 cheako: wine/battlenet uses the i686 mesa libraries, what's the best distro/setup for building mesa from git branches for the two architectures?
18:32 cheako: I'm using debian stable, but I plan on running wine in a distrobox.
19:49 mattst88: cheako: gentoo has an ebuild that builds mesa from upstream for 32-bit and 64-bit
21:07 cheako: Perhaps it's time to stop building mesa twice and instead build a new project that bounces the i686 calls to x86_64 libraries?
21:40 DavidHeidelberg: any favorit (neo)vim glsl highlighter? Just found https://github.com/tikhomirov/vim-glsl and feeling pretty happy with it
21:40 DavidHeidelberg: had to add shader_test extension support though, so it's easy to work with it with piglit and shader-db stuff
22:39 mareko: jenatali: does d3d12 have something like drm-shim, so that I can reproduce d3d12 crashes locally?
22:49 jenatali: mareko: not currently. Theoretically you could do vkd3d-proton?
23:17 jenatali: Or feel free to ping me if you need me to look at something