On Fri, Jan 31, 2014 at 2:27 AM, Henri Verbeet hverbeet@gmail.com wrote:
On 30 January 2014 22:22, Stefan Dösinger stefandoesinger@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.