编辑器在编译Shader时的报错疑问

A1：OpenGL ES2.0中，单个Shader最多支持8个贴图；OpenGL ES3.0中，单个Shader最多支持16个贴图。没办法，这是硬件限制，你只能减少贴图数量。

比如，把几个2D Texture合成2D Array Texture。或者，根据不同的Keyword，访问不同的贴图，但是要保证，贴图使用量最多的变体，符合上面的要求。

A2：以前的写法，参考这个：

https://blog.csdn.net/weixin_32521765/article/details/113056248

现在的写法，只定义一个Sampler，传参数的时候共用这一个就行：

A1：jpg和png拥有良好的压缩率，也就是你所看到的1KB的图片。但是这2种格式不支持随机读取，所以引擎会帮你转换成支持随机读取的格式，会比原来的图片大一点，存储也是按照新格式来存储的。包体构成如果是AssetBundle或者全都放在Resource目录下，就可以通过AssetStudio进行解包查看。

A2：你要理解内存大小和所占硬盘的容量大小，10KB是实际加载这张图内存会占用的大小，1KB是这个文件在你的操作系统中的文件所占的硬盘大小，但是不完全等同于实际进包内的大小，毕竟Resource里或者打成AssetBundle之后会有一定的压缩，可以在打下的AssetBundle中查看。

也就是说，要看下这个文件更改格式之后打出来的AssetBundle大小是否产生了实质的变化，因为AssetBundle的大小进到包内一般不会被压缩。

A3：最终看打出来的AssetBundle包的大小即可，通常AssetBundle是不会2次压缩的，否则加载耗时会变高。纹理的压缩格式也会导致AssetBundle大小不一样，下图中是1024x1024的纹理测试得到的结果，仅供参考：

A1：首先一点，Sprite不是你想的100X100尺寸，传到GPU就是这块区域，最终传输到GPU还是纹理本身，GUI只是通过Sprite信息设置了顶点UV，才能正确渲染纹理的目标区域。Sprite它不是任何显示资源或者物理资源，而就是一个纯数据结构，为了方便管理一个纹理的不同区域。

A2：纹理带宽主要指读纹理带宽：当GPU的OnChip Memory上没有，则会从System Memory里面读取，一般是会读取一个NxN的像素块的内容进OnChip Memory。所以，当采样次数和采样点更多的时候，越容易Cache Miss，这样就增多了到System Memory里面读取纹理到OnChip的次数，带宽就相应增大了。

因此，为了降低带宽，我们常说纹理要开Mipmap，要减少采样次数（避免开启各项异性和三线性差值），从而尽量减少Cache Miss次数；也可以进一步压缩纹理格式，来减少传输的数据量。

对于本问题，本质还是在OnChip上读取里面NxN的内容的，但是会受到采样次数的影响。其中如果有200个DrawCall但被合成一个了Batch，仍然会采样200次；但如果确实合成了一个DrawCall，那就会只采一次。

之所以说Mipmap降低带宽，是因为传到GPU的是合适层级的纹理，当画下一个像素时很大概率就落在OnChip里的NxN个像素内，就不需要重新采从而增加Cache Miss概率；但如果没有开Mipmap而导致用了分辨率过大的层级，则画两个相邻的点也可能要跨纹理中的好几个像素，从而得重新采从而增加Cache Miss概率。

A3：对于带宽来说，是100x100还是1024x1024，区别不大，小图和大图的区别在于从CPU传到GPU的时候的操作，是一次性传图集到GPU里面还是分很多次传小图到GPU，到带宽层面，都是读取采样点周围的像素到OnChip上，应该没有太大区别。至于采样点读取的NxN有多大，这个应该是和硬件相关。

A：Frustum Culling已经在JobSytem的子线程中。你相机可能重复渲染了，或者你场景的对象太多了，建议先用些其他手段，比如LOD、HLOD或逻辑剔除等。

跳过不可能。如果跳过，全地图的顶点都会进入这一帧的VBO（一样会卡），EBO长度也大大增加 ，接着由驱动发送到GPU，后来来到Vertex Shader阶段参与计算（压力)，其次除法前裁剪［－ｗ，ｗ］之外的顶点（最后也裁剪了，但是浪费了最大的计算过程资源）。