编写shader时的一些建议:
1、只计算需要计算的东西;
2、通常,需要渲染的像素比顶点数多,而顶点数又比物体数多很多。所以如果可以,尽量将运算从PS移到VS,或直接通过script来设置某些固定值;
3、在使用Surface Shader时,可以通过一些指令让shader优化很多。
通常情况下,Surface shader的很多默认选项都是开启的,以适应大多数情况,但是很多时候,你可以关闭其中的一些选项,从而让你的shader运行的更快:
(1) approxview 对于使用了view direction的shader,该选项会让view dir的normalize操作per-vertex进行,而不是per-pixel。这个优化通常效果明显。
(2) halfasview 可以让Specular shader变得快一些,使用一个介于光照方向和观察方向之间的half vector来代替真正的观察方向viewDir来计算光照函数。
(3) noforwardadd Forward Render时,完全只支持一盏方向光的per-pixel渲染,其余的光照全部按照per-vertex或SH渲染。这样可以确保shader在一个pass里渲染完成。
(4) noambient 禁掉ambient lighting和SH lighting,可以让shader快一点儿。
4、浮点数精度相关:
float:最高精度,通常32位
half:中等精度,通常16位,-60000到60000,
fixed:最低精度,通常11位,-2.0到2.0,1/256的精度。
尽量使用低精度。对于color和unit length vectors,使用fixed,其他情况,根据取值范围尽量使用half,实在不够则使用float。
在移动平台,关键是在fragment shader中尽可能多的使用低精度数据。另外,对于多数移动GPU,在低精度和高精度之间转换是非常耗的,在fixed上做swizzle操作也是很费事的。
5、Alpha Test
Alpha test和clip()函数,在不同平台有不同的性能开销。
通常使用它来cull那些完全透明的像素。
但是,在ios和一些android上使用的PowerVR GPUs上面,alpha test非常的昂贵。
6、Color Mask
在移动设备上,Color Mask也是非常昂贵的,所以尽量别使用它,除非真的是需要。
相关文章
- Redis进行性能优化可以考虑的一些策略
- RabbitMQ 优点和缺点- 消息可靠性:RabbitMQ 提供了持久化功能和消息确认机制,确保消息在各种情况下都能可靠地存储和处理。 灵活的路由:通过多种交换机类型和绑定规则,RabbitMQ 能够灵活地路由消息到指定的队列。 支持多种消息协议:实现了 AMQP 等(MQTT、STOMP)标准化、开放的消息队列协议,使其能够与多种语言编写的应用程序进行通信。 插件化扩展:RabbitMQ 提供了丰富的插件系统,可以通过插件扩展功能,如死信队列、压缩、追踪等。 高可用性:支持集群模式和镜像队列,确保服务的可用性 易用性和可管理性:提供了丰富的 API 和管理工具,以及多种客户端库和框架支持,易于集成和使用。 多语言支持:RabbitMQ 支持多种编程语言的客户端,包括 Java、Python、Ruby、C#、Node.js 等,方便开发人员集成到各种应用中。 高性能:在处理大量并发消息时表现出色。 广泛的社区支持:拥有庞大的开发者社区和丰富的文档资源。 劣势: 性能和吞吐量较低:相比于 Apache Kafka 等面向大数据流处理的消息队列系统,RabbitMQ 的吞吐量较低,不适合处理海量的实时数据流。RabbitMQ 的设计更注重消息的可靠性和灵活性,而非极高的吞吐性能。
- 在开发ts时,有时会遇到没有d.ts文件的库,同时在老项目迁移到ts项目时也会遇到一些文件需要自己编写声明文件,但是在需要的声明文件比较多的情况,就需要自动生产声明文件。用过几个库。今天简单记录一下。自己怎么编写有很多教程和文档,那里就不介绍了。
- 编写Ruby代码注释时需要注意的一些问题
- VS2015--win32project配置的一些想法之在 Visual Studio 2015 中进行调试的同一时候分析性能
- Python使用Beautiful Soup包编写爬虫时的一些关键点
- 编写Shader时的一些性能考虑
- Jmeter编写脚本时遇到的一些问题整理
- 编写代码的一些小细节,主要是性能方面的注意吧
- 升级到SQL Server 2012/2014时一些需要考虑的事项