[Mesa-dev] Ivybridge support for ARB_transform_feedback2

Ian Romanick idr at freedesktop.org
Tue Oct 22 19:07:37 CEST 2013


On 10/21/2013 11:48 AM, Kenneth Graunke wrote:
> On 10/21/2013 08:40 AM, Ian Romanick wrote:
>> On 10/17/2013 11:09 PM, Kenneth Graunke wrote:
>>> Here's my implementation of ARB_transform_feedback2.  I believe it's
>>> complete; it passes all of our Piglit tests and a lot of Intel's
>>> oglconform tests.
>>>
>>> This should work out of the box on Ivybridge and Baytrail.  It won't
>>> work on Haswell at the moment, due to restrictions on register writes
>>> (to be solved in a future kernel version).  Patch 9 will need to be
>>> replaced with something that detects whether or not we can write
>>> registers from userspace batchbuffers.
>>>
>>> In the meantime, I figured I'd send out the rest for review.
>>>
>>> Porting this back to Sandybridge is probably doable, but annoying.
>>> Sandybridge doesn't have the MI_LOAD_REGISTER_MEM command, so we'd have
>>> to map the buffers and use MI_LOAD_REGISTER_IMM.  Seems pretty gross.
>>> Plus, transform feedback is done very differently pre-Ivybridge.  I'm
>>> not sure it's worth it, seeing as it's a GL 4.0 feature.
>>
>> I assume this is just to support glDrawTransformFeedback?
> 
> No, it's to support glResumeTransformFeedback.

This is also part of OpenGL ES 3.0, so we need to fix it. :(

> glDrawTransformFeedback actually just reads pipeline statistics counters
> and leaves them free-running.
> 
>> Can you add that information to http://dri.freedesktop.org/wiki/I965Todo/ ?
> 
> Actually, I'm probably wrong...on Gen7 we use MI_LOAD_REGISTER_MEM to
> copy offsets into the SO_WRITE_OFFSET(n) registers.  But on Sandybridge,
> XFB is done using the geometry shader, so it works entirely differently.
>  I don't think there is a register to load.
> 
> I'll just let whoever looks into it figure it out.  Not much insight anyway.
> 
> --Ken



More information about the mesa-dev mailing list