00:17uis: I want to draw many quads. And many data (e.g. lightning) are per quad. What faster: tbo, gs or inctancing?
00:19karolherbst: uis: benchmark it
00:19karolherbst: it always depends on the amount and complexity and everything
00:27Lightkey: That sounds like 42 is your answer.
01:59karolherbst: can we delete this wiki page or state that Wayland is X12 or somethign? :D https://www.x.org/wiki/Development/X12/
14:14uis: What faster? glBindTexture or glTexBuffer?
14:18belarien: and all the google work is just unforgivable shit, a week i am being trying to make sense of electron framework, it is so volatilely rndomly crashing so fucking slow, so bulky, so slow compile, so bad memory usage, i knew it was bad but i guess i hoped to see some world progrmmers to have a little brain present.
14:28belarien: listem you can not really do keep on committing such bullshit anymore , is it so hard to get yourself together, it is incredibly shocking.
14:30clever: uis: i suspect it would vary from card to card, and possibly even within a driver
14:31clever: uis: as a random example (the only gpu i know the internals of), the v3d on the rpi series of chips has no true GPU memory, but the GPU isnt coherent to the arm caches, so you have to (at a minimum) flush the arm caches for any texture data, and ensure its contigious in the physical space
14:31clever: if the image wasnt allocated within special dma-capable ram, then you also have to copy it to some physically contigious ram
14:32clever: the opengl implementation might then do funky stuff ontop of those limitations, like generating a texture atlas for you (more copies), to reduce the number of textures (i think v3d is limited to one texture for the whole shader)
14:34belarien: I am so much overflooded with work, i can not fix so many staggering issues, hence i resorted to helping with theory...I have an helpdesk to ask how to do things , no money charged, you can not really do that bad to the rest of the community and people, you just can't,
14:38belarien: You must had understood something wrong about memory allocation, or how the double data rate refreshed memory or SRAM or such things function, those very good memories when treated sanely.
14:39belarien: This is not sane that i sysctl -w mmap objects , stuff still leaks 8GB of swap is not enough and randomly still compilation runs out of memory, it is so bad really.
14:42belarien: normally this type of DDR memory was meant by hw designers to be used with linefill separate cache, it's throughput is programmed equivalent to the SRAM, cause SDRAM and DDR they normally 16banks arbitrated.
14:43belarien: so it is 10times slower per bank, but it has 16 banks in comparison to SRAM i.e register based stuff, flip-flops.
14:43belarien: it has 1T and one capacitor though, flip-flops are made of transistors
14:44belarien: the linefill buffers from the bus to the whole memory address space comes with writecombined marking of the memory.
14:47belarien: normally this strategy i used for framebuffer cause this interruption is timing critical also
14:48belarien: so to correctly grab the framebuffer from kernel, it takes without compression or reusing the or unpacking the memory roughly only 1ms
15:49belarien: 1ns is only a memory read which is behind a rising clock cycle edge synced sorta. The memory without syncing to that clock edge, is read in picoseconds, 1GB of memory is ready in 1ms actually.
15:50belarien: DDR is little bit cheaper than SRAM, i mean quite some way to be honest. It is very neatly integrating to the rest of the hw.
15:55Vanfanel: Hi! I am adding Vulkan support to the KMSDRM backend of libSDL2.
15:56Vanfanel: Do you guys have any idea on what could I be missing when trying to get the pointer to vkCreateDisplayPlaneSurfaceKHR() here? -> https://github.com/vanfanel/SDL/blob/e9c636f445521e9c066d290028958e057b7158f3/src/video/kmsdrm/SDL_kmsdrmvulkan.c#L146
15:57Vanfanel: I mean, in what cincumstances does vkGetInstanceProcAddr() return NULL if the function DOES exist?
15:57HdkR: If you haven't enabled the extension
15:58HdkR: Make sure to have asked to enable the `VK_KHR_display` instance extension
15:59HdkR: Looks like you're only asking for `VK_KHR_surface`
16:00Vanfanel: HdkR: Oh, what I need is a VK_KHR_Display_Surface, right?
16:00belarien: you know Vanfanel exactly like this kind of people are very troublesome to the community and they are misled by Khronos, for christ sakes you never should be getting any pointer with such crazy extensions to the context, not even an address of MMU VRAM, all you do is pack enourmous smount of stuff to the variable that is held in cache or ddrm write combined memory
16:00belarien: then you unpack it on chip alus
16:01HdkR: Vanfanel: According to the documentation for VK_KHR_display, it's the extension that provides that pointer. https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_display.html
16:01Vanfanel: HdkR: so first I enable the extension, right?
16:02Vanfanel: belarien: I believe you have mistaken me for other person
16:02Vanfanel: HdkR: Thanks, I will start with that
16:04belarien: No, All i am saying , it is as always this portland or whatever based organisation is United States Organisation , they are good at giving shit to people.
16:04belarien: and most likely deliberately
16:12belarien: There are so many designers from that country knowing how computers actually work, IO bus is async transactional bus, when you post it something it will process it through the pcie bridge to the IOHUB of the cpu, those kind of buses are in-order transaction pipelined buses, with write and read controllines and data out, nothing more.
16:12belarien: IOHUB chipset is another chipset on the motherboard.
16:14belarien: IOHUB itself appears as a PCI interconnect bus, which allready explained IO registers have this control line logic.
16:31belarien: because interconnects carry very few latency in their calculations, i.e no alus and deep pipelines like compute logics, actually interrupts are not useful most of the time, all the time i mean
16:33belarien: so those guys saying that IO can be handled from userspace are indeed correct, and linus is wrong, maybe even Sharp some lady said that, but in the linux conference linus said this is not possible that java guys are crazy to state that
16:33belarien: actually it is possible
16:35belarien: Someone who wrote USB userspace drivers at intel Sarah Sharp was her name, she got into arguments with Linus Torvalds, now if she was on that side of the debate which i described now, basically this is possible of course.
16:44belarien: you can do this in many ways, but most popular ones are self-modifying code and entirely hw based solutions.
17:03karolherbst: some progress on rustcl: https://gist.github.com/karolherbst/dd416223ac719f0b15d91cba363c58af :)
17:03karolherbst: soo. I think at this point I can say it's definetly doable and actually not that terrible
17:03karolherbst: amount of unsafe is quite low
17:04karolherbst: now integrating it into mesa will be fun
17:05karolherbst: dcbaker[m]: is there something I can pull/base on where we have basic rust integration in mesa?
17:05karolherbst: I am sure wiring up nir will be annoying, but I am planning to just see how we can integrate into the pipe loader stuff
17:05karolherbst: and gallium
17:08dcbaker[m]: That's probably an anholt question. From meson all your really need is to add rust to the languages in the project() function, and compile the rust code as a separate static_library, then link it into whatever
17:08karolherbst: what about crate support?
17:08karolherbst: only caring about bindgen atm
17:13belarien: Even with interrupts to program the interrupt handler , none mandates you have to go to the kernel, how can ones simply do not understand that, microcontrollers like microchip ones, which very big producer of such, they do not have kernel you see?
17:24belarien: anyways where you get such ringbuffers, all GPUs have two or more of those, which can access cpu memory IOHUB directly, you can use one of those 1.
17:25belarien: then consult with or inspect intel iohub documentation
17:25belarien: if they have more of such on their chipsets directly , many of those circular buffers are outlined in the docs.
17:25belarien: very many options really
17:27dcbaker[m]: I'm still working on that, there's on la branch on my github, I think it's called wip/2020-10/cargo-module you can try. It still can't build ever crate, but I've been able to build some real crates
17:28dcbaker[m]: Notably it can't handle crateb dependency recursion yet
17:28belarien: it can go all the time on the full throughput, and if all memory which in case of compressing the memory also, the chip will be basically couple of millions years timetraveling in front of us
17:28karolherbst: dcbaker[m]: the annoying bit of the bindgen crate is that it more or less depends on that top level build.rs file from cargo as you essentially write your tool generating the files :/ and I guess that could be annoying to integrate as well
17:28belarien: cause we can not process the data what it does.
17:29belarien: if everything is full it will discard and erase and fall back to the past
17:29dcbaker[m]: Yeah... Right now I have no plan for build.rs except write a meson.build.
17:30dcbaker[m]: I was sorta punting on that until I ran into a case we needed it
17:30dcbaker[m]: Guess I found that case
17:31karolherbst: I mean.. build.rs is just a binary you link deps to
17:31karolherbst: so maybe we can do something similiar as with the other code generators we have
17:32karolherbst: but yeah.. my next step would be to wire up the gallium API to create screens/contexts etc..
17:32karolherbst: as far as writing the CL implementation in rust goes
17:33dcbaker[m]: The problem with crates, and build.rs in particular, is getting all of the dependencies right so that ninja digress the right thing
17:33dcbaker[m]: There's also meson's guarantee that you can select the c complier per machine and meson won't use another one
17:34dcbaker[m]: I haven't looked into it yet to see if that's possible with build.rs
17:34belarien: And PLL wise both amd and intel will give access to some ranges half duty cycle clock, and quarter ones, to implement basically just double pumped alus i.e that corresponds to async clock which is always processing
17:35dcbaker[m]: I may just maintain a meson.build for bindgen
17:35belarien: they just do not want to get access doing something stupid with their PLL easily in hw
17:35belarien: however this code is of course still available for FPGAs, almost full PLL is implemented and bookmarked.
17:35belarien: for me as well.
17:37belarien: since on nouveu PLL does not function this is basically a big win like i have been telling for performance and power save
17:37belarien: since the clock comes directly from IOhub they just have higher voltages around , they amplify 100mhz clock to 135.
17:37belarien: since their voltage lines are higher.
17:38belarien: you can easily from IOhub drive any kind of clock to the circuit without this power hungry PLL there
17:40belarien: PLL itself of course in musical instruments and uranium enrichments , many many areas where such things is really used, but compute equipment never needs it.
17:40belarien: like performance based computing chips.
17:52karolherbst: dcbaker[m]: from what I understand about build.rs is, that it's just a normal rust program you write with different dependencies and ran with some env variable ABI
17:53karolherbst: atm the only I use is OUT_DIR
17:53karolherbst: and I guess it somehow knows about the project dir as it just picks up the header file I wrote
17:53karolherbst: _but_ bindgen does use clang for generating the stuff
17:53belarien: And as i told, i was bout to become a major champion and i saw as teenager how terror was the most paranoid one landed against me, i am still very disgusted about this, cause i lost most the performance and talent, even though i am still good player in my event only this exclusively, but i am alive, many ran this against me, but the bad thing is 10years it was paranoidically performed by my own dad, who probably was terrorised by someone bigger .
17:54karolherbst: dcbaker[m]: https://gitlab.freedesktop.org/karolherbst/rustcl/-/blob/master/build.rs
17:54belarien: very perverse 100percent crackup calculations they landed, so i'd be in that situation where i am at.
17:54karolherbst: other bindgens also want to link against system libs, but in our case we can just skip it (for CL)
17:54karolherbst: probably not with gallium
17:55karolherbst: or maybe we can
17:55karolherbst: it throws out some *.rs file I include in my project: https://gitlab.freedesktop.org/karolherbst/rustcl/-/blob/master/src/api/bindings.rs
17:55karolherbst: last line
17:56belarien: so i am safe in that regard, even with a cracked up cutthrough body and hand also, i still know if i land a punch with full force, you wont get up anymore.
17:56dcbaker[m]: From what I've seen the most common use of build.rs is to compile a vendored c library
17:56karolherbst: ahh, yeah, saw that as well
17:57belarien: but currently there is torturing tech. contest allready going, for the next 25 years i respond with save evilness.
17:57karolherbst: this part we really don't need :)
17:57belarien: i finance exectly the same stuff, what they did to me, personally from my own wallet.
17:59dcbaker[m]: I'll have to look at bindgen on Monday and see what we'd need to make it work
17:59belarien: and this is not about karma, god gave me everything, humans took most though
18:00belarien: karma never still hits me, i am totally immune to accidents
18:00karolherbst: dcbaker[m]: cool thanks! Kind of not looking forward doing all the binding stuff ourselves :D
18:04belarien: and i am still saying all the opencl that you work at has been done before you in open source form as well, it can work ontop of opengl hw beautifully
18:05belarien: there are accurate compiler kits which do everything needed, smaug was chosen by me, but there are many others.
18:06belarien: it has documentation small but accurate one for smaug, how to add alus to the compiler, and llvm-tracer and gem-aladdin interaction and very short code too.
18:07belarien: youll be placing this transformation the untrained models to tvm or handing it to them from x86 LLVM IR, it does everything with the webgpu backend from there.
18:07dcbaker[m]: Lol, yeah. For sure.
18:07belarien: it can lift it to compute shaders or fragment shader, vulkan or opengl or anything
18:07belarien: and opencl2.0 is supported too
18:07belarien: that happens in the clang3.6 frontend
18:11linkmauve: karolherbst, you could depend on the `bindgen` command and use it from meson, instead of relying on build.rs.
18:12karolherbst: linkmauve: mhhh, that might be a choice
18:12linkmauve: Distributions already package it mostly: https://repology.org/project/rust:bindgen/versions
18:14karolherbst: ohh cool
18:14dcbaker[m]: I think that's probably what we really want to do, is use the binary. Especially if we can use a distro provided one for ci, but fallback to subprojects when necessary
18:14karolherbst: ehh rawhide only :/ oh well
18:14karolherbst: but yeah.. I think that might be good enough
18:15karolherbst: passing arguments can be messy but maybe that works as well
19:05karolherbst: dcbaker[m]: yeah.. the tools seems to be good enough. And you don't even need distribution packages. "cargo install bindgen" installs into ~/.cargo/bin
19:06karolherbst: at least it has all the args I care about :)
19:06karolherbst: okay.. nice. let's get this integrated into mesa then :D
19:07karolherbst: but now I really need a good name :D
19:08dcbaker[m]: We have to have a solution that works for distros though it doesn't do is any good to build something no one ships :)
19:16karolherbst: yeah.. I guess some will dislike installing binaries via cargo
19:25CounterPillow: Is this the correct channel to ask as to how one would go about bisecting mesa? Having the currently being tested version installed in some prefix and then launching the application with LD_LIBRARY_PATH set to the prefix's lib and LIBGL_DRIVERS_PATH set to the lib/dri/ dir just results in segfaults as the application loads something not from the prefix.
19:30kisak: personally, I'm lazy and run git bisect on a copy of mesa on a separate system and use portage to build on the test box without needing to deal with any of that non-system-installed mesa dance
19:31kisak: but for me, worse case scenario, I still have ssh access to rebuild mesa to a known good state
19:36CounterPillow: I guess I'll try using my distro's mesa build config, maybe it tried loading something from the system mesa because I built without something it wanted.
19:39karolherbst: dcbaker[m]: how can I force a cdylib?
19:40karolherbst: the error is when I create the shared lib and link the static rust ib in
19:40dcbaker[m]: I think there's a rust_crate_type argument
19:40karolherbst: ahh, indeed
19:42karolherbst: that wasn't the part going wrong though
19:43karolherbst: ohh wait
19:43karolherbst: the rlib is empty :D
19:48karolherbst: dcbaker[m]: okay.. so I have the static gallium frontend being a staticlib, and then I want to have this shared_library think using this in link_whole, but I get those linker errors: https://gist.github.com/karolherbst/25fd21e23ff548a899981c5940634702
19:48karolherbst: and I kind of hope the magic deps will get added automatically :d
19:50karolherbst: anyway, "dependencies : [dep_thread, dep_dl]," fixes it
19:52karolherbst: anyway, it works :)
19:53airlied: karolherbst: most distros build in non-internet connected builders, so cargo isn't an option
19:53karolherbst: but it's good enough for development :D
19:53karolherbst: and I doubt anybody would be crazy enough to enable it this year
19:53airlied: so one of the rules for mesa will be no cargo
19:53karolherbst: or next year
19:59CounterPillow: aaand it still segfaults, urgh
20:08robclark: ajax: btw, 63a6b719d98fb1ad58ae93c2de859e6d4bfa8b8b seems to make GLX_MESA_multithread_makecurrent disappear.. (I only noticed because I was looking for multithread tests, and piglit has a few that depend on that ext)
20:10CounterPillow: Ah I see, needed to build a libva in my prefix too
20:10karolherbst: dcbaker[m]: is there something special I need to deal with for the "use" syntax?
20:14dcbaker[m]: karolherbst: I'm not sure. You can look in the meson rust test cases
20:14karolherbst: ohh, good idea
20:14dcbaker[m]:is not at a computer
20:16karolherbst: ohh hum.. mhhh
20:16karolherbst: oh well, wished that wouldn't be messy but here we go
20:19karolherbst: now to deal with OUT_DIR or so ..
20:19karolherbst: let's see
20:28Vanfanel: The VkDisplaySurfaceCreateInfoKHR member called planeIndex, is it supposed to be a drm plane "plane_id"?
20:32karolherbst: dcbaker[m], airlied: this time built with meson inside mesa: https://gist.github.com/karolherbst/d7a43cd1f5f83b977e38b975e9a7a3af
20:33karolherbst: ahh.. need to change the name
20:34karolherbst: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/418a696900948e0937bdba9dedb377025b51ed31 :)
20:34karolherbst: there are two ugly things..
20:34karolherbst: custom_target dep and the include
20:36karolherbst: also.. should probably use our own headers
20:38dcbaker[m]: I'm not sure, but bindgen might actually be a good place for a generator. Either that or something else to put in the meson rust module I'm writing
20:39karolherbst: I think this will help a lot
20:39karolherbst: it's not hard to use.. just.. annoying
20:39karolherbst: see the custom_target
20:41karolherbst: dcbaker[m]: any idea on how to pass env variables into a target?
20:41karolherbst: what I need is to pass the path to the generated rs file into the static_lib target so rustc picks it up
20:42karolherbst: dcbaker[m]: also, we might want to be able to pin the edition if meson can't do it yet
20:43dcbaker[m]: 0.57 will have edition support, that landed already
20:45karolherbst: yeah.. I need run_command.env but for static_lib :/
21:00dcbaker[m]: Ninja doesn't allow env
21:00dcbaker[m]: Well have to wrap it
21:01karolherbst: any other idea on how we could deal with it?
21:02karolherbst: this is also a bit ugly :/ oh well https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/aff5b4b8076418bc805d4223334c96c795abb914
21:02karolherbst: at least it works
21:03karolherbst: now figuring out why the librusticl doesn't depend on rusticl_opencl_bindings_rs
22:39karolherbst: dcbaker[m]: ehh... not even relative paths work
22:51karolherbst: the custom_target + dependency stuff simply doesn't work :/
22:52karolherbst: so, rusticl_opencl_bindings_rs is not generated automatically
22:59dcbaker[m]: I'll add it to my list of things to look at Monday
23:36karolherbst: airlied: the biggest issue with OpenCL in rust is, that the runtime has to manage a couple of objects and rust just makes that super hard :/
23:37karolherbst: now I have to deal with devices
23:53Vanfanel: Hi! Is it somehow possible to use a drmModeModeInfo as VkDisplayModeKHR? Or what's the relation between them?
23:56airlied: not they aren't the same atall
23:57Vanfanel: airlied: ok, ok.