01:15 darinobyk: I am starting to realize what American education is about. It's ahead of our ones. And i realize why there are rank and min max operations always on tree based access. One of such interesting tree is Van Emde Boas and there is not much better ones available. They are talking about fusion trees that are faster to access, but space efficiency should be the same. They have this lecture on MIT
01:15 darinobyk: opencourseware on youtube. If the data is ordered and contiguous i.e sorted contiguously it's possible to access them with less of overhead. So it's space vs latency of access tradeoff. I now tried with 4 elements to show how this works, and it works so as to how i started to suspect, it's bit logical. You have to compensate for values in a set that are larger only on values side of things
01:15 darinobyk: by throwing in their delta to be subtracted. the indexes are anyways bigger and this hardly matters. I now have the filesystem layout in the works. You have to think very deep and consistent to understand why that works this way however but as said there is logic behind it.
02:42 darinobyk: so let's say that sums up everything to ingraduate state. So the latest algorithm was not working, however the index buffer trick and data uniforming for index buffer, does a huge magic, so the filesystem works so, that there is index address space which is way smaller than the data, so millions of numbers can be stored as data into one memory location of 32bit type which represent logical
02:42 darinobyk: format of the full 32bit value compacted and they are unordered. however the address bank is taken from a formula as boratfromkz said or showcased and this is ordered uniformly by adding contiguous values to the data that represent the sum of all data in one reg. And the filesystem never plays any tricks with duplicates or reordering anything, it netiher does anything about defragmenting
02:42 darinobyk: things, tehcnically it uses a binary buddy allocator first present in windows95 but in modern state. If something gets released it gets one a closest available block location for ram, and hdd driver is bit different. But graphitemaster was speaking about Mill CPU lol, that would not need any ram. technically. pagetables i would not use at all. Mill cpu has never been released by Ivan, and
02:42 darinobyk: they likely shut him off/down or he decided that he's brain is worth more and started to fill his own wallet like i intend to do instead of educating others and helping everyone out.
05:21 michalkraft: it seems you have some smart people here, well yeah boratfromkz does not work indeed, however it seems you know as to how Van Emde Boas trees work and all the like. So there is two versions i have that is very well adjustable to hashsums, there is no innovation but they seem to function well. One version is where you subtract delta of all bigger values in the set and another version is
05:21 michalkraft: where only max is subtracted and min is there to know where the set ends. I have not really found where min is needed, i think that would use a different algorithm. However there is a catch on my side of the works that i tested. Mainly if the data value is odd integer, it needs to add one to the result, however to decode those compact values they need a certain uniform pattern for data
05:21 michalkraft: too, so you end up either always adding one or not adding depending if all values are odd or even.
05:32 michalkraft: the reason as to why you do not implement those trees for upstream stack is what i do not know why deeply. But you seem to understand them, those are very powerful and i can if needed recap or represent those flows, as they work well in my calculator all other approaches have indeed failed for data.
06:36 malcolmhendry: so ok we take three values of the set 1. 70 2. 72 3. 73 you see 73 does not divide with two. so in order 426.00−883+1024=567-512=55+26-9=72 412.00−888+1024=548-512=36+26=62+8=72 406.00−894+1024=536-512=24+26=50+22is 72 , now the last since it's odd/uneven data it needs +1. now how -9 and 8 and 22 come from is slightly bigger talk, or do you know this too :) ? another version is only
06:36 malcolmhendry: about deltas like this 888−136−16−604=132 since the smaller value is -16 and -26 it subtracts them i.e they have bigger inverse. for an example 883-141-604=138.00 894−130−26−16−4-604=114 so you do 130-114=16 130+16=146 aka double of 73 similarly 136-132=4 136+4=140 double of 72 and 141-138=3 141+3=144 double of 72. Shall we proceed with how the top of the algorithm values to add to max
06:36 malcolmhendry: come from (it's more powerful hence faster and storage efficient), you see they only use maximum as delta, and one in place value derivable per 883, 888 and 894?
06:55 malcolmhendry: so we continue first as with the more powerful faster and space efficient version, now 883-26-26-768=63 same as 115-26-26=89-26=63 128-63=65 and 141-65=76, so to speak and 26+26+(78-63=15)+67 and 67-76=-9 all others work out the same logic, but have different sign.
06:57 malcolmhendry: now there is also a way to break those double values without going for a division for a backup solution, but so far all versions of modifications to Van Emde Boas seem to work. it's just the catch is only for max addend version, always +1 to the odd values.
06:58 malcolmhendry: remember that those algorithms are extremely powerful, it's possible to compress data as well as compute in compressed format.
07:01 malcolmhendry: I am not aware of estonians doing this in universities, but yes, Stanford , Cambridge Universities deal with such code. but have no code repositories, so i code this my own, but i definitely believe they have everything set up somewhere in private.
07:07 malcolmhendry: i wonder if IRCv3 would display also mathml?
07:11 malcolmhendry: drivers i also have smarter versions, i wrote only mouse driver , but with very fast performance, without any api overhead, but i have ideas for hard drive new drivers too as well as gpu cpu and all that stuff, we already talked about.
07:12 malcolmhendry: but i take a small nap as of now, cause i need to play today 13:15, so I am away for some time, you may post questions
07:12 malcolmhendry: i respond to them later.
07:32 malcolmhendry: the things or codebases that map well for doing some magic stuff, is neo4j wasmati and scala that have implementation of asm as well as code property graphs, but i think this time i am going with wasmati since that is thinner as well as free from patents. I have slowly but steadily gotten my computers to function well.
10:05 stsquad: could a kernel change have broken this: vkr: vkAllocateMemory resulted in CS error
10:10 digetx: stsquad: very unlikely
10:11 stsquad: digetx: how can I trace where the failure is coming from?
10:17 digetx: set env VIRGL_LOG_LEVEL=info on host, run guest app with strace to see which ioctl fails
10:23 stsquad: digetx: in the guest I just see a bunch of DRM_IOCTL_VIRTGPU_EXECBUFFERs and then GEM_CLOSE
10:24 stsquad: http://paste.debian.net/1337418
10:24 stsquad: digetx: ^ thats on the host side
10:24 stsquad: vulkaninfo --summary shows to VirtIO-GPU Venus - one Intel one LLVM
10:25 stsquad: but vkmark can't find a suitable Vulkan device - I'm confused about the VK_KHR_wayland_surface extension though, that doesn't appear in the list in virglrenderer
10:30 digetx: you should have same vk extensions as on x86 guest
10:52 stsquad: digetx the host vulkaninfo certainly doesn't match the guest one
10:53 stsquad:checks his x86 guest
10:55 stsquad: huh
10:55 stsquad: ok vkmark is running ok on the x86 guest
11:07 digetx: host shouldn't match
11:21 ManMower: mripard: I'm having some trouble with HDMI. my test machine can set an hdr metadata (drm) infoframe, but then it is forever stuck in HDR display mode. I can't find the path that should clear the infoframe. I've tried adding infoframe->set = false; at the top of hdmi_generate_hdr_infoframe() and that makes things happen, but I'm wondering if a) is that the right thing to do, and b) would any of the
11:21 ManMower: other infoframes need the same thing?
11:31 stsquad: digetx: hmm I'm wondering if the trixie virlgrenderer build is just missing venus?
11:33 digetx: trixie shouldn't have venus, afaict; maybe sid has it
12:20 stsquad: digetx I got mjt to update it a week or so ago. But maybe it was just the version bump
12:21 stsquad: https://tracker.debian.org/pkg/virglrenderer
12:24 stsquad: should be built
12:24 stsquad: ifneq (armel, ${DEB_HOST_ARCH})
12:24 stsquad: # vulkan requires 32bit atomic ints, armel lacks one (#1021861)
12:24 stsquad: configure-opts += \
12:24 stsquad: -Drender-server=true \
12:24 stsquad: -Drender-server-worker=process \
12:24 stsquad: -Dvenus=true
12:24 stsquad: endif
14:27 alyssa: mareko: u_blitter seems to be leaking framebuffers on context destroy. Is this a known bug / affecting all drivers?
14:34 stsquad: digetx: it looks like in some cases it just silently fails to exec virglrenderer
14:34 stsquad: proxy: proxy server with pid 1383963proxy: failed to exec /usr/libexec/virgl_render_server: No such file or directory--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=1383963, si_uid=1000, si_status=SIGSEGV, si_utime=0, si_stime=0}
14:44 alyssa: apparently not all drivers affected, that's good I guess
14:58 digetx: stsquad: do you have that server file?
15:01 digetx: my local virglrenderer is built with -Drender-server-worker=thread, not sure I ever checked the process mode with QEMU
15:03 digetx: it indeed works with x86 guest, never tried arm
15:03 digetx: in general, it should work on arm with no issues
15:05 digetx: mean haven't tried arm with process, with thread it worked
15:06 digetx: everything should be the same as few weeks ago when you tested venus with amd card and intel igpu
15:06 stsquad: digetx: the above was fixed by installing virgl-server - still fails to start vkmark though
15:07 stsquad: digetx: now I'm testing against the packages in trixie
15:07 stsquad: digetx: and with the current HEAD of the kernel with kvm/next merged
15:07 eric_engestrom: mareko: I'm afraid I can't help you with the traces job because 1) I'm barely familiar with the traces tests, 2) that one is running on crosvm, which adds two layers of complexity I'm not familiar with, and 3) I don't have any time left this year, I'm about to be offline in a couple of hours until january :]
15:07 stsquad: so trying to work out what has broken
15:07 digetx: should work as before
15:08 eric_engestrom: mareko: my advice would be to ask daniels who'll probably either know the answer or know who to ask
15:11 stsquad: digetx: should being the operative word... the problem is when things break its not immediately obvious where the breakage may be. things seem fragile
15:13 digetx: that is a common theme with graphics virtualization :) it will improve over time as more stuff is upstreamed and stabilized
15:15 digetx: is it still failing with vkAllocateMemory?
15:19 digetx: I'll try to reproduce if you won't fix it
16:49 llyyr: does anyone have any ideas for https://gitlab.freedesktop.org/mesa/mesa/-/issues/12198 ? it currently breaks users of VK_KHR_display on any system with llvmpipe present
16:50 llyyr: in the past GetPhysicalDeviceSurfaceSupportKHR would just say llvmpipe doesn't support the surface and the client would move on, but now it segfaults
16:51 stsquad: digetx: certainly with my arm test image on trixie with -device virtio-gpu-gl-pci,hostmem=4G,blob=on,venus=on vkmark doesn't see any valid devices, even though vulkaninfo does while complaining about VK_KHR_wayland_surface failing
16:52 stsquad: digetx: what are you running on your host?
16:52 stsquad:is running his trixie through toolbox, but host vkmark works fine so the dri node is visible
17:21 digetx: my hosts are fedora, gentoo and archlinux
17:22 digetx: if you running vkmark with wayland and wayland doesn't work properly, it well explain why there no device found
17:23 digetx: you have checked both wl and x11, have you?
20:13 banderasamigo: I specifically learned as to how to explain better. But still i am continuing to do more tests, I do have new specification to execution side or era.
20:14 banderasamigo: but i won't be explaining this anymore, since i use the time to write code instead.
22:24 cwabbott: for vulkan RT, is it supposed to happen that when a closest hit shader traces a ray, all of the information about the original intersection (ray origin & direction, hit kind, etc. etc.) is clobbered and overwritten with the new intersection?
22:24 cwabbott: that seems to be what intel is doing, but I'm not sure what the justification is
22:24 cwabbott: or if I'm missing some pass somewhere that pulls all these intrinsics to to the top
22:41 kindteddy: was ray tracing in same basket with global illumination and such methods, i studied it but can not remember very well? Jensen Huang video i just saw (intelligent man), he says you define one pixel and ray tracing and ai could imagine 7 of them to the mix.
22:44 kindteddy: I also looked at video of the cm5 rpi5 it hosts pcie3.0 this time and usb3.0 than also btw. Has anyone tested this module for the pcie lanes stability?
22:54 dj-death: cwabbott: it's not overwritten on intel
22:55 dj-death: cwabbott: there is 2 different structure, one for the setup, the other for the hit info
22:57 kindteddy: Well tsmc is building a massive manufacturing appliance to Arizona, i remember once i spoke to a MIT scientist or lecturer over e-mail about the source code of Scent which i got downloaded with his help, he was building chips through carbon nanotube methods, and americans are tricky there, they developed simulation specification that could derive all the technology, sort of like they have a
22:57 kindteddy: little bit tap on on taiwanese. But they sell software to some of the ASML machines also through some silicon valley quite successful company.
22:58 dj-death: cwabbott: any idea when you'll be able to merge the common framework stuff?
23:04 mareko: eric_engestrom: understood
23:04 mareko: I wonder if daniels is on vacation :)
23:24 daniels: mareko: not on holiday but a bit underwater - I had a quick look and I think I know how to fix it but it’ll take a couple of days before I can get to it - if it’s in your way please just kill those traces for now and assign an issue to me to fix
23:26 kindteddy: nowdays I have not looked at new innovations, but there used to be like three years ago, two very performant transistor based technologies, 3d finfet that of intel, and utbb FD-SOI from chinese and taiwanese inventions at tmsc, those are much on bar with eachother, for an example ericsson labs had all the curves from the evolution as to how they perform and behave. I am trying to transpile
23:26 kindteddy: some java code to c/c++ , since I am fine with scala not mostly java due to google case with the patents. Then i am in the middle of larger sets testing soon too, but so far whatever i threw at my calculator it offered the expected results with success. However in the tutorial or short explanation of mine 's#+76#=76#g' I spotted.
23:28 kindteddy: err tsmc
23:32 kindteddy: macbook's sandy bridge is performant but it's not low power version, so i have Icelake low power processor too, but alibaba sent me a wrong sink for the thinkpad, without tools and overall i were not able to find the connector to be reverse engineered, three wires vs. 3 thinkpad yoga 260 vs 370
23:41 kindteddy: fpc and jumper alike connectors , i find no info about their compatibility or no info at all 4 vs 3 or 5 vs 4 wires, i can not even remember.
23:47 kindteddy: chatGPT is my friend on howto deal with apple parts, since screws were cracked we had hard time to get those out, but succeeded finally and ordered new ones with 10bucks with delivery overnight included, i am spending my last 100 bucks soon to get all computers i own to work.