我对kde唯一需求是它自带color profile服务，而我一直想用的sway对这个color profile的支持有点问题
其实我要是换个好点的显示器，我直接用sway了。i3/sway/aerospace这样的tiling window manager好用太多
1 个赞
除了打游戏以外，macos都能很好地满足你的需求 
1 个赞
Wayland本身支持就不好，zoom在wayland上个月又出现无法分享屏幕的问题，还有skype等也是。
1 个赞
对，平时用用wayland session还可以，一定在系统里enable一个x11 session,这样前者坏了还可以fall back到后者去修理
No Apple No Google No Microsoft No Nvidia please.
我知道不可能避免这四家的互联网基础设施，但是直接和我打交道的部分打灭。
1 个赞
最后决定把4070S退了，买了张二手amd instinct，大概率是矿卡但是无所谓了。
本地跑跑模型，消耗品而已，坏了就扔掉买新的。
你用7950x3d玩哪些日呆游戏
cpu当然不是玩日呆游戏用的。
nvidia驱动现在做SR-IOV虚拟显卡方便么？无知买了A卡现在只能passthrough
我听说GBM不是必须的，implicit sync才是首锅，然后我在那独立思考了一会儿2024年怎么会发生这种事情。
开始的时候我还在想，现代图形API不就是讲究一个驱动那边干的越少越好，尽量让应用那边能控制的多，以前啥都是驱动管这管那，你觉得驱动有问题抱怨也就算了，为什么今天越来越自由了还在整天抱怨驱动呢？再不济，CUDA总能用吧？不然也别谈啥机器学习了。那用它写个软光栅总可以吧，又不是没人写过，不求你做成UE5 Nanite那样战胜硬光栅，至少给GUI用总还是够的吧。
由于实在独立思考不出来，我就查了一下到底是啥有问题…………implicit sync？这不应该十年前就被DX12/Metal/Vulkan这新一代图形API集体抛弃了吗？再一细看，发现比我想象中的反人类一百倍。
首先我们回顾下历史，OpenGL是个彻头彻尾反人类的东西，从很早很早，早到我还一行代码都不会写的年份就停止进步被DirectX完爆了。由于是全方位被爆，它的缺陷属于罄竹难书那种的，让我们跳过Direct State Access这种脸都不要了的东西（反正我整出这种烂活来过了N年才回来擦个屁股是不好意思管它叫feature的），直接进入synchronization问题。
我们想象这么一个世界，在那里操作系统课直接把线程相关的东西全给删了，什么lock semaphore fence统统不教。程序员们写出来的程序都是不带synchronization的，全都甩给kernel和CPU驱动（假装有这么一个背锅的东西）决定怎么并行化，由它们来看汇编猜谁和谁有依赖关系，猜不明白要么瞎搞（这就是所谓的驱动bug），要么管你是啥统统按timestamp先来后到序列化，多核自己歇着去吧。不难想象，这种先把手捆住再意念操控的玩法会导致堆出来一坨到处都是bug的屎山。
这个世界是不是很恐怖？更恐怖的是这个世界里面的程序员不但没意识到有问题，还在那整天高谈阔论什么自由啊什么开源啊什么底层啊什么效率啊之类的听不懂的玩意，觉得没人比自己更懂汇编。
上面这个就是现实世界，只不过CPU要换成GPU，那坨屎山就是上一代图形API背后驱动干的事情，而且驱动不止要干这些脏活各种麻烦事多了去了。这就是为什么驱动质量那么重要，更新驱动能产生那么大影响，为什么有的东西N卡换A卡就炸了（反之亦然）。
Wayland诞生在2008年，那个时候已经距离我前面提到的DirectX完全胜利过去了好多年了。因为DirectX完全胜利很多年了，所以游戏不入Linux也有很多年了，还停留在Linux的开发者大概也看不上早年游戏开发者们突破旧时代图形API缺陷进行过的斗争，反正既然Linux世界里面只有OpenGL，那OpenGL就是最好的，Wayland把gl改成wl弄个画风差不多的东西就得了。
没想到5年后天翻地覆，人们终于开窍了：让驱动来猜游戏开发者想干什么这个事本质上就是反人类的，没有人比开发者自己更清楚自己在干什么。那好了，什么管线状态内存管理同步机制，这些驱动都不用管了，统统交给开发者自己解决就行了。驱动简化了，bug少了，开发者自由度提高了，简直是赢了又赢——所以现在有了渲染第一个三角形要写1000行代码的鬼故事，但至少我们自由了（这个真是褒义的，现在能渲染很多以前不敢想的东西）
既然这一代图形API就是为了explicit sync，那正确的驱动当然就应该把Vulkan实现成这个样子……Wayland怎么办？如果异步操作没有正确的同步鬼知道会发生什么事情。
我不知道发生了什么，为什么现在比较做人的OpenGL驱动都是通过翻译成DX12/Vulkan这种方式来进行了，Vulkan的specification是公开的，好像不需要GPU厂商那边配合干什么，但Wayland那边就不能在Vulkan基础上让它们的API行为正确。反正结果就是往地上一趟，等着GPU厂商来擦屁股，不来擦的就开骂，毕竟社区人多声音大。Intel和AMD过来擦屁股了，NV没有，那我们就骂NV不开源。但这事和开源有关系吗？
Intel和AMD并没有解决这个问题，并不存在什么开源了所以社区神奇地解决了这个问题。现在看起来没事是因为在不为人知的角落里有人在负重前行，苦一苦正确使用Vulkan的开发者，那不会用的起码能正常跑起来。我直接复制粘贴了：
The RADV driver currently tracks when each window-system buffer is acquired by the client and only enables implicit synchronization for window-system buffers and only when owned by the client. Thanks to details of the amdgpu kernel driver, enabling implicit synchronization doesn’t actually cause the client to synchronize with itself when doing work on multiple queues. However, because of our inability to accurately track when a buffer is in use, this strategy leads to over-synchronization if the client acquires multiple images from the swapchain and is working on them simultaneously. There’s no way for us to separate which work is targeting which image and only make the
vkQueuePresentKHR()wait on the work for the one image.In ANV (the Intel driver), we get hints from the window-system code and flag the window-system buffer as written by the dummy submit done as part of
vkQueueSubmit()and consider it to be read by everything that waits on the semaphore fromvkAcquireNextImageKHR(). This strategy works well for GPU ↔ GPU synchronization but we run into problems when implementingvkWaitForFences()for the fence fromvkAcquireNextImageKHR(). That has to be done viaDRM_IOCTL_I915_GEM_WAITwhich can’t tell the difference between the compositor’s work and work which has since been submitted by the client. If you callvkWaitForFences()on such a fence after submitting any client work, it basically ends up being avkDeviceWaitIdle()which isn’t at all what you want.
理论上我对这个完全不应该感到惊讶，毕竟这是Linus社区的老传统的——就是Linus，这位几十年学不会pointer provenance，一问就开始嘴臭骂C++，那没办法，只能委屈大家一起关掉strict-aliasing了。Wayland这事不过是历史重演——第一次很滑稽，第二次更滑稽。
但我还是很震惊，里面提到的那些vk开头的API不是什么稀有的玩意，很多都是我学Vulkan API第一周开始就需要用的，必不可少的东西，这些东西的行为都能和specification不一致整点惊喜出来也太吓人了。
同样，正如早年Linux社区孜孜不倦论证为什么epoll比iocp先进，直到io_uring出来后口风集体180度反转一样，类似的事情又发生了——在骂了N卡很多年不来擦屁股，孜孜不倦论证为什么Vulkan的specification就在khronos.org摆着人人都能看到但对就是错错就是对NV就是要来遵守我们社区的潜规则后，Wayland终于也要提供explicit sync的API了……就像Android从一开始就做对的一样——Android没事不是因为N卡跟移动端没关系，而是因为人家开始就把API设计成explicit sync了。
5 个赞
Implicit Sync这个问题确实是自己乱搞，OpenGL也终于被扫进历史垃圾堆了。
虽然Mesa，叹气……
但是这种事情，你NVDA一开始wayland开工的时候就说这样干我们没法配合不就行了吗……
Wayland开工的时候你黄仁勋不来说，干了一半了说你们这样我们不会配合的，搞什么啊。
而且GBM确实是一个问题，只是现在被解决了而已。
我其实没理解为什么这个事情需要NV那边配合。如果Vulkan实现有问题那肯定是NV的问题，但现在好像不是这样。
考虑到OpenGL的实现可以通过翻译成Vulkan/DX12的方式进行，而且工作得挺好的，类似的d3d11on12不说好不好用起码能用，我一直以为这是个特别成熟的技术，不知道Wayland那边障碍具体在什么地方……
根据我的理解，其实implicit sync是一个容易解决的问题，虽然被拖到今年才解决。
GBM vs EGLStreams是一个更加原则性的问题，这个问题不解决所以社区没有推进其他的动力。
EGLStreams肯定是不如GBM的，性能和兼容性都不如，但是nvidia喜欢。
而且NVDA不直接说，它直接没去开会。
我觉得你的各种观点都，非常，pro-megacorps，你既然不喜欢corporate America，那何必呢。
虽然你的批评都是正确的，但是GBM问题真的是一个更大的前置性的问题，肯定是NVDA那头的。
第一反应：好骂
第二反应：这个strict-aliasing是啥我去看看
看完以后：
-
卡马克那个上古神仙优化不是就是abuse的这玩意儿吗？hacker社区不喜欢这个rule好像没问题？
-
Compiler在内存地址级别完全不需要这个规则来保证优化啊，这个规则明显是单纯为了简化compiler制定的。C时代机器慢为了简化编译器制定这种规则无可厚非，现在还守着这种规则有点rust式的不要脸了
不过抛开这个这个技术问题的细节不谈，Linux kernel社区核心一直就是一帮mafia啊，bully明尼苏达大学的那事儿记忆犹新
MI多少？25，50还是100？
蹲一个使用实战，前两天有点想搞个MI100玩玩没下的去手。
等等，UMN faculty往linux内核投毒还不把人开了，被人bully一下就成mafia了？
MI60 32G，MI100有点贵了。
1 个赞
蹲个评测，我之前用过一段时间的mi25但这卡表现相当奇怪，大部分时候都work，但是玩某些东西，比如说SD出图的最后一步，的时候会非常慢就像换到CPU上跑一样。不知道这是GCN通病还是啥原因，反正我用rdna1/2的游戏卡没碰到过类似的问题，就是游戏卡每次都要过一遍像是JIT compilation的过程很烦。
不过32G显存真的香，这么一想又想下手MI100了
1 个赞
如果只是想本地跑跑llama，32G是真的比什么都重要。
别的，不打3A游戏真的也就无所谓了，3A也有GeForce Now。
第一没投毒，在内核社区approve之后就主动撤回patch了，内核代码没有处在受到真实威胁的状态下过
第二bully那次跟“投毒”根本没关系，就是kernel mafia记仇觉得上次没怼爽，找个借口硬上去踩脸
什么叫没有受到真实威胁……
就是个犯罪中止的赛博恐怖分子罢了，你还要洗地，良心在哪里啊？
UMN既然没开除Kangjie Lu还给了tenure，我支持linux “mafia”在他离开UMN之前霸凌UMN到底。
退一万步讲，这种实验能过IRB exempt，UMN就该负责。