注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

中吴南顾惟一笑

成功法则就是那19个字

 
 
 

日志

 
 

Vulkan  

2016-09-26 17:18:08|  分类: R&D |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

    开放标准,跨平台3D计算API
    不再与OpenGL兼容
    简洁清晰现代架构(command buffer,dispatch queue)
    多线程,多核友好
    极大降低CPU开销
    稳定性,通过显式控制,可以到达可预见的性能(shader编译,command生成)
        原来:应用调用接口(如draw call)
            驱动也许在做
            - 编译shader
            - 刷新缓存
            - 分配内存
        现在:API 对应的硬件指令时间
    给应用程序更多控制
        - 明确的CPU/GPU sharing 同步,RMW hazard
        - 明确的内存管理
        - 最大化CPU性能


    具体特征
    1.暴露更多更加低层的功能与控制,图形引擎的编写可以更具灵活性,比如使用更多的全局算法,而不拘泥于屏幕空间。
            原OpenGL接口专注于流水线
            只是结构固定的流水线的几个特定点允许shader编程
    2.统一存储资源,仅包括两种:线性存储的Memory和非线性存储的Texture。之所以仍然要区别两者,一个是因为Locality不同,还有一个是因为Filtering的需要。
            以前各种Buffer, uniform buffer, pixel buffer, texture buffer, vertex buffer
    3.API被彻底简化成了State和Cmd。
            State的集中处置意味着驱动对状态一致性检查的减少。
    4.分线程的Command Buffer和DMA集中调度。这主要是为了支持多线程。
            CPU的利用率可以得到一些解放(比如不用去没必要的wait for sync).
            其实就是多个缓存绘制命令队列,直到flush的时候才把这些命令推到GPU
            关注通用计算
    5.新一代高性能图像处理和计算API,它要比OpenGL ES更高效。
            在移动、桌面、控制台和嵌入式平台上实现最小化驱动过载并提高了多线程性能
    6.新标准SPIR-V?中间语言规范
        Bytecode,driver->vm?
        可以带来更高的渲染语言灵活性
        Runtime之上的Mid Level Shader ASM和硬件的实际指令差的挺远
        可以通过Rust,C#等语言完成从GLSL,Mid Level 到SPIR的转换或者优化。


    对开发者的影响
        驱动开发简单
          - 以前需要实现算法和shader compiler
          - driver这层变薄,效率高了
        程序员负担加大
          - Memory Management, 折腾Buffer利用策略
          - 开发者将能够自行管理内存和多线程,而不是将此类决策交给驱动
          - 需要更好的工具或引擎开发

  评论这张
 
阅读(52)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017