Performance 每个应用程序有多个上下文，而每个上下文有多个应用程序

我想知道创建一个负责所有应用程序元素渲染的“系统”级渲染服务器是否是一个好主意。目前，应用程序通常有自己的上下文，这意味着无论不同应用程序中的数据是否相同，都将在GPU内存中复制，更频繁的资源管理调用只会减少可用渲染调用的数量。据我所知，OpenGL执行引擎/服务器本身在设计上是顺序/单线程的。所以从技术上讲，所有可能在应用程序间重用的东西，特别是像位图或文本和UI的几何缓存这样的重东西，都会因为不必要的传输和内存使用而阻塞服务器

在多个应用程序之间共享一个场景图有什么缺点吗？当然，假设正确处理意外冻结的客户端

我想知道创建一个负责所有应用程序元素渲染的“系统”级渲染服务器是否是一个好主意

这取决于手头的任务。一个小迂回：以webbrowser为例，JavaScript在DOM上执行操作；CSS转换和SVG元素定义图形元素。为响应事件而调用的每个JavaScript都可以作为单独的线程/轻量级进程运行。从某种意义上说，webbrowser是一个渲染引擎（他们内部甚至被称为渲染引擎），适用于所有应用程序

这是个好主意

一般来说，显示服务器是一件非常好的事情。看看X11，它有着令人难以置信的历史记录。这些天，Wayland是所有的炒作，很多人喝了Kool-Aid，但实际上你想要一个显示服务器的抽象但并非出于您所想的原因。拥有显示服务器的主要原因是避免冗余代码（而非冗余数据），并且只有一个实体来处理脏细节（颜色空间、设备物理属性），并提供优化的高阶绘图原语

但对于直接使用OpenGL而言，这些考虑因素都无关紧要： 目前，应用程序通常有自己的上下文，这意味着不同应用程序中的数据可能相同

那么？内存很便宜。通过合并重复数据并不能获得性能，因为对性能唯一重要的是处理这些数据所需的内存带宽。但带宽并没有改变，因为它只取决于数据的内部结构，而通过合并，数据的内部结构是不变的

事实上，重复数据消除会造成很大的开销，因为当一个应用程序进行更改时，如果不影响另一个应用程序，则必须调用一个非免费的“写时拷贝”操作，这通常意味着一个完整的拷贝，但这意味着在进行整个拷贝时会消耗内存带宽

但是，对于一个应用程序的数据中的一个小的、选定的更改，由于每个应用程序都有自己的副本，内存总线被阻塞的时间要短得多

它将在GPU内存中复制，更频繁的资源管理调用只会减少可用渲染调用的数量

资源管理和渲染通常不会相互干扰。当GPU正忙于将标量值转换为点、线和三角形时，CPU上的驱动程序可以完成管理工作。事实上，当GPU忙于渲染时，通过让CPU执行与渲染无关的工作，可以获得很多性能

据我所知，OpenGL执行引擎/服务器本身在设计上是顺序/单线程的

你在哪里读到的？在OpenGL规范中没有这样的约束/要求，真正的OpenGL实现（=驱动程序）可以自由地并行化

只是用不必要的传输和内存使用阻塞了服务器

当数据被加载时，传输只发生一次。重复数据消除不会改变内存带宽消耗。如今，内存非常便宜，重复数据消除根本不值得付出努力

在多个应用程序之间共享一个场景图有什么缺点吗？当然，假设正确处理意外冻结的客户端

我想你完全误解了OpenGL的本质OpenGL不是场景图。OpenGL中没有场景，只有mo模型。每个应用程序都有自己的数据布局，最终这些数据被传递到OpenGL中，以便在屏幕上绘制像素

---

但是，对于OpenGL，只有绘图命令可以将标量值数组转换为屏幕上的点、线和三角形。没有更多了。

有许多移动设备的内存小于等于1 GB，由CPU和GPU共享。此外，我从未声称OpenGL是一个场景图。问题是使用共享的sceengraph是否是最大化GL调用的好主意。@user2341104:这始终取决于应用程序。对于一个复杂的GUI系统（ATM I和一些来自本地黑客空间的朋友正在涉猎），共享显示服务器肯定会带来好处。然而，可视化系统或游戏的性能实际上会受到影响。此外，共享场景图还引发了大量关于安全性和数据分离的蠕虫。说到内存，除了游戏、可视化和图像/视频编辑之外，大多数应用程序只需要几个100kiB，也许几个MiB。