※ 引述《lovesnake (LoyalDog)》之铭言：
: ※ 引述《justinlcs (班班)》之铭言：
: : ^^^^^^^^
: : interrupt
: : 看你程式怎么写，但是通常Render Thread只会有一个的情况下，CPU送东西给GPU之后，
: : 大部分显示引擎会等到结果返回才进行下一次的render，要不然资源存取很容易打架
: : 大多数的引擎都会等，一个render结束才会执行下一个。
: : 在软件层面来说，可以取得的时间只有
: : 可以取得CPU准备资料所消耗的时间
: : 可以取得CPU送指令给GPU所消耗的时间 + GPU收到指令返回结果所消耗时间的"总和"
: : 无法从软件面单独取得CPU送资料给GPU消耗的时间
: : 无法从软件面单独取得GPU收到指令完成运算时所消耗的时间
: : 我所了解的程度有限，希望可以帮上忙
: 所用的是最底层的API OpenGL.
: 主程式可能有很多Thread，Timer、AI、Physics、Rendering等等。
: 我想知道的是，今天当CPU把Draw Call送给GPU后，是否会将RenderingThread Block，
: 然后执行其他的Thread，还是Busy-Waiting等到GPU处理完?
Render Thread是Render Thread
CPU在Render Thread丢资料给GPU之后就是等，在等的时候CPU自然会做其他Thread的事情
: 或者今天为单一Process，OpenGL的Display Function前后包夹clock();
: 他会直接把Display处理完丢给GPU，然后直接继续执行，然后等下一次要Display时，再
: Wait GPU的Interrupt?
: 还是会等GPU执行完以后才继续下面的程式呢?
如果你所有的逻辑设计包含Render都是在同一个Main Thread里面，
也就是说你整支程式就只有一个Thread，当然会等GPU作完才会执行下一步
但是如果不是，那答案就很不一定，因为一般游戏引擎绝对有很多个Thread
然后由一个Main Thread下达命令，例如
Main Thread中你下达了PlaySound()的call
实际上把播放的声音送到 Sound Quene 之中然后再由另一个Sound Thread去播放
Render也是如此，要Render的东西送到Render Quene，由Render Thread一一绘制
但是Render Thread会比单纯播放声音复杂很多，解释起来可以讲很多，
而且实作的方式不同又可能是另一个故事，所以这里不多做解释
因为要call的系统资源种类太多，例如加载材质可能又有一个Loading Thread，
Network又是另一个Thread，诸如此类...这也是为何许多游戏引擎的API，
相关的资源都会实做一个Singleton的Manager，例如Sound Manager,
Texture Manager, Control Manager, AI, GPU, Shader, Map, Decal, Mesh, Physics,
Network, Memeory, Animation, Buffer, Tick, Post Effect, Render, Render World,
Font, Logic, Sence....等等以异步的方式
通常是用Observer模式实做来订阅并触发各种事件来交换讯息和进行动作
总而言之，如果你是把所有的逻辑都写在同一个Thread，那么绝对绝对是上一步做完
才会执行下一步
如果是好几个Thread，考量异步资料的运作方式会有很多种不同的答案。
**补充
我可能有点答非所问，如果你的问题是指compiler在编译程式时，
是用Single Thread去模拟Multi Thread的选项，如果是这种情况，
那么执行过程中所有的行为都会影响到Render的时间