08:23markus_wanner: Hi, on wayland, is there a way to list attached displays from the CLI? Or where does Gnome Display get its information from?
08:46pmoreau: markus_wanner: Hello, you could try `grep . /sys/class/drm/card*-*/status`.
09:13markus_wanner: pmoreau: Thanks, that's what I'm already checking, but it gives me just a connected/disconnected status. No vendor info or anything.
09:13markus_wanner: Is it i2c that's used to get possible resolution and other such vendor info?
09:15pmoreau: You can try `grep . /sys/class/drm/card*-*/modes` to ge the resolutions
09:17pmoreau: And `grep . /sys/class/drm/card*-*/device/device/vendor` will give you the PCI? ID of the vendor; 10de is NVIDIA, nor sure about Intel and AMD.
09:18pmoreau: There might be a better way to get all that information, but at least it is exposed through various files under /sys/class/drm/card*-*.
09:18pmoreau: markus_wanner: -^
09:34markus_wanner: pmoreau: ah, I overlooked `modes`, that seems to be about the display, indeed. card-*-*/device links back to the GPU device, not the display.
11:18pmoreau: markus_wanner: Oh, you wanted the vendor of the screen, not of the card, got it. No idea how to get the screen’s vendor.
11:31mivanov: :imirkin :karolherbst Hello again, we've talked before about Vertical sync with Nouveau on GK104(Kepler NVE0)
11:32mivanov: I've wanted to ask why did you recommend me to use the Nouveau DDX instead of the Generic Modesetting DDX?
11:32mivanov: I've read some threads stating that most DDX will be deprecated in favor of the Modesetting DDX with Glamor
11:35mivanov: By the way with the Nouveau DDX(intel disabled, just the Nvidia card), if I disconnect my monitors and reconnect them again, I get a deadzone, meaning I can't put any window there. And mirroring becomes gray in the Display utilities.
11:36karolherbst: mivanov: the nouveau ddx is generally lower overhead (but this is the case for most ddx compared to modesetting), higher power efficiency and doesn't use GL, which causes less issues overall
11:36mivanov: Doesn't the modesetting also use GL via Glamor or am I mistaken
11:37mivanov: Modesetting DDX without Glamor is slow
11:37karolherbst: sure, but you have a high API overhead
11:37karolherbst: and a driver ddx can call into a driver directly to do stuff
11:37mivanov: Actually I don't use any GL applications, so do I really need 3D acceleration at all
11:38karolherbst: well, most GUI applications are using GL these days
11:38karolherbst: even if it's only hidden inside Qt5 or gtk3
11:39mivanov: I am actually forwarding framebuffers from Virtual machines, so it's not like I am rendering anything via the GPU
11:39mivanov: So I don't get it why videos feel slower without Glamor
11:39mivanov: The Virtual machines doing the actual rendering don't have GPUs
11:40karolherbst: mivanov: because modesettings software paths are just super slow
11:40mivanov: So imagine that the X server is just receiving frames via a shared memory. I just want those frames to be displayed in sync.
11:40mivanov: I see
11:40mivanov: So what about Intel, how come the modesetting DDX works so well for Intel
11:41mivanov: Most distros even stopped delivering the i915 DDX
11:45karolherbst: mivanov: mhh, for me the intel ddx works better than modesetting
11:46karolherbst: but generally intel cares more about the modesetting ddx
11:46karolherbst: there are just random issues you can't really solve because you deal with OpenGL
11:46karolherbst: or how glamor handles buffers
11:46karolherbst: scrolling in chromium at 4k res is super painful with glamor
11:48mivanov: Don't know I get very snappy interface with 2x1920x1080 with Intel modesetting and Glamor. No tearing in videos either. I am using Cinnamon which has a built-in compositor
11:48karolherbst: but the biggest issue with glamor and nouveau is glamors memory usage... especially on older cards with less memory you can get to the point where gl memory allocations are failing...
11:48mivanov: Hm, I doubt that's an issue with K4100M, it has 4G
11:48karolherbst: mivanov: it's not about tearing, but eg in chromium when I scroll parts need to rerendered
11:48karolherbst: *to be
11:48karolherbst: which doesn't happen with the intel ddx
11:48mivanov: are you sure it's not the compositor fault?
11:49karolherbst: so the scrolled in content appears blank for a while
11:49karolherbst: mivanov: well, it happens with modesetting, doesn't happen with the intel ddx
11:49mivanov: but what about modesetting plus compositor
11:49mivanov: I can't understand yet, but sometimes compositors fix the strangest of errors.
11:49karolherbst: well, then it's a workaround a bug the ddx doesn't want to fix
11:49karolherbst: which is equally bad
11:50mivanov: Like nothing is working, you move windows and they leave trails, screen is not refreshing. Then you run a compositor and it works.
11:50karolherbst: well, that's just X
11:50karolherbst: or even modesetting indeed
11:50mivanov: I experiencied this so many times. Tried so many compositors with both nouveau and intel. In the end it feels like pure magic and I can't make any sense out of it.
11:50karolherbst: glamor kind of requires a compositor
11:50karolherbst: and for X you want a compositor anyway
11:51karolherbst: anyway, with the intel ddx I have less issues than with the modesetting one
11:51mivanov: So, how does tearing relate to compositors in general? Some compositors have a Vsync option, sometimes even enabling the compositor without Vsync fixes the tearing.
11:51karolherbst: because you have multiple surfaces
11:51mivanov: Also most of the time tearing increases with the higher resolution
11:51karolherbst: and something has to sync up displaying/updating each
11:52mivanov: Sometimes I manage to not have tearing in 1280x1024 but when it gets above 1920x1080 tearing gets very bad
11:52mivanov: As for i915, even without a Compositor with TearFree "true" it's okay
11:53mivanov: How come even with Prime without synchronization Intel manages to be Tear free?
11:53karolherbst: yeah.. that's kind of workarounding how stupid X is inside the ddx
11:53karolherbst: because they hard sync inside the kernel driver
11:53karolherbst: which... causes other issues
11:53mivanov: But what about Prime? I've read a Paper stating that without enabling the PRIME Synchronization via xrandr you will get tearing.
11:53karolherbst: like bad displaying performance
11:54karolherbst: mivanov: well, I don't know about the details, but usually things get changed later on and most of that isn't caused by the architecture or can be workaround in different places
11:54karolherbst: anyway, X sucks in this regard from every point of view
11:55karolherbst: can't have a superior solution to fix all the issues :/
11:55karolherbst: because you just cause others
11:55mivanov: Actually there's one other thing I do not understand about Prime, say you have 2 GPUs, Intel and Nvidia. Nvidia has 2 heads, Intel has 2 heads. Why do you need PRIME for this to work? Can't X just run with two GPUs. I thought Prime was for headless cards.
11:55mivanov: I have such configuration and I don't get it why I need PRIME.
11:56karolherbst: mivanov: because you want to display stuff on both GPUs at the same time
11:57mivanov: I read many X docs about Randr and Xinerama, some Prime stuff too. But nowhere did it said that modern Xorg can't run on 2 GPUs.
11:57karolherbst: eg if you run an OpenGL application, it has to run accelerated on one GPU and display on the other
11:57karolherbst: so you need to pass buffers around
11:57karolherbst: xinerama has no acceleration
11:57karolherbst: and is a crappy solution overall
11:58karolherbst: and reverse prime is the solution inside X to make it all work on 2 GPUs
11:58mivanov: But I do not need to do acceleration on one GPU and show result on other. I just want to have one screen that is combined from all my monitors. And for Xorg to run with 2 GPUs.
11:58mivanov: Isn't PRIME useful only when you want to offload all work to 1 GPU?
11:59mivanov: Do you generally need prime to run X on many GPUs and have one big continous screen?
12:00mivanov: But now everytime I write a Xorg conf, the first GPU becomes master and the second one uses PRIME to get buffers from it.
12:00mivanov: I.e one becomes source and two becomes sink
12:05pmoreau: karolherbst: I can try out the patch, but I don’t think my laptop is actually using _DSM: it’s using a hardware multiplexer controlled by the apple_gmux driver,
12:07karolherbst: pmoreau: ohh, true
12:08karolherbst: mivanov: if you have displays on 2 GPUs you run into the issue that one applications is rendered on a different GPU than it's displayed on
12:08karolherbst: mivanov: you can't get around this
12:09karolherbst: imagine a qt5 application, and qt5 uses some acceleration for displaying or glamor does, doesn't matter, point is one of the GPU is doing the rendering
12:09karolherbst: now you move one window of that application from one display to the other
12:10karolherbst: and the displays are driven by different GPUs
12:10karolherbst: so what do you do?
12:11karolherbst: mivanov: anyway, especially for this we have reverse prime and you won't need any xorg.conf file to set this up
12:11karolherbst: just let xrandr do it's magic
12:13karolherbst: also, think about the sitautions where the window is still on both displays
12:16mivanov: So when did PRIME appear? I remember having 2 GPUs with multimonitors and dragging a window on both displays and having it work many years ago
12:16karolherbst: uhh, quite a long time ago
12:17mivanov: I thought that RANDR took care of this and not Prime.
12:17karolherbst: mivanov: also keep in mind that xinerama was quite old, but it had serious drawbacks
12:17mivanov: And I thought that RANDR replaced Xinerama
12:17karolherbst: randr can only do this with the help of prime
12:17karolherbst: prime is a kernel feature
12:18mivanov: but isn't Prime a relatively new feature?
12:18mivanov: I remember in 2013, nvidia used bumblebee
12:18karolherbst: nvidia still doesn't implement prime
12:18karolherbst: but that's not primes fault, but nvidias
12:18mivanov: How so, I read that it does actually
12:19karolherbst: it does in a crappy way
12:19karolherbst: either you render everything on nvidia or you can't use it
12:19karolherbst: which makes it pointless on laptops
12:19mivanov: Hm, so what about the Nouveau prime
12:19mivanov: Doesn't it render everything on the Primary GPU
12:19karolherbst: well, we only render what you want on the nvidia gpu and if there is no active consumer, the gpu can be turned off
12:20mivanov: But how do I choose what do I want to render on it?
12:20karolherbst: the DRI_PRIME env variable is the main thing, but there is also driconf and some desktop environnments have some context menu thing to select it
12:21mivanov: And what of the case with the multimonitors
12:21mivanov: basically plugging a monitor both into the nvidia and the intel graphics
12:21mivanov: who renders the window if you do that?
12:21mivanov: when dragging the window for example
12:22mivanov: I thought that PRIME used the Primary GPU for everything and pushed some buffers to screens connected to the secondary GPU
12:23karolherbst: usually the main one
12:23mivanov: So when PRIME Synchronization is disabled you get tearing
12:23mivanov: how does DRI_PRIME relate to that?
12:24mivanov: And to PRIME Synchronization?
12:24mivanov: So to simplify: if you had a Desktop with many GPUS would you still use Prime?
12:24mivanov: Say having for example 3 nvidia cards
12:26karolherbst: there is no other reasonable way
12:27mivanov: So for multi gpu it's either PRIME or Xinerama?
12:28mivanov: I guess the Arch wiki made me confused: "PRIME is a technology used to manage hybrid graphics found on recent laptops"
12:33cyberpear: mivanov: you'll likely find that any laptop w/ a dedicated GPU has to do either PRIME or reverse-PRIME, because any given output is generally only connected to either the dedicated GPU or the integrated one
12:35mivanov: cyberpear: why do people use the terms PRIME and reverse PRIME? Is it about which GPU is primary? Reverse meaning integrated is primary and feeds buffers to discrete. And Prime meaning making the discrete gpu primary and feeding buffers to integrated?
12:36mivanov: or are both of those cases Reverse PRIME?
12:36cyberpear: mivanov: it's about rendering the image one one GPU then copying it to the other for output to a display
12:36mivanov: cyberpear: If rendering on one GPU and passing to the other for output is Reverse PRIME, then what is just PRIME?
12:37cyberpear: I think the distinction is about which GPU is considered "Primary"
12:38cyberpear: PRIME came first, where the display is hooked to the integrated GPU, but you wanted to offload to the dedicated GPU
12:38mivanov: So wouldn't that just make dedicated GPU primary?
12:38cyberpear: then reverse PRIME came later, where the display is connected to the dedicated GPU, but you want to render on the integrated GPU but output to a display hooked to the dedicated GPU
12:39cyberpear: you'd want reverse-prime for power-saving reasons, and PRIME for graphical performance reasons
12:39mivanov: and what if I want to render on the dedicated GPU and and output to it
12:39cyberpear: mivanov: that's a case of neither prime nor reverse prime; it's the simple case of a single GPU
12:39mivanov: Say for example I have intel and nvidia cards, both have outputs connected to different monitors.
12:40mivanov: But what if I have 2 GPUs, both with their outputs connected to different monitors.
12:40cyberpear: you'll likely find that the laptop display is hardwired to the integrated GPU, so you have to do PRIME to display images rendered by the dedicated GPU on the laptop screen
12:40mivanov: But is it true that I need Prime if I don't want to offload?
12:40cyberpear: I don't think prime plays in there at all, but I could be wrong as that's beyond my understanding
12:41mivanov: Say a desktop with 2 nvidia cards
12:41mivanov: Do I still need Prime? Each card has it's own monitor, but I want to have one big screen where I can move windows between monitors
12:41cyberpear: I don't think you'd use prime in that case, if you had one display hooked to each card
12:41cyberpear: (anyone please jump in if I'm wrong)
12:42mivanov: karolherbst mentioned that for any multimonitoring via 2 different GPUs, I need either Prime or Xinerama
12:43cyberpear: it's beyond my understanding
12:43mivanov: I am experimenting with a laptop with an Intel + Nvidia. Both have their own outputs. Without any configuration => Intel is primary. If I connect a monitor to some of the Nvidia outputs, the Nvidia is started and listed as a secondary(it has prime attributes in Xrandr)
12:44mivanov: I can swap it around if I make a xorg.conf and list the Nvidia GPU as the first GPU and the Intel as the second one.
12:44mivanov: Of course since the laptop display is connected to the Intel GPU, it can't get turned off.
12:45mivanov: But Prime is always listed in xrandr for the inputs connected to the second GPU
12:46mivanov: It's like Xorg always uses just one GPU and if you have extra monitors on another GPU, it will start another Xorg for the second GPU and forward windows to it via that.
12:46mivanov: It's even more confusing because most of the time it works out of the box without a config.
12:47mivanov: And that makes it that much harder to learn what is happening or if there are alternatives.
12:54karolherbst: mivanov: ohh, that's easy, there are no alternatives
12:59mivanov: by the way, about another issue I have. I've tried a docking station and the displayports don't want to go above 1lane x 540 MB. Is that related to Nouveau
13:00mivanov: strange thing is if I don't go through the Dock and plug a monitor into the laptop's displayport I get 5 lane x 540 MB(full bandwidth)
13:00mivanov: Same K4100M(GK104) card
13:00mivanov: No thunderbolt, just a standard Dock
13:09mivanov: Link training just won't do more than 1 lane of 540 MB via Dock
13:09karolherbst: maybe an updated kernel might help
13:09karolherbst: Lyude was fixing quite a lot in this regard
13:09imirkin: Kepler has DP 1.2
13:09imirkin: which means you don't get more than 540*MHz* per lane
13:09mivanov: Yep, and via Laptop directly it works fine. But if I use the Dock, no more than 1 lane
13:10mivanov: But there should be 4 lanes
13:10imirkin: chances are it's a DP dock
13:10mivanov: and via Dock I only get 1 lane
13:10mivanov: I did disassemble the Dock
13:10imirkin: er, i mean 5.4Gbit/s i guess
13:10mivanov: The board schematics says it has Displayport 1.2 connectors
13:10imirkin: each lane is a separate physical group of pins
13:11imirkin: is it a DP-MST dock?
13:11mivanov: But sometimes I could get a high res monitor to work by doing the following: plug it into the laptop
13:11mivanov: and then really fast replug into dock
13:11mivanov: I don't think it's using MST
13:12mivanov: But the fact that I could trick it to work by replugging fast would mean that the problem is with the training phase?
13:13imirkin: most likely
13:14mivanov: Strange thing is that even in full hd this monitor wants 2x540mb. The dock has two displayports. The other port however has an option to run with intel or nvidia. When running with intel, the other dp dock port allows up to 1920x1080
13:14mivanov: but not above
13:14mivanov: if I set both dock ports to use the nvidia, I can't even get 1920x1080
13:14mivanov: but either way I can't go above 1920x1080
13:15mivanov: The Dock board clearly states it has Displayport 1.2
14:56kreyren: is separate project that introduces vulkan to nouveau that is written in rust mergable in nouveau?
14:57kreyren: there would probably have to be some changes done to nouveau to accept it tho
15:00imirkin_: kreyren: "mergeable"? meaning what? where would it be merged?
15:00kreyren: like if it would be accepted in nouveau project so that it would be maintained
15:00imirkin_: i don't think anyone here is interested in rust
15:01imirkin_: but i could be wrong
15:01kreyren: why not? it's faster then C* afaik
15:01imirkin_: it would present a lot of overhead for basically no reason
15:01imirkin_: (development overhead)
15:01imirkin_: it would also prevent the tried-and-true way of developing vulkan drivers
15:01imirkin_: step 1: copy anv
15:01imirkin_: step 2: replace some functions
15:02imirkin_: however this is all secondary to the primary issue -- first the kernel support needs to be figured out
15:02imirkin_: anv is the intel vulkan driver
15:02imirkin_: vk has an enormous amount of boilerplate
15:03kreyren: well but we don't have anything better to vulkan atm
15:03karolherbst: although we already abstracted the most annoying bits away
15:03karolherbst: like the dispatcher and the wsi stuff
15:03imirkin_: exactly. and rust would be a huge redo.
15:03imirkin_: for ... no reason
15:03imirkin_: kreyren: in C, you can reuse (a) the stuff everyone else is doing and (b) the khronos-supplied headers
15:04karolherbst: isn't b actualy generated by python scripts?
15:04imirkin_: maybe, maybe not. good luck validating.
15:04karolherbst: and for a you can do the stuff in C you want to reuse and just mix and match... that should be possible with rust and C, no?
15:04imirkin_: maybe. something else that Just Works (tm) -- C :)
15:05imirkin_: look, the driver part isn't the hard part here
15:05kreyren: relevant: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html dunno seems reasonable to me to use rust for vulkan support assuming that it would have positive effect on performance
15:05imirkin_: the hard part is changing the kernel to support the functionality that vk requires
15:05imirkin_: you can make one in each language you know and 3 you don't in the time that the kernel changes will take.
15:06imirkin_: the other hard part is the shader compiler. good luck reimplementing that.
15:06kreyren: can't we grab that from AMDGPU?
15:06imirkin_: sure, as long as we run it on AMD gpu's
15:06imirkin_: (there's already a shader compiler ... just not in rust)
15:08kreyren: why not using the original then with compatibility to accept instructions from rust?
15:08imirkin_: why not use C?
15:08kreyren: slow, boring >.>
15:08imirkin_: C is the definition of fast, esp for this stuff.
15:09imirkin_: unpacking and repacking data.
15:09imirkin_: bit manipulations
15:09kreyren: rust can do that afaik
15:09imirkin_: it all compiles quite simply to CPU
15:09imirkin_: of course rust can do that
15:09imirkin_: but it can't do it better than C
15:09kreyren: check the benchmark made by debian provided
15:10imirkin_: this appears to be benchmarks of cpu-heavy things
15:10imirkin_: the vk driver is cpu-light
15:10imirkin_: multi-cpu stuff, etc
15:10imirkin_: this is not that use-case.
15:11kreyren: afaik rust is also faster on cpu-light iiuc
15:12kreyren: if so would it be accepted?
15:12HdkR: Aside from arguments about performance I think the bigger issue is development overhead for everyone else that doesn't care about rust
15:13HdkR: Unnecessary burden for bringing in the newest shiny
15:15karolherbst: anyway, rust isn't faster as C, but that's not even the point of rust
15:15karolherbst: and benchmars wich claim otherwise have crappy code
15:16kreyren: can you prove otherwise or provide scenario in which it it's not fast?
15:16karolherbst: I am not saying it's slow
15:17karolherbst: rust and C are similiar fast, though C is generally a bit faster
15:17kreyren: i'm saying that it's faster then C based on available info..
15:17karolherbst: and a bit means <5%
15:17karolherbst: it's all totally irrelevant
15:17kreyren: yep it's around <5% but thats astill a lot tho ;-;
15:17karolherbst: kreyren: the benchmark you posted is biased
15:17karolherbst: that's always failing
15:18kreyren: they are made by debian.. doubt
15:20kreyren: relevant also http://cantrip.org/rust-vs-c++.html
15:22kreyren: and there are two active devs in nouveau anyway so it would probably encourage other ppl to contribute
15:23HdkR: Maintaining a project with multiple languages in use is such a headache :/
15:23kreyren: slowly recode it in rust then? :p
15:23HdkR: Try and convince the entire mesa project with that
15:24karolherbst: my internet connection today is also the best.... not
15:24HdkR: You end up with having to define your internal APIs on both sides of the C++ and Rust boundary, which ends up being problematic and prone to breaking
15:25karolherbst: kreyren: it's biased: "and there are 4 tests whre rust is faster, 5 where gcc c is"
15:25HdkR: additionally you get a hard dependency on LLVM as a compiler, which means if you try mixing GCC/LLVM object files then there is a high chance of something breaking.
15:25karolherbst: but only rust is ever marked as being faster
15:25karolherbst: that's means being biased
15:25HdkR: (Oh hi LTO)
15:26karolherbst: anyway, switching over to rust won't mean more developers anyway
15:26karolherbst: coding is the smallest part of deveoping a driver anyway
15:26kreyren: still wierd that there aren't many devs here tho
15:27HdkR: Nvidia is doing a very good job killing motivation
15:27kreyren: i'm just waiting for the dead fish to appear with reason
15:27HdkR: I don't get the phrase
15:28imirkin_: switching to $language-of-the-week could mean new developers interested in the project solely because of that reason
15:28imirkin_: however i suspect that interest will fade
15:28imirkin_: a handful of gpu driver developers are bullish on rust (iirc at least anholt liked it?)
15:28imirkin_: however the majority of the community is fairly happy with C
15:29imirkin_: a big part of the reason that there aren't more developers contributing to nouveau is that it's hard work, and those developers can get an actual paid job doing something similar but for amd/intel drivers
15:29orbea: switching to rust would be a major pain in the ass to compile the drivers...compiling rust itself is a horrible experience
15:29kreyren: is there even a possibility that nvidia will be faster then AMD on linux tho?
15:30kreyren: why? because of the hardware limitation?
15:30imirkin_: for anything starting with the GTX 9xx series, the fact that nvidia will never release signed firmware which enables us to reclock
15:31imirkin_: no reclock = joke performance
15:31kreyren: assuming nouveau beeing in it's gold condition?
15:31imirkin_: it's like saying "will intel ever be faster than AMD if you lock the intel chip to its lowest perf setting"
15:31kreyren: meaning everything working on sanitized code etc..
15:32HdkR: You could have perfect codegen, if you're running at 1/20th maximum clocks then you're not going anywhere fast.
15:33kreyren: assuming that we have fully functional nouveau with all required functions ?
15:33kreyren: since RX Vega 64 is 114% of GTX1080ti on linux in native linux games
15:33HdkR: With which driver stack?
15:33imirkin_: for all the shit we dump on nvidia, the nvidia blob drivers are actually quite good
15:34imirkin_: they have much better codegen than we do
15:34kreyren: HdkR, don't remember i made the tests 4 months ago and said system is not at my current residence
15:34imirkin_: they've probably sunk 10000x the manpower into it, so it seems like a reasonable result though
15:35kreyren: and we can get even more performance by using DXVK/dxv9 in directX apps on linux so.. If not then probably just open-source raytracing for RTX2060 is sane
15:36HdkR: Don't even have basic Turing support and you're already thinking about making an RT stack?
15:37kreyren: yep :p
15:37kreyren: since graphic support is not needed assuming that performance would be provided by AMDGPU (well for my usecase)
15:37HdkR: Make RT fast in compute first, then maybe in a few years once Turing support comes up you'll be able to accelerate it
15:39HdkR: Or just use the Nvidia stack where they've spent a decade working on making RT fast on GPUs
15:39kreyren: yes that is always an alternative, but nvidia drivers sucks in general >.>
15:40karolherbst: kreyren: well, they get hired by other companies like AMD/Intel/Valve, so a lot of nouveau developers are working on other stuff now
15:41karolherbst: kreyren: also, you have a big misconception about rust. It's just makes it easier for developers to now mess up, but at some level it doesn't really matter as you can always cause security issues. With rust you just trade one group of issues with another one in the end
15:41karolherbst: and what you get with rust is even worse
15:41imirkin_: the issues that cause slowness, btw, have nothing to do with CPU
15:41imirkin_: in general they have to do with poor management of buffers between GPU and CPU, unnecessary synchronization points, etc
15:42imirkin_: this is the stuff that causes 99% of the slow. maybe the 1% is cpu overhead. which you can use rust to reduce down to 0.95% in theory? woo hoo?
15:42karolherbst: intel synchronizes a lot :/
15:42kreyren: any proof of rust beeing less effective that i can verify on my end?
15:42karolherbst: I even have cases where games running at around 50 fps, but the window redraws at 20 because of something intel does
15:42karolherbst: kreyren: any proof it's more effective?
15:43imirkin_: kreyren: absolutely none. just not interested in the language. the fact that it takes down my system every time gentoo wants to build a new version of rust certainly doesn't enhance my perception of it.
15:43karolherbst: imirkin_: you should "nice" and cgroup portage :p
15:43imirkin_: and that it's like a 1GB download
15:43imirkin_: karolherbst: if only i'd thought of that...
15:43imirkin_: maybe cgroup is the way
15:43imirkin_: i definitely nice it
15:43imirkin_: but i have 6GB of ram at home
15:44karolherbst: I can compile chromium/libreoffice while having 0 impact on games
15:44kreyren: imirkin_, it never took my gentoo down o.o
15:44kreyren: karolherbst, will do some research since my current research is not valid
15:44imirkin_: [and i generally run without swap]
15:44imirkin_: karolherbst: yeah, on my work computer, with 32GB of ram it's a lot more practical
15:44karolherbst: imirkin_: mhh, I have 32GB of ram :/
15:44kreyren: or use exherbo where paludis is not that vulnerable to overload on system resources :p
15:44karolherbst: but I also compile inside zram
15:45imirkin_: you sure have a lot of cpu to spare.
15:45karolherbst: so no IO except reading system headers/libraries
15:45kreyren: well it probably is tho ;-;
15:45imirkin_: i have a piddly little i7-920
15:45karolherbst: imirkin_: meh.. the overhead isn't all that big
15:45karolherbst: imirkin_: it's faster than doing IO
15:45imirkin_: probably true.
15:45karolherbst: i7-6820HK here...
15:46karolherbst: anyway, works out quite nice overall
15:47karolherbst: mhh, my portage zram device is 16GB big... probably because of libreoffice or something
15:48karolherbst: yeah.. libreoffice requires like 12GB to build
15:53kreyren: or you can also do it like me :p https://i.imgur.com/kjzmp7D.png
16:03karolherbst: kreyren: anyway, the biggest problem I see with rust is this "cargo culting" of dependencies where your application is repsonsible of updating all deps.. and "serious business enterprise software" is already showing us how hard this fails
16:03karolherbst: and I kind of don't see how dependency management is in better hands if software engineers have to take care of it instead of distributions
16:03imirkin_: the non-hermetic aspect of all this new stuff frightens me immensely too
16:19kreyren: karolherbst: serious business enterprice software?
22:29imirkin_: skeggsb: need anything from me for the 1024-sized lut thing?