当我宣布在我之前的帖子中,X-Plane 11.50 以本地 Vulkan 和金属驱动程序支持为特色,是由我们的开发人员组成的私人测试版 (E. g. 第三方开发者)。我们从他们那里得到了一些非常好的错误报告 -- 报告是好的,而不是错误 -- 基于此, 很明显,11.50 今年 (意味着明天) 不会上市。

这让我们很失望 -- 我们在两端都烧了蜡烛,试图在今年一路进入公共测试,但是在这一点上,建筑还没有准备好。

我将在下面详细描述真正阻碍公共测试版的一个错误,明天我将尝试做一个关于 Vulkan 和 Metal 的常见问题解答; 基于上一篇文章的 150 多条评论,我认为很明显,我们有很多基本信息要传达,其中一些直到最近才与第三方开发人员共享。

请不要用 “我可以进入私人测试版吗” 来轰炸我 (或者甚至 “你因为不让我进入私人测试版而成为一大群驼鹿”)。关于私人测试版的事情是这样的: 我们的目标是杀死错误,这样每个人都可以使用测试版,并尽可能快地杀死它们。

在这一点上,十几个正在使用测试版的第三方开发人员生成错误报告的速度比西德尼和我修复它们的速度快 -- 如果我们在测试版中增加更多的人, 我们的错误修复速度将会变慢,因为我们不得不花更多的时间来对即将到来的报告进行分类。因此,只要我们有效地修复了最糟糕的漏洞,更多的人进入私人测试版意味着每个人都要等待更长时间才能进入公共测试版。我认为对西德尼和我来说,最好的事情就是尽快解决问题。

(我认为将它交到第三方开发人员手中也是一种胜利 -- 在某些情况下,我们已经看到插件意外地使用了错误的 api 进行处理,因此不兼容使用 Vulkan 时,他们不需要-开发人员可以得到更新此代码的开端。如果你是第三方开发者,我们可以让你进入测试程序 -- 我不想让一些第三方开发者偏爱其他人。

模糊纹理

我们内部测试版的性能反馈的简短总结可能是这样的: 平滑度和 FPS 是好的,VRAM 管理不是。

我们所看到的飞行中的大多数崩溃看起来像是 sim 耗尽了 VRAM 并且无法恢复,对于使用较小 gpu (例如 4 GB VRAM) 的用户来说 x-Plane 进入一个紧张的 VRAM 情况,并通过使屏幕上的一切低分辨率和模糊来解决它。

VRAM 管理路径是为 Vulkan/Metal 后端编写的全新代码,是…… 嗯,它是全新的,需要一系列测试, 调试和迭代以获得稳定。在 8gb 卡上,VRAM 是如此丰富,以至于 X-Plane 有点天真的 VRAM 分配方案工作正常。在 4gb 卡上,我们只是有点短 (几百 MB),但结果是纹理分辨率的惊人损失。

这是我们可以做得更好的东西!它在我们的控制之下,因此现在正在进行。(西德尼写这篇博客,而他在这里完成了真正的工作。)但是,在我们有更好的 VRAM 管理之前,现在上市还为时过早。如果我们这样做了,我们只会被数百份 “我的纹理模糊不清” 的报告淹没。它太吵了,无法运输bob电竞官网。

为什么这不是 OpenGL 上的问题?

有人可能会问: 你为什么不做任何事情来管理 VRAM 呢?问题是: OpenGL 的解决方案是口吃。

OpenGL 驱动程序根据您现在真正需要绘制的内容,在 VRAM 和系统内存之间交换纹理。如果你把目光从西雅图移开,太空针塔的纹理可以存在于系统内存中,但是你可能需要雷尼尔的山地纹理。

我们也尝试这样做-最大的区别是:停止渲染当它移动纹理时,我们不会。其结果是,OpenGL 总是显示您所选择的纹理分辨率的完美图像-没有模糊的图像。但是你可能会口吃!如果你在 VRAM 的边缘,通过飞行,然后改变视图或在相机周围盘旋,你可以看到这一点 -- 如果你的 FPS 去 “块 VROOOM”,你吃了一些口吃,而纹理四处移动, 然后你又跑得很快。

OpenGL 的方式是一个我们从未想过可以接受的解决方案 -- 我们的目标是最好的图像质量没有牺牲平滑。解决低 VRAM 的情况需要更多的时间,但是一旦我们到了那里,我认为这是值得的。

关于本 · 苏普尼克

本是一名在 X-Plane 工作的软件工程师; 他大部分时间都在喝咖啡和对着电脑破口大骂 -- 有时是同时。

116 关于“Vulkan/Metal 公共测试版将于 2020年

  1. 谢谢你这么坦诚,本。祝西德尼和你自己在测试版中推出这一革命性版本的努力好运。
    感谢层流公司的所有人,祝他们新年快乐

  2. 本,你们都做得很好。总会有一些人尖叫着抱怨着贝塔和释放,抱怨着空中交通管制和水等等,但是这些人通常是第一个跳槽的人对于没有深度的闪光产品。X 飞机一直是更好的,它的重要性和我们谁知道层流和真正喜欢飞行一个伟大的团队开发的一个伟大的 sim卡不介意耐心等待更好的产品,并赢得了。不要让你陷入不切实际的期望或截止日期。这对 XP 来说是一个巨大的变化,我们明白了。当我告诉你我们感谢你们所有人的辛勤工作时,我知道我代表了普通消费者/瘾君子, 漫长的夜晚和吃力不讨好的时间在网上灭火,同时创造了我玩过的最伟大的消费者飞行模拟器。继续,新年快乐!

    1. 这些评论我也是!我认为 X 飞机可能是我在飞行模拟器中运行过的最有价值的飞机。

  3. 本,我完全同意之前的帖子。你只能把午夜的油烧这么长时间,所以休息一下,喝杯啤酒,看一些蒙提 · 派森的剪辑。你 (复数) 错过了你自称的死线,这是一个令人沮丧但没什么大不了的。这是最重要的最终结果,我们都知道这将是非常棒的。
    感谢所有的辛勤工作,祝你和团队其他成员新年快乐。

    1. + 1 正是我要发布的内容。
      你为新年而努力,但现在给自己一个机会。
      一旦你在代码中找到了你的心理书签,你可能会发现一段时间的离开实际上是有帮助的。

      1. + 1 尤其是有蒙提 · 派森剪辑和啤酒的那个
        但是现在完全不同了。慢慢来。该产品现在运行良好。它只能更好。祝大家新年快乐!

  4. 一如既往的干得好。最好有一个光滑的产品,而不是把它扔出门外。我们都已经等了足够长的时间,那么等待那一点点时间来得到抛光版本的问题是什么,而不是一个半散列版本的错误,让每个人都失望。

    1. 我希望我们将有 4gb 与公共测试版一起工作。但是为了更稳定,你可以随时关闭 Vulkan 驱动程序,并在测试期间返回 GL。

      而且… 见鬼,是的,你可以一直坐在测试版外面,如果你不是第三方开发人员,你可以等待最终结果。

  5. 驼鹿便便。

    我笑了。

    伟大的更新,我非常乐意等待我知道的时候,这样你们就可以确保你们已经尽了最大努力。继续伟大的工作!

  6. 在这个阶段是否有任何共享的信息关于 CPU 工作负载的分布比较 OpenGL 和 Vulkan?会非常有趣。

    非常感谢所做的巨大工作。

    1. 它在 Vulkan 上的 CPU 工作量较少。:-)。西德尼,我手头没有详细的数字,但我记得:
      -NV 和 AMD 的驱动开销非常相似。
      -AMD 和 NV 的驱动开销都低于 NV Windows OpenGL 驱动,这是我们以前访问过的最快的驱动。
      在 Mac 上,从我们所知道的情况来看,对金属的绘制调用需要大约 1/10 个 OpenGL 的 CPU。

      1. 哇……
        用不同的方式阅读它,这就像给第三方开发者更多的中央处理器电池来构建 x 平面之上, 像天气广告一样..等等… 每个人最终都是赢家..

          1. 如果您注意到在 opengl 下使用 xplane 时的 CPU 利用率,则有一个内核被充分利用,它具有主线程,

            通过说 “更多的攻击” -- 我的意思是主线应该减少对主题核心的压力/负担,将其归因于新的更轻的 vulkan driver 开销, 从而留下更多的空间来利用其他任务的主要核心线程。

            查看这些视频以获得更bob电竞app安全吗好的想法..
            https://www.youtube.com/watch?v=Nt4Q7eqtrNA
            https://www.youtube.com/watch?v=SBhJSsBmWL8

  7. 别担心,最好慢慢安全地走。批评家将永远在那里,更重要的是匆忙做事。
    祝整个团队新年快乐。

  8. 感谢您的开放风格更新!我想痛苦在于细节,就像经常发生的那样。你关注的是 graphicscard 的使用。你能稍微了解一下这个测试版的 CPU 的使用情况,特别是多核的使用情况吗?

  9. 谢谢你的更新本。

    冷静点,冷静点,抽出一些时间 & 为 2020 的团队尽最大努力。

  10. 你好,我看了关于推迟发布 X-plane 11.50 beta 1 的新闻。发布至少一个工作中的 beta 1 是一件很棒的事情,没有简介和 vram 问题。这也可能是一个营销问题,因为 fs2020 预计将于 3 月发布。无论如何,在基于另一个 opengl 图形引擎的模拟器上改变图形库并不容易,你有毁掉一个出色软件的风险。无论如何看 YouTube 视频,这并不坏,但它有很高的反差。不管怎样,aerofly fs2 也用同样的模拟器传给了 vulkan 蜜蜂。我不得不说 top top 和 top。祝你在奥斯汀和你所有的员工过得愉快,新年快乐。bob电竞app安全吗

  11. 感谢所有的辛勤工作。自从我开始使用 Xplane 9 以来,Xplane 已经取得了很大的进步,这仅仅是因为你和像你这样的人投入了大量的工作来不断地让它变得更好。

  12. 首先,我祝你有一个非常好的一年,我总是想感谢你所有的团队所做的工作,但是我认为不发布测试版是一个错误,下载者知道他们可能有问题,并对此负责,发布这个 “B” 可以从用户和更多小型开发人员那里收集更多信息。但是我也能理解你的决定,正如我之前所说的,我祝你和你的家人度过一段美好的时光

    1. 如果经验向我们展示了一件事,那就是批次下载测试版的用户中,有一部分不相信自己注册了一些可能会使他们的安装无法用于娱乐飞行的东西。

      我们可以添加一系列确认-“您确定要测试版吗?你真的,真的确定吗?它可能是错误的!你确定吗? ”-- 但是在一天结束的时候,有些人会下载它来获得最新最棒的功能…… 然后生气 (比如,“ 1 星评论 ”生气) 当它被严重破坏时。

      1. 是的,这是一个可悲的现实!这就是为什么我也理解今天不发布测试版的决定

      2. 这就是为什么我使用一个大的 (2 TB) SSHD,并保留一份非 beta 版的好副本和两份 beta 版的好副本 (a 和 b)。这样,我就可以跳过 betas,如果有一个好的,然后是一个不好的,我仍然在飞行。如果所有其他方法都失败了,我仍然有我的非测试版。如果每个人都意识到贝塔就是这样,并做好准备,就不会有问题。感谢您对细节的关注,但我仍然期待有问题,并感谢您与我们分享经验。

        1. 这是个好主意 (有两份)。我只希望在安装之间分享全球风景很容易…… 只要没有重复数据消除文件系统。

        2. 我有一个大的 2tb 固态硬盘,只专用于 X-Plane, 由于我的 x-plane 目前是 1.83 Tb,我没有空间安装两个 (Beta 和非 Beta)

      3. 嗯,也许公共贝塔不会 “被可怕地破坏”。我自己测试每个测试版,我真的经常被一些琐碎的错误所困扰,这些错误永远不会传递给公共测试版。令人惊讶的是,其中一些 (相同!),一次又一次地传递。外部视觉同步有多少次出现问题?;-p 也经常通过修复一个错误,你打破了已经在工作的东西。所以请不要着急,而不是半烤测试版投入更多适当的自动化测试。尤其是现在,当很多代码被更改时。谢谢。

        1. 哇 -- 这是我在 2020年读到的最讨厌的东西,甚至可能在 2019年。

  13. 感谢您的评论和灵感!
    我对你创造力的所有尊重。
    跟上伟大的工作人员!

    2020年新年快乐!

    Lknfly

  14. 我知道人们希望测试版尽快上线,尤其是 Vulkan,但这无疑是第3 方开发者在公众面前访问测试版的良好做法。

    1. 我真的希望答案是否定的!

      OpenGL 规范对性能相当模糊 -- 你要求驱动程序绘制,规范很清楚:
      1.将画什么。
      2.它将在未来的某一天被绘制出来,不会花费很长时间。
      3.驱动程序不允许给你的机器打蓝屏,在某些情况下也不允许使你的应用程序崩溃。
      它没有提到什么是快什么是慢 -- 一切都是 “尽力而为”,像我这样的开发人员可以尝试阅读茶叶来猜测是什么让事情变得更好。

      所以在这种情况下,英伟达做了一个选择,他们试图将 CPU 工作从驱动程序中分离出来,变成一个额外的线程。这是一场赌博。
      -如果应用程序是大规模的单线程绑定在渲染器上,就像 X 平面一样,这可能是一个巨大的胜利!并行性。绿色团队!
      -如果应用程序已经为 FFT water 、 AI 飞机和风景加载安排了所有内核 (如 X-Plane) 的工作,然后 NV 开始尝试使用这些内核, 我们将超负荷的 CPU 和一切调度变得非常糟糕,你得到 4 fps。

      Vulkan 的目标是可预测的可靠性能: 一切都可以是多核的 (驱动程序内部没有锁),但所有的多核都取决于应用程序。这样,应用程序可以使用整个 CPU,但不会过载。

      所以在 Vulkan 中没有地方可以选择 “你来处理它” -- 如果他们这样做了,他们就违反了 Vulkan 的精神,那就是: 司机只负责简单快捷的事情和应用程序。

  15. 我希望这个 Vulkan 收养能尽快完成。

    为什么?……
    因为我希望看到模拟使用的其他改进>
    我主要关心的是多机组通过互联网正常带宽 (不是 1 gbps
    对称连接: D)
    内置通信 (对讲机,同时多联播) 和无线电
    基于频率、距离和功率的通信… 可能是人类的空中交通管制。
    也是一个飞机制造商更新。

    我知道 Vulkan 将花费大量时间,但这是我想要的,因为这个新的 API 基础 (基础) 是完全坚固和可用的。

    感谢层流这个伟大的模拟软件!!

    1. Vulkan 进入第3 的发展。只是切换到替代图形 API。其他开发人员已被重新分配到 GloMo 手机版本。奥斯汀正在制作电影、做辅助项目和 YouTube 评论。与此同时,XP 中仍有一长串问题和缺陷。环境问题和视觉效果差。自 2016年以来未优化的代码 (即反射)。仍然没有修复。它仍然是单个核心!他们搞砸了。一切都会结束的。

      1. 谁知道你是否正确。

        我只是想看看 Vulkan 在现场周围的尘云。它肯定需要新的图形 API。但也需要其他不那么倾向于本质上性能的特性。
        我在表达在所有这些都安定下来后,拥有什么会很好 (在一年内或任何时候命名)。

        所以,基本上我喜欢看更多的地平线而不是真实的近景。

  16. 很好的反馈,本,像往常一样。正如我之前所说,从 OpenGL 转移到 Vulkan 有点像在病人慢跑时做心脏直视手术。我以前更换过软件上的主要子系统,所以我明白了。

    在 OpenGL 世界里,我有很多最后的飞行任务要做,所以请花点时间。

  17. 这是个非常好的消息,我们会等待。

    有史以来最好的消息是听到我们终于摆脱了那种绝对的沉浸式破坏 “口吃” 烦恼,这种烦恼是在改变视图或像你描述的那样绕着相机转的时候引起的!

    如果我们能摆脱口吃,那将是一个惊人的进步!

    新年快乐

  18. 我有一个英特尔 i7 四核处理器和英特尔虹膜图形,因为我有很多 cpu,我的 FPS 会随着 vulkan 而增加吗?

    1. X-Plane 本质上是一个单一的核心/线程应用程序,所以多个核心不一定是有益的。我们不想在这里再次讨论这个话题,因为它涵盖了论坛上的许多其他地方。

      1. 等等-这绝对不是真的。

        X-Plane 的主要风景渲染路径 _ is _ single core,这往往是一个巨大的瓶颈。类似地,插件代码是单核的,除非插件作者使它成为多核,这是大量的工作,因为 SDK 没有帮助。

        但是所有的场景加载和准备过程都是纯多核的,而且它总是在你飞行的时候运行。AI 平面、一些每帧工作和各种杂项任务也是如此。因此,拥有双核机器的用户发现他们没有足够的内核以高帧率平稳飞行。

        1. 等等,那不是完全正确的,对吧?

          并行化的 X 平面电流水平能够获得最多 4-6 个内核。正如我们已经知道的那样,IPC (每个时钟的指令) 和 CPU 频率 (时钟) 都不会像过去那样快速增长。所以目前的趋势 (已经持续了两年 -- 谢谢 AMD) 是增加 CPU 内核的数量。所以今天 8 个 CPU 内核是平均的,16-32 更可能是桌面高端,让我们看看 ryzen3。

          唯一的问题是,在过去的两年里,虽然 CPU 内核的可用数量每年都在增加,但层流的反应为零。意味着没有更多的线程优化实现能够有效地加载超过这 4-6 个内核。

          是的,Vulkan 是朝着这个方向迈出的非常好的第一步,但是老实说,有火车要赶,层流甚至还没有稳定下来。因此,我们很可能只在 XPL12 中进行这种优化,肯定是在 MSFS2020 发布之后。

          1. 这取决于: 如果主要任务是移动数据,多线程不会有多大帮助,因为 RAM 是瓶颈。当任务繁重时,就有优势了。
            还要注意,目前的系统都是 NUMA 系统,并非所有线程都经过相同的测试,所有内核都有热限制。
            作为一个惊人的附带说明: 我可以从我的 cpu风扇中听到线程使用的噪音,就像 GPU 使用一样。我有软件可以将所有线程保持在几乎 100%,但那不是 X 平面; X 平面使我的图形处理器保持在 100%…

        2. 就像这部分的边注小边通知:

          -> 类似地,插件代码是单核的,除非插件作者让它成为多核,这是大量的工作,因为 SDK 没有帮助。

          一些工作已经开始为 YA747 项目添加多线程到 xlua 脚本。没有实时的时间框架,即使这将是成功的 -- 很多工作都是委婉地说。但是,如果这是第一次发布,这个问题应该会得到极大的缓解。

          1. 我很好奇线程 XLua 代码是什么样子。Lua VM 是在线程中运行的一个很好的候选,因为它与 sim 完全隔离,而不是你通过函数调用戳进去的洞。所以你可以默认建造一个好的沙箱。

  19. 我只是想对这条线索补充一句谢谢,你的工作非常受欢迎,所以按照你自己的节奏去做,保持精力。
    很明显,要让你的想法成真需要付出巨大的努力和对细节的极大关注,但是你们仍然设法在这一切中保持乐观, 所以坚持下去,美好的事情就会发生。

  20. 本,谢谢你写这个。当我们对那些紧闭的门后发生的事情有了更好的了解时,在侧翼等待要容易得多。新年快乐,谢谢你的辛勤工作。

  21. 我的收获是: 你们在圣诞节期间工作
    不管怎样,谢谢你的更新,我的 11GB VRAM GPU 正在耐心等待。

      1. 是的,我明白,我从 12月开始休假,包括我在内的家里的每个人第二天都生病了…… 哦,我们明天回去工作吧

  22. 微软发布了其最新一代图形应用编程接口 DirectX 12,苹果也发布了其 Metal 5 API。两者都计划使用与 Mantle 或 Vulkan 相同的低级硬件接入和移动便携性。那么为什么坚持 kulkan/Metal 呢?

    1. 等等-我想这里有些混乱。
      苹果为 OS X 和 iOS 提供了金属 (现在主要以两次的方式逐步更新)。
      微软有针对 Windows 和 XBox 的 DX12。
      Khronos 在 Windows 、 Linux 和 Android 上有 Vulkan。
      AMD 在 Windows 方面做了很多工作 -- 你可以把它看作是 Vulkan 之前的研发项目 -- 我认为 AMD 会在这一点上告诉你 “使用 Vulkan”, 但是低水平驱动的许多创新来自地幔。

      我们选择了金属和 Vulkan,因为这两个后端给了我们所有的平台: Linux 和 Windows,在桌面上没有新的后端, 我们也有安卓手机。

      DX12 不会给我们任何 Vulkan 没有的平台,也不会给我们任何 Vulkan 没有的功能。

      既然 X-Plane 已经被大量重构以使用多个后端驱动程序,我们可以为 DX12 做一个后端驱动程序,而且不会花那么长时间。但是那里没有胜利。

      1. Linux <3 我很高兴你支持 Linux。这是我唯一的飞行方式。

        我也想称赞团队的辛勤工作。我看到并欣赏你努力工作的结果。

        1. 附带说明: Linux 用户可以尝试使用 union 文件系统的测试版,风险很小: 使用稳定版本作为基础,在升级到 beta 之前在顶部安装一个新层。如果东西坏得很严重,只要去掉顶层,你就能回到稳定的状态…
          然而,对于极客来说,这是一个高级话题…

      2. 我想这也是一个优势,如果微软出于任何原因切断了对 windows 的 Vulkan 访问,你可以及时发布 DX12 后端……

        尽管如此,这仍然是一个需要维护的额外的东西。但无论如何,这可能不会发生。

      3. “我们选择了金属和 Vulkan,因为这两个后端给了我们所有的平台: Linux 和 Windows,桌面上没有新的后端, 我们也有安卓手机。”

        如果你放弃了 Mac 和 Linux 用户的一小部分,专注于你最大的市场,赢得用户,你还会做出同样的决定来选择 V/M 吗?

        1. 首先,Mac 约占我们市场的 1/3。因此,虽然我可以尝试推测性地回答这个问题,但我想弄清楚数字实际上是什么。有时人们会在评论部分建议,如果我们放弃 Mac,sim卡的情况会变得非常棒。我们会保留一些 mac 特有的恶化,但是,移植到金属上后,真的没有一个 “但是 Mac 怎么样” 来冲洗我们,如果我去奥斯汀然后去 “嘿, 奥斯汀,我有一个很好的主意,这个功能可以减少 1/3 的销售额。”他会有一些不友好的问题。

          我们目前的策略是 “后端不可知论” -- 也就是说,sim 可以对抗多个驱动程序。这是一个经过验证的设计,你可以在很多其他游戏和引擎中看到,我们几乎肯定会有抽象,不管我们选择什么特定的后端, 例如,我们不会只是从 “锁定到 OpenGL” 跳到 “锁定到 Vulkan” 或 “锁定到 DX12”。

          现在推动我们走向 Vulkan 的第二件事是,它让我们在 Android 上使用 Vulkan,而不是 GLES 3。所以当我们谈到覆盖所有平台时,记住有五个平台,而不是三个,因为移动和桌面共享大量低级代码。因此,我们必须在 Android + Windows 上的 Vulkan 和 Windows 上的 DX12 以及 Android 上的 Vulkan 之间进行选择 -- 我从未见过 DX12 独有的东西不在 Vulkan 中让它值得做 _ 更多 _ 后端。

          我们可能仍然会为 iOS 做金属,但是时间范围不会与桌面同步 -- 每当我们将图形重构移动到移动设备时,它就会发生 (这大部分还没有发生)。

  23. 你能评论一下使用 Vulcan 的 oculus VR HW 建议吗?不是最低的,不是不遗余力的,而是价值的甜蜜点?我应该期待 45fps 吗?

    考虑升级电脑。目前… I5-7600 k + 16GB RAM + vega64 8GB VRAM,win10。专用于 Xplane 的机器。

    11.50 英镑。超过 4 个内核会有帮助吗?还是更多?或者更好的 GPU?

    目前得到 ~ 30fps。兴奋地尝试 11.50 发布时,希望避免所有的调整黑客得到 45fps 和没有口吃。

  24. 嗨,本和所有人,

    你在模拟器上做得很好!很高兴听到您目前正在进行 Vulkan 版本开发。迫不及待地想试一试!

    新年快乐!

    -托马斯

  25. 我正在用 Radeon VII 运行 i9 9900K z390 hackintosh。在 4k 显示器上运行 1080p 的高风景设置,获得低 30 的 fps。期待看到金属实施将如何改善事情!多 gpu 平台会有什么好处吗?也许不是最初,而是最终?我有一个 egpu,我可以通过 Thunderbolt 3 与这个装备一起使用,或者我可以在内部添加第二个 gpu。

    出色的工作!奉献是如此令人印象深刻。

    新年快乐!

  26. 谢谢本和悉尼。尽管我们很兴奋,但我们理解新技术和软件开发的挑战。谢谢你如此努力地让它变得令人惊叹,并将带着诱饵的气息袖手旁观。新年快乐!!

  27. 也请考虑插件的 VRAM 消费。插件动态链接库 FSTramp 使用 Direct3D,在 4k 显示器上需要 0.5 GB VRAM。这些不是静态位图,而是同时绘制到 VRAM 中的最终图像的几个层。

    1. 西德尼的 VRAM 管理系统理论上应该考虑到这一点 -- 它和司机谈论 VRAM 有多少空闲,并试图应对 “暗物质” -- VRAM 耗尽了我们无法解释, 例如从插件。

  28. 你的努力和坦率尤其受到像我这样的技术恐惧症患者的赞赏,他们曾经在庞蒂乌斯成为飞行员后用 fortran 和 cobol 创造东西,

  29. 干得好。真的很期待测试 Vulkan 和 Radeon VII。
    @ Ben: 您看到 16GB VRAM 卡有什么用途或好处吗?Xplane 真的可以利用它们来获得速度优势吗?

    1. 我正要发布一个关于 VII 的非常相似的问题。它只是消除了模糊纹理的风险吗?

  30. 请不要被约会束缚。最好慢慢来,推出一款你引以为豪的产品,而不是后悔。

    新年快乐。

  31. 我在我的笔记本电脑上使用淄博 11.40 mod 运行 X-Plane 737,它只有 2 GB 的 VRAM。但是在中等图形上,它工作正常。当我看到你提到你正在努力改进 4gb VRAM 上的图形时,我很担心。我能跑 11.50 吗?

    我和其他人一起感谢你的辛勤工作。新年快乐。

      1. 配备双 3GB Firepro D500 gpu 的 2013 Mac Pro 怎么样?X-Plane 用金属实现是否利用了第二张卡片?

        (奥斯汀还在经营他的 “垃圾桶” 吗?)

        1. 金属版,像 GL 版一样,不利用第二张卡片。正如我以前说过的,我无意尝试优化两张卡片驱动一个显示器的情况。就 D500 Mac Pro 而言,它只是 X-Plane 的一个非常非常愚蠢的硬件, 因为这两张小卡片的热预算被错误地用于 X 平面。奥斯汀仍然有他的垃圾桶,就价格而言,它不是一台好的 X-Plane 机器。然而,它是一个非常便携的开发机器,这对奥斯汀非常有用。

          1. 但是你对一张卡片运行另一个显示器的想法持开放态度?Ie 3 显示因此 3 视频卡?

  32. 嗨,本,祝你新年快乐!

    干得好,你所有的努力工作; 你和团队真的应该休息一下!

    关于性能…… 现在的情况是,英伟达仍然是首选的图形处理器,还是 Vulcan 的改进意味着英伟达和 AMD 都势均力敌?

    非常感谢!

    多姆

    1. 我们认为它将是均匀匹配的,你可以根据 GPU 的实际性能选择一个 GPU (应该如此) 但是可能在测试后期需要更多的测试。在我们的测试前,Red 和 green 团队有非常相似的驱动开销。

  33. 在 VRAM 和 RAM 上: 我看到了与操作系统分页的相似之处: 如果操作系统忙于移入和移出页面,性能将会受到影响; 如果操作系统 (一个线程) 不得不等待一页,表演也会受到影响。所以操作系统在两者之间有一个额外的缓存。
    我的想法: 基于缺乏 VRAM 构建一个看不见的对象队列加上优先级: 在该优先级的后台线程会移动这些对象 (可能是旧的和大的对象更喜欢) 到 RAM,释放 VRAM (和队列)。
    所以总会有足够的免费 VRAM。然而,“页面输入” (VRAM 中需要 RAM 中的对象) 仍然是同步的,即: 必须有人等待。
    当然,如果你能预测到需要的对象,你可以构建一个类似的页面输入队列,或者至少取消页面输出…

  34. 嗨,本,
    我在你之前的帖子中询问了图层系统的使用情况,但是在评论被关闭之前没有机会回复。
    我指的是使用图层来进行某种绘图; 也许就像纯文本一样简单。
    问候,
    卡尔

    1. 啊。从技术上讲,一个拥有大量时间的第三方开发人员,并且愿意编写大量代码,这些代码几乎肯定会在下次我查看 Vulkan 时被破坏,可以使用该层系统将我们与 Vulkan 驱动程序的交互进行包装,并将他们想要的几乎任何东西插入 sim。(我想你也可以更换装载机,然后走那条路。)

      这将类似于 FlyInside 包装整个 OpenGL API,重写我们的着色器,扰乱我们的绘图调用流,使 VR 在非 VR 启用的 X 平面上工作,如 v10。

      这里有两个大的缺点:
      1.这是一项了不起的工作。你得到的 sim卡的视图就像通过针孔观察一个城市的速度…… 一大堆随机的 API 调用,没有韵律或理由。对程序员来说,整理它们是一项艰巨的工作。
      2.它有 _ zero _ future 兼容性。“我们如何与驱动程序交谈” 不是一个 SDK 或 API,当我们进行任何开发时,它会以两种有意的方式改变,甚至只是作者改变内容也会以无意的方式改变。所以你会报名一遍又一遍地打断你的工作。

      我认为这对于 FlyInside 和 v10 来说实际上是很好的 -- 因为 v10 已经结束了,我们从来没有打算做虚拟现实 (这两件事在某种程度上是联系在一起的) 他们可以把东西放一次,然后收工。但是对于 v11,在开发周期中期,它只是要求他们的附加组件被重复破坏。

      干杯

      1. 感谢您的详细回复。
        你能扩展 2) “我们如何与驱动程序交谈” 不是 SDK 或 API…… 我远非 Vulkan 方面的专家,但我知道它有一个定义明确的 API (Khronos) 和 SDK (LunarG)。
        非常感谢。

        1. _ Driver 的 API _ (例如 Vulkan 、 OpenGL 、 Metal) 绝对是一个定义明确的 API。它有明确的规则 -- 当你打电话给 X 时会发生什么,什么是合法的,什么是非法的,bla。

          _ 我们对驱动程序的使用根本不是一个定义良好的 API。例如,X-Plane 呈现其各种 FBOs 的 _ order _ 在 v11 版本运行期间发生了变化,从 11.20 到 11.30 再到 11.50。Vulkan 没有说我们的通行证是什么顺序,甚至我们的通行证是什么。

          因此,基于 _ Vulkan 的 _ API 的 Vulkan 层可以做正常的事情。这就是验证层的工作方式。因为当我们说 “开始渲染过程” 时,我们必须传递一个渲染过程对象,这是明确定义的,如果我们在没有有效 RP 对象的情况下调用 “开始渲染过程”, 验证层可以是 “嘿,你在做傻事”。这就是验证层的观点 -- 做较慢的错误检查来帮助应用程序开发人员发现错误。

          但是一个以在 X 平面屏幕上插入图形为目标的 Vulkan 层呢?好吧,如果你知道结束渲染过程的调用是我们结束主窗口 FBO 的渲染过程,你可以去 “哈!我将添加一个发送更多的绘图命令给驱动程序,然后结束通过 “结束渲染通道”-和 viola!您已经将额外的 Vulkan 驱动程序命令注入到我们的命令流中。

          但当是正确的时间,如果你想达到的效果 (E.g.三维绘图或三维顶部的二维绘图,或者定制天空穹顶,或者如果你可以任意修改我们的框架,你可以做任何其他的技巧)?

          答案是: 谁知道呢!没有指定。它可能会在下一个版本的 sim卡中改变。X 平面使用 Vulkan 并不标准化 -- 只有 Vulkan API 本身是标准化的。

          1. 再次感谢 Ben,感谢您花时间提供如此详细的回复。
            期待 2020年 XP 世界的伟大成就。
            亲切的问候,
            卡尔

  35. “明天我会试着做一个关于 Vulkan 和 Metal 的常见问题解答;”

    这根本不是抱怨,但是如果你看到服务器流量激增,是我点击 reload 看看你是否发布了。

    抱歉!知道如果你做一个常见问题解答,我很感兴趣

    1. 抱歉,我还没有谈到这个。我开始了一个常见问题解答,我不认为我会赢。很难同时得到简单的问题和答案。简单的问题 (将 X 与 Vulkan 一起工作) 有复杂的答案 (这取决于) 和简单的答案 (如果没有插件,你的插件肯定会工作) 回答复杂的问题 (我的风景包不是插件增强需要更新)。

  36. Ben Supnik 说: 11.41,我们将麦克风权利添加到我们的列表中,希望能解决这个问题。只有 X-Plane 可以解决这个问题-插件 DLLs 没有获得安全权利,因为它是在进程级别。

    我们能期待 11.50 的相机权利吗?拜托。

  37. 嗨,本,

    我目前正在考虑升级我的 CPU (GPU 2070 超级),不能决定 i7-9700K 和 AMD 3700X。你认为在 Vulkan 什么会运行得更好?多核多线程机器 Ryzen 或单核野兽 9700K

    干杯
    凯文

    1. 在 11.50 中,多核使用只是稍微重要一点。因为我们现在在其他内核上做一些曾经口吃的事情,如果你的内核用完了,那也没用,但是我们不会使用 8 个内核来渲染一个帧。

      1. 好的,谢谢。所以基本上,线程较少的 CPU 的更高核心速度将受益更多,谢谢。

  38. 你不认为自动调整图形设置并在飞行中调整它们是有意义的吗?也许当你在地面上的时候,最佳的设置会不同于高姿态?

  39. 亲爱的开发团队,

    只是好奇: bug 修复过程是如何进行的?你设法解决模糊纹理问题了吗?也许你喜欢分享一些见解。我和我的孩子们很高兴测试即将到来的 beta 补丁 :-)。
    玩得开心。

    1. 缓慢但稳定。我们已经从私人测试版的第三方开发人员那里得到了很好的 bug 报告,但是模糊的纹理问题不是一天修复的事情。

      1. 如果在 vram 饥饿系统上,您在加载时转换为 16 但纹理 (每个通道 5 、 6 和 5 位),会怎么样?

        还是缺少阿尔法通道会把事情搞砸?

  40. VRAM 分配如何与加载包括粒子在内的对象的插件一起工作?插件加载对象对待不同的风景等?
    期待着用数以千计的带有粒子的物体与 OpenGL 进行测试。

    1. 如果插件导致加载 X 平面艺术资产 (OBJ 、粒子等),则使用与场景加载相同的机制对插件透明地管理 VRAM:

      -加载新的纹理可能会增加 VRAM 压力。
      -我们可以页出一些东西来处理它。
      – If OTHER stuff pages out (e.g. you fly away from Las Vegas and we can page out all of Cristianos’ nice buildings then if VRAM pressure releases enough, the plugin loaded art assets might INCREASE their res to use the free space, just like the rest of the scenery system.

      如果一个插件只是直接使用 VRAM (例如,它调用 glTexImage2D 并分配一个巨大的 64 MB 纹理) 然后,当 Vulkan 驱动程序告诉我们 “嘿,VRAM 现在少了” (因为驱动程序看到了所有) 时,我们注意到 VRAM 压力,我们可能会页出一些东西。

评论已关闭。