[Mesa-dev] i915c vs i915g piglit run

[Marek Olšák]

It depends on what you need the sw fallback for. Stippling and
smoothing is accelerated. Maybe emulating fragment shaders with too
many instructions?

Marek

On Thu, Apr 18, 2013 at 3:11 AM, Eric Anholt <eric at anholt.net> wrote:
> Kenneth Graunke <kenneth at 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.
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>