Cross-regressions between wine and mesa: how to handle them?

[Ruslan Kabatsayev]

On Fri, Jan 31, 2014 at 2:27 AM, Henri Verbeet <hverbeet at gmail.com> wrote:
> On 30 January 2014 22:22, Stefan Dösinger <stefandoesinger at gmail.com> wrote:
>> I don't know about the extend this card support pixel shaders. There
>> may be a way for the driver and/or wine to work without falling back
>> to software. But overall I disagree with the premise of this patch.
>> There's a point in shipping a < GL 2.0 driver for hardware that just
>> doesn't support GL 2.0. But there is no point in requiring the
>> application to magically know if the driver's GL 2.0 is really 2.0 or
>> just something rigged with software fallback mines.
>>
>> Can you file a Mesa bug about this issue? I think we should ask the
>> Mesa devs about their opinion.
>>
> I don't know if that's specifically the issue here, but GL 2.0 also
> introduced point sprite coordinate origin switching. We need that when
> rendering offscreen, and I seem to recall i915 hitting a software
> fallback for that. Without GL 2.0 we'd just render incorrectly
> instead. It should be easy enough to rule that out by commenting out
> the "glPointParameteriNV(GL_POINT_SPRITE_COORD_ORIGIN, origin);" call
> in psorigin(). It's also generally useful to set INTEL_DEBUG=perf when
> investigating these kinds of things.

Indeed, you're right. If I return psorigin() before any GL calls are
made (first one, not NV one is effective, btw), then it works fast
enough.