Kenneth Graunke <kenn...@whitecape.org> writes: > On 04/17/2013 01:59 PM, Dave Airlie wrote: >> Hi, >> >> I put a 3Ghz Core2 Q35 box i found in the office to good use (so much >> nicer than a pineview atom). >> >> http://people.freedesktop.org/~airlied/piglit/i915c/ >> >> is a full run with i915c forced to advertise GL2.0 using the stub >> occlusion query hack in drirc, and i915g advertising GL2.1, and built >> against llvm 3.2. >> >> some quick regression analysis: >> >> blending regressions - fbo-blending-formats, glean blendFunc >> constant color is due to i915g advertising RGBA and BGRA support when >> the hw can't really do it, the blend color would need swizzling >> DST_ALPHA support - it seems we should smash the blend factors in this >> case to do DST_ALPHA->ONE if we have no alpha in the dst. (though the >> ALPHA* formats also seem to fail). >> >> sin/cos/tan - taylor series me more, but this could also be just >> broken as a link on irc pointed out. >> >> two-sided stencil - i915c seems to have a workaround for the hw not >> applying faces like other hw, i915g lacks this, hopefully that is the >> fix for two stencil ones >> >> array/matrix ones - i915g fails a lot of these we suspect due to >> overflowing instruction count due to inefficient GLSL/TGSI production. > > But that should just fall back to software, right?
I forgot that there was no plan for dealing with SW fallbacks on i915g. That kind of kills the whole proposal.
pgpnfLGqbcFkQ.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev