HSR效能1/7？喷了，转个7800的review，包括z-rejection performance
http://www.beyond3d.com/content/reviews/38/8
稍微解释一下，render order为Back to Front时，Early-Z-Rejection没有工作。因此pixel pipeline会承受全部overdraw。当render order为Front to Back时，可认为是Early-Z-Rejection的理想状态。
overdraw factor为3时，F2B的性能是B2F的两倍，overdraw factor为8时F2B的性能是B2F的3.6倍。比同期的ATI要来的差不假，但也还能将就。
顺便一提，这东西不是说想关就关的，换句话说，这个early-Z-Reject除非吃错了药严格按照B2F顺序，或者打开AlphaBlending（Alphablending需要重复渲染否则结果就不对了）要不就是从shader里输出深度，要不就是使用一些特殊Z-Test，否则一直是起作用的，无论开不开AA。那请问1/7是怎么来的？

至于4G fillrate是不是等效的请看官方网页
http://www.imgtec.com/news/Release/index.asp?NewsID=428
稍微做下算术都知道，4G = 200M*2Rop*4Core*2.5 depth complexity

[ 本帖最后由 hourousha 于 2011-2-2 14:55 编辑 ]

引用:

原帖由 JimmyC 于 2011-2-3 19:27 发表
要到G80才算真正支援early z-rejection
http://www.gamedev.net/topic/576 ... on-on-g70-hardware/

喷了，你给出的链接只是说明在alpha test时early-z会失效罢了（大多数正常情况不会失效）。这和你说的‘G70的HSR是历史笑话’‘fps会降到1/7’之类的逻辑联系在哪？

要说起来，你不如去关心PVR中你引以为豪的TBDR的HSR对alpha test支持程度比较靠谱，下文引自PowerVR Insider FAQ
http://www.imgtec.com/powervr/insider/powervr-faq.asp

引用:

To take advantage of this all 3D and 2D applications should use opaque objects (blending off, alpha test off, no discard in shader) as much as possible so that the HSR process can reduce fragment processing to a minimum. These should be rendered first, before any objects with transparency. Examples of this kind of sprites could be background graphics, terrain tiles, pop-up message windows.

[ 本帖最后由 hourousha 于 2011-2-4 02:01 编辑 ]

引用:

原帖由 JimmyC 于 2011-2-4 14:30 发表
不至, 至少在这些情况下也会失效(fps降至1/10~30)
-use kill/clip in pixelshader
-change compare func
-modify depth
好吧, 你要说这也算是完整的HSR我也没办法
那G80的官方文档和Nvidia GPU Programming Guide还真是写心酸的

USSE2的TBDR效能已经比USSE好了一倍(16z:8z)
一样是MBX, Sega的Aurora(2008产品)就有专门优化透明/不完整三角形
当年PowerVR2代, Dreamcast也是alpha test with HW front, 效能比同时脉的电脑版快一倍
难保SGX543MP4+不会有硬件加速alpha test, 就算没有, 也有64z, 即是Galaxy S的八倍
200MHz的Galaxy S(SGX540)比起240MHz的Tegra2 GPU效能差距多少?
就算不是N粉也可以参考Nvidia今年1月26日发出的宣传PDF, 说是110~150%, 实际约110~125%
然後Nvidia声称Tegra2的GPU效能是低阶G80(Tegra1是低阶Geforce6)
要喷, 请连NV一起喷, 好歹SGX543MP4+的同时脉效能是这"低阶G80"的八倍以上

1：请给出fps降至1/10至1/30的出处，说起来你这个结论就很神，降至1/10的原始参照物在哪里？前提条件是什么？仅仅是一个alpha test时HSR失效就会让fps降到1/10，那岂不是说alpha test占了总渲染成本的90%以上且alpha test的overdraw要不小于10不成？这是哪来的神奇程序？至于1/30，我的天……

2：顺便指出你给出的那三个条件，条件1上一个帖子里提了对于SGX的TBDR同样失效，看我给你那个Insider FAQ里，甚至提到了Alpha test/pixel shader discard性能甚至比alpha blend性能还要糟糕，所以建议使用alpha=0的alpha blend 来代替alpha test/pixel shader discard；条件3我在37楼就提了请仔细看贴，这种情况失效也是正常的，就和alpha blend时HSR失效一个性质，因为这时需要运行fragment shader（要不怎么输出深度），自然不可能early-z（别忘了early-z是要在运行fragment shader前把fragment给cull掉）了，这种情况TBDR自然也不能幸免。所以我说你还是先替PVR心酸吧。
一个功能有限制很正常，关键得看你怎么应用，能不能规避限制。你非要就着限制来使用，那是自找不痛快。至少G70在处理solid object时没什么问题（测试结果在那摆着），这也是early-z最常应用的范围。因此RSX的HSR至少是‘多数情况下可用的’，结果被你一句话就说成了HSR的笑话，那请问同样不支持alpha test的SGX是不是也是HSR的笑话？

3：优化透明三角形么？还是看我给你的那个Insider FAQ，里面提到了，我再给你引用一下

引用:

For sprites with transparent areas, create polygons that are optimal for the visible area and exclude fragments that are completely transparent. If an application was to render a simple triangular shaped tree texture on a quad polygon, there would be large, empty areas that would need to be blended. A better approach in this situation would be to use a triangle that tightly fits the shape of the texture. By doing so, most of the empty area that would have to be blended when using a quad to render the tree sprite can be removed, which means there are fewer fragments to blend. Geometry used to tightly fit sprites in a given application should be kept as simple as possible while eliminating as many unwanted fragments as possible. Finding the balance between geometric complexity and the empty space that will be removed by using more complex geometry is a balance that is very application and platform specific. A tool such as the one described here: http://www.humus.name/index.php?page=Cool&ID=8 can be used to generate the geometry required.

For further optimisation, when rendering sprites with partially transparent areas, break each object down into an area that can be rendered as an opaque sprite and a second area of partially transparency that can be blended. By taking this approach, the number of fragments that need to be blended for each sprite can be significantly reduced, which allows the HSR process to provide a "super" fill rate. In order to maintain sprite ordering, use of the depth buffer will be required - each sprite will need a unique offset to avoid artefacts. Generating the areas for this technique can be done with a similar tool to that mentioned above, but this time looking for opaque pixels instead of completely transparent. As stated previously, the opaque objects should be drawn first followed by the blended objects as this will allow the blended objects to gain the most benefit possible from the hardware's HSR process.

是让开发者事先把blend的几何体给分割成不透明/半透明两大集合，尽量减小blend处理量，这就是你说的硬件优化透明/镂空三角形吗？喷了……
4:不是要和RSX比吗？怎么又转进到Tegra2去了？别跑题别跑题，233……

[ 本帖最后由 hourousha 于 2011-2-4 16:05 编辑 ]

引用:

原帖由 JimmyC 于 2011-2-4 16:39 发表
early-z exists since gf3, like mentioned before. it is disabled if you
-enable alpha test
-use kill/clip in pixelshader
-change compare func
in order to get speed again on G70, you need to work around your alpha-testing.
this is critical, otherwise you pretty much run without optimization and then you're easily 10 to 30 times slower.
你自己搜索一下随便一个Dreamcast模拟器的说明
DC用的PowerVR2的指令分ZWrite和Alpha ZWrite等
後者可大幅强化fps数倍,
这硬体加速指令可是DC版的PowerVR2才有, 显卡的Neon250没有
Sega街机用的MBX也有这个指令, 但iphone2G/3G用的就没有
证明Imgtec一早就有解决方法但没全部采用
在还没清楚SGX543MP4+的规格前就喷这点会不会太早?
PowerVR Insider那边的资料别说SGX543MP4+, 连SGX543的也没有, 也没有家用机芯片的资料
最近期的就是2007年发表的SGX540的开发建议
比起USSE, USSE2每管线shader/TBDR/隐面处理性能增加一倍, 8z>16z, 1D>2D, Vec2>Vec4, 同时支援更多硬体加速
难为你可以面不红气不喘地用2005年USSE的资料来喷2009年的USSE2
跑什麽题?
RSX:G70(7800)阉割版(8:24:24:8)
时脉比SGX543MP4+高20%, 效能高10~25%的240MHz Tegra2:低阶G80, 最低阶的G80为8300GS(8:8:4)
前一点不敢喷,
说到同时脉效能为Tegra2八倍以上的SGX543MP4+效能接近8600GT(32:16:8)/RSX就要喷了
可笑的是连SGX543MP4+时脉多少还未知道
当2011Q1的OMAP4440(45nm)用的已是380MHz
还要拿着200MHz的数据来喷

敢情1/10-1/30是这么来的，彻底喷了，那人在论坛上红口白牙地一说，一无数据支持，二无环境说明，三无法证明此问题是由HSR失效导致，到了你这里就当真理宣传了，你真行……
说RSX的HSR是笑话是假HSR的是你不是我；说HSR开AA只剩1/7性能的是你不是我；后来转进到G70的HSR功能有限制的是你不是我；从论坛一无数据支持发言得出1/10-1/30的依然是你不是我；有意无视SGX的情况而搬出更早的某MBX甚至10多年前的PVR CLX2来给SGX543MP4当最后挡箭牌的是你不是我；说SGX543MP4+@200MHz的4000MP/s不是等效数字的还是你不是我，扯出Tegra2与什么频率200M、380M、之类的的依然是你不是我……
搞清楚谁在胡喷OK？

从我回的第一个帖子开始就在说同一个问题——麻烦你解释清楚怎么RSX的HSR性能只有1/7，怎么就只有1/10-1/30的fps，怎么就是笑话和假HSR——按照你后来的‘不支持Alpha test的HSR’这个标准，已推出的采用TBDR的产品，又有几款在HSR方面不是笑话，有几款是‘真HSR’？

[ 本帖最后由 hourousha 于 2011-2-4 19:03 编辑 ]

引用:

原帖由 JimmyC 于 2011-2-4 20:21 发表
G70及之前的只能coarse level Z and Stencil culling
G80及以後的才能fine-grained Z and Stencil culling
Course-grained Z: Course Z, Hierarchical Z, Hi-Z, or ZCULL
Fine-grained Z: Fine Z, Early Z, Early Z Checking, Early Z Out
好吧, 这不是阉割,
fine-grained Z and Stencil culling是多馀的
skip the shading of occluded pixels其实是没有用的垃圾功能
没有这的G70已经是完整的HSR
没有这的G70才是真HSR
有这的G80反而是假HSR
我这样说没错吧?

喷了，你这逻辑能力真成问题，G70的early-z有限制，但不是假HSR，更不是笑话，很简单，有37楼给出的测试结果为证，比你在这红口白牙地给HSR的真假与否，笑话与否胡乱下定义要强的多。
至于你说G80是假HSR，我只能佩服你的脑仁儿了，呵呵……

引用:

1/7, 1/10-30都是别人在G70使用HSR实际编程的结果,
Nvidia自然不会说白慢多少, 但随便搜一下也有很多这方面的讨论

很简单呐，要是所有的物体渲染我都用alpha blending来做（这没什么不可以，对不透明物体把alpha设为255就成了），并且把overdraw给做到100左右，那几乎所有硬件都慢成龟，你信不信？你拿错误的使用情况当真理还振振有词？

一个基本的事实是，支持不支持HSR对速度的影响，完全看场景的overdraw来定。没有一个统一的情况，Imgtec给出的典型值还是2.5呢，那按这数值的话，完全不支持HSR的消耗也就是2.5倍左右。
实际情况还要复杂得多，因为无论G70还是SGX，都可以对部分情况使用HSR而部分不行，那么实际情况就是不能使用HSR的那部分会有性能差别，做一个简单假设，比如总渲染时间中，55%花在solid obj上，15%花在alpha test obj上，20%花在alphablend obj上,剩下10%花在post processing上。而alpha test obj的overdraw假设是5——这个数不算小了吧。
第一部分是可以HSR的，第三部分是肯定任何硬件都无法HSR的而第四部分没有HSR的必要，区别在于第二部分，有些硬件可以HSR有些不可以，这会造成多大差别？差别就是渲染alpha test obj这部分会有5倍的时间差距。这个看起来不小，但是和总时间加一起算，也就是0.55+0.15*5+0.2+0.1=1.6倍的时间差距。我不知道你能否看明白。总之由于没有任何一个硬件可以在所有渲染流程部分都实现HSR，而G70在solid obj也支持HSR，所以G70的HSR的受限部分所造成的性能影响比该部分obj的overdraw要明显来的小。
简而言之，在正确使用的前提下，是绝对不可能出现1/7甚至更大的差距的。说的更绝对一点，在G70上写出仅由于HSR的限制而产生超过3倍以上fps差距的实用程序（并非理论测试程序），就都是废程序。

引用:

我放出讨论链结又被喷是搜回来的, 非官方不能作准
但我又不会写, 你怎样不自己写一点看看?
还有, MBX是五年前的产品
拿2005年USSE来喷2009年USSE2的不是你?

前面写给你了。看得懂看不懂就随便了。我倒要问问你，我后面对比HSR提的都是SGX，你哪只眼睛看到我用USSE喷USSE2了？我举SGX的原因很简单，因为似乎没什么正常人会认为PVR系列的HSR是假HSR，那么SGX不支持alpha test下的HSR说明alpha test下的HSR功能不是正常人判定HSR真假的依据。明白了么？
至于引用透明物体优化那段，别说USSE2，到了USSE8也是一样的优化手段，本来透明物体渲染就和HSR无缘。至于shader depth output情况也是一样，这部分本来就和early-z、HSR的应用相矛盾。
别听风就是雨，选择性摘段网上的无责任留言就当真理还到处宣传。

引用:

原帖由 JimmyC 于 2011-2-4 23:25 发表


你先看一下Course-grained Z和Fine-grained Z的归类
Course-grained Z: Course Z, Hierarchical Z, Hi-Z, or ZCULL
Fine-grained Z: Fine Z, Early Z, Early Z Checking, Early Z Out
然後究竟G70有没有Fine- ...

原来你又发现了新大陆，呵呵，可惜的是你只知其一不知其二。
这个early-z rejection指的是一种行为——也就是把‘本来就通不过z-test的fragment在进入fragment shader之前预先cull掉，避免不必要的运算’。至于不同级别的功能命名那是次要的，我在37楼也说明了NV的这方面不如同期的ATI产品。NV的这个从级别上更类似于ATI命名的Hierarchical Z——也就是相对粗粒度的cull——4x4 pixel quad，也就是实质相当于4x4个fragment的Z都failed z test时这4x4个fragments才会被cull掉。因此效率不如同期的ATI产品，从37楼的GL_Reme测试也能看到这种差距。
但是，虽然效率不足够高，但是行为的性质依然是early-z rejection，因为它的行为同样是在fragment shader前cull掉必然会fail掉Z-test的fragments。因此，至于它是叫early-z还是叫Hierarchical-Z还是叫Hidden Surface Removal都只是一个命名的问题。事实上在NV的G70 Doc里写的就是‘Early-Z Optimization’。原文如下：

引用:

Early-Z Optimization
Early-z optimization (sometimes called “z-cull”) improves performance by avoiding the rendering of occluded surfaces. If the occluded surfaces have expensive shaders applied to them, z-cull can save a large amount of computation time. To take advantage of z-cull, follow these guidelines:
Don’t create triangles with holes in them (that is, avoid alpha test or texkill)
Don’t modify depth (that is, allow the GPU to use the interpolated depth value)
Violating these rules can invalidate the data the GPU uses for early optimization, and can disable z-cull until the depth buffer is cleared again

至于test func反转失效也并不是判断Early-Z与否的必要条件，充其量是判断‘G80级别Early-Z的必要条件’罢了。
至于你说GL_Reme的测试有做假于出错的嫌疑，该怀疑过于naive，不予评论。

引用:

原帖由 JimmyC 于 2011-2-5 00:15 发表


以你的标准
现在连Tegra1支援也真HSR, 非阉割HSR了...
(Tegra支援early-z rejection)
哎...

这样的话我也无话可说了...

Tegra细节是啥我不清楚别和我扯这个。
RacingPHT在本论坛也有账号你直接问他关于这问题不就OK了？
他在那贴里明明也说了‘因为首先z-cull也可以算是early-z’。换句话说，G70的Z-Cull本身也是Early-Z,只不过后来G80出来了做了重新的命名来区分罢了，R-PHT的测试也是旨在验证G70是否有NV在G80定义的Early-Z功能。
再说一次，你所说的NV在G70 Doc里写的Early-Z，就是在G80后定义的Z-Cull，不同于G80里重新定义的Early-Z，但是两者功能是非常类似的，使用上的区别主要在于G80里的Early-Z效率更高，限制更少。
但G70的Z-Cull效率也可以，有测试为证。
如果你还不能明白，那就算了~

还在扯真假HSR？你能不那么幽默么？定义性能的高低很容易，但你怎么定义真还是假？嗯，ATI HD5870速度比HD4870速度快，所以HD5870是真GPU，HD4870是假GPU？你是这意思吗？
说起来你直接去问问RacingPHT，他开发PS3游戏的，你问问他RSX的HSR功能到底是不是笑话，是不是基本没法用，是不是1/10fps不就得了？

[ 本帖最后由 hourousha 于 2011-2-5 00:40 编辑 ]

引用:

原帖由 JimmyC 于 2011-2-5 00:55 发表
刚又找到SCEE的官方开发文档PDF 2009年版
在适当环境下, 依足步骤, 没有违反建议下, RSX的Early Z-cull可以足足省回10%GPU!
哈哈, 好吧, 我认了
RSX的HSR是"真"HSR, "非阉割"HSR
虽然效率只有G8X的一半
TBDR的六分一(依x2.5计算)

请贴10%的原文与前提条件，要是原场景的depth complexity就只有1或者渲染全是transparent obj，那还一点都省不了呢。少逗咳嗽了你

还乘2.5，还TBDR的六分之一喷了，你要不就是算术太棒，要不就是脑子太好，真是让人仰视。难怪得出200Mhz的SGXMP4+的4G填充率不是等效值这种神论。
我再义务教你一下数学，咱们假设（因为你没给出10%的前提）省10%前提是depth complexity也是2.5，且完全没有诸如alpha blending之类不能HSR的东西的干扰——这样才能充分体现RSX的HSR笑话水平么。
那么RSX的实际平均overdraw是2.5*(1-10%)=2.25，而TBDR的实际overdraw咱们按理想情况算是1，这时TBDR的HSR效率是RSX的2.25倍。2.5是这么用的你清楚了？

引用:

RSX 2 z/stencil
SGX543MP4+ 64 z/stencil
两者的实际HSR效率差了32倍
就算RSX的HSR仅能省回10%也好,
总之RSX的是"真"HSR, "非阉割"HSR就是

32倍原来是这么算，啧啧，看来你贴了半天都不清楚你说的coarse level Z and Stencil culling到底是啥意思。另外~你能解释一下2 z/stencil是什么么？是指z/stencil rop单元么呵呵……

引用:

话说回来, "PowerVR有TBDR有什麽了不起, RSX也有HSR＂这话题呢是谁开的?
现在有答案了, 呵呵

是谁开的呢？你说一下呗，帖子都在这摆着。

引用:

RacingPHT我不熟, 你可以问问看

我搜了一下论坛短消息，这问题我在08年就和他聊过，结论当然和你相反。你还真以为能有正常人附和你啊？

引用:

看你对CLX2在TBDR的同时对alpha test硬件加速一面怀疑

给出我怀疑PVR CLX2的连接，别急了眼就信口胡说啊……

引用:

其实beyond3d的讨论区就有Imgtec的员工长驻
说CLX2有alpha test硬件加速, 同时脉性能比Neon250高一倍的就是他
你可以问他究竟十二年前是怎样做到的
(虽然随便下一个DC模拟器已经可看到zwrite/alpha test zwrite的选项)

SimonF说的话我信，不过我想问问，PVR CLX2有alpha test+HSR，和我贴出的SGX没有alphatest+HSR矛盾在哪啊？难道CLX2有了alpha test就能否定前面贴的Insider FAQ吗？我前面说了我贴Insider FAQ的目的就是说明alphatest/shader discard并不是判断HSR真假的依据。注意你的理解能力~

引用:

原帖由 JimmyC 于 2011-2-5 15:08 发表
10%
没有, 原文那一頁, 就这六行, 你可以不信, 呵呵
Many games are fragment shaderbound
•Rendering Z only ‘primes’ the RSX™ Z-cull unit
–Very fast, 16 pixels/clock rather than 8
–Render entire scene,
–Or ‘large’ meshes only
–Easily save 10% GPU

从你这几句话能得到的情况就是，人家说的是在实际shader-bound的游戏应用中合理使用z-cull可以轻易节约10%的GPU。到了你这里就是z-cull的效率只有10%，你还真有才，58楼中间写的那段看来你又忽略了，竖子不可教也。

引用:

怎样不直接计算SGX和RSX受惠於TBDR/z-cull能省掉多少GPU?
RSX方面SCEE已直接给了省10%GPU这答案
SGX将400MP/s当1000MP/s用对吧?
省多少?怎样计算?我不知道, 呵

很简单的事实，理论测试是理论测试，实际应用是实际应用，那个2.5倍只是一个情况假设，不代表实际应用就可以节约60%的运算量——原因前面说了，一来不是所有render过程都可以HSR，诸如alpha blending肯定不行，大部分full screen post processing也不行，同时HSR无法降低VertexShader的工作负荷。这对unified shader结构的SGX系是有切实运算量影响的。所以实际情况是，绝对理想的HSR在整个渲染过程中对GPU消耗的降低也是低于不透明物体的depth complexity的。因此如Imgtec的假定不透明物体深度复杂性为2.5，但实际游戏使用中，哪怕不透明物体深度复杂性真是2.5，但最终也不可能达对比完全没有HSR硬件，到节省60%GPU资源或者说提速2.5倍的效果。
这是最后一次解释这个问题，还不明白的话你趁早闭嘴。
要想对比理论测试，那么37楼已经给出数据，你不去看我有何办法，就测试结果很明显，稍微算一下就能知道。
对于overdraw factor3的情况，等于z-cull起作用时渲染了(1+3)/（1+106%）= 194.1%的像素，也就是说cull效率是(400%-194.1%)/3 = 68.6%
对于overdraw factor8的情况，等于z-cull起作用时渲染了(1+8)/（1+265%）= 246.5%的像素，也就是说cull效率是(900%-246.5%)/8 = 81.6%
这个数字肯定不如TBDR接近100%的水平，也无法相比ATI同期产品X1800的水平（beyond3d同样有测试，计算后基本是92%+的效率），如果多边形极碎极小，那么效率还会下降。但你说这个数字很糟糕，是笑话，是假的形同于无。那也是纯粹扯淡。
咱可以假设个简单情况，在一个实际应用中，可HSR的solid obj在完全不使用HSR的情况中占用了60%的总渲染时间，这部分solid obj的深度复杂性是3。TBDR按100% HSR的效率计算，RSX按50%的效率计算。完全不考虑VertexShader的消耗。
那么对于TBDR HW，则开启HSR后时间变成了60%/3+40% = 60%
对于50% cull效率的HW，开启HSR后渲染时间变为原先的60%*(2/3)+0.4 = 80%
你不会算，我给你算了，在看懂前别再废话，OK？

引用:

拿十二年前的CLX2/六年前的MBX替USSE2说项不行
拿六年前的USSE喷USSE2就可以了, 呵呵

我只是说你拿老早的CLX2等给尚未具体出台的SGX543MP4+搅稀泥过于搞笑。你觉得行就行，嘿嘿。
请给出我拿USSE喷USSE2的证据。
‘alpha blend物体无法HSR’这是一个既成事实，在可预见的未来也将以事实继续存在，这和alpha blend的原理有关，和USSE或USSE2无关。这有什么问题？这叫拿USSE喷USSE2？稍微补点基础支持吧我说。
我引用Insider FAQ的那段你认为是针对USSE的透明物体优化tip，还真的就同样适用于任何GPU，你还别不信。
还有麻烦您别缩，我怀疑CLX2的证据在哪？

引用:

你不会看?

很简单，这话我没说也没传，所以谁说的让你不满意你找谁去，别跟我这递牙

引用:

就贴出来呀

没有贴私人聊天记录的习惯。也许这行为你擅长。那就请你去问他呗。

我说你就不能去看看我引用的那段Insider FAQ的内容么？不识英文是咋的？就算不识我后面不也紧接着概括了一下文章的意思么——就是把整个sprite分成‘透明’和非透明的两部分多边形集合（还有事先把完全透明的空白部分直接剔除），非透明的部分直接使用HSR渲染，透明的部分由于是从原来的整个sprite分离出来的，所以blending的面积比原先小，对性能冲击不太大。
也就是说那段说的是alpha blending优化的方法是由开发者事先做工作减少alpha blending的像素，别无他法。那段说的是alpha test么我说……faint!果然是回帖不看帖的主。

引用:

原帖由 JimmyC 于 2011-2-5 17:40 发表
问题1.
你信SimonF吗?

信

引用:

问题2.
CLX2/MBX到底有没有alpha test硬体加速?

MBX不清楚（是只是某个特别型号还是啥的没工夫去了解），CLX2可以。

引用:

问题3.
HSR渲染下能否对alpha test硬体加速?

有些硬件可以，有些硬件不成。

引用:

问题4.
Imgtec是否曾经掌握HSR渲染下对alpha test硬体加速的设计?

嗯，曾经掌握。

引用:

问题5.
为什麽你要用PowerVR Insider那段软件解决方法

因为那段说的是透明物体优化，也就是alpha blending物体优化。我为何不能引用，你前面不是也提到透明物体渲染了么？所以我说，alpha blending想用HSR优化还是省省吧。
顺便我提一句常识，在渲染流程中，alpha test物体是要是硬归类，也是归到在不透明物体范畴里的，或者单独一类，不应该归到透明物体范畴中。因为它们不像透明物体在渲染前需要按深度从后至前排序，互相之间也没有顺序依赖。明白？