[Mesa-dev] [PATCH 5/8] main: enable NV_primitive_restart extension by default

[Jordan Justen]

On Fri, May 11, 2012 at 10:49 AM, Ian Romanick <idr at freedesktop.org> wrote:
> On 05/11/2012 10:35 AM, Marek Olšák wrote:
>> On Fri, May 11, 2012 at 7:17 PM, Brian Paul<brianp at vmware.com>  wrote:
>>> So setting MESA_EXTENSION_OVERRIDE=-GL_NV_primitive_restart should be an
>>> option.  The o(dummy_true) convention might prevent that, but I haven't
>>> tested that...
>>
>> In that case, I think we should disable it in the state tracker if
>> there's no driver support. If it's faster for svga, it's very likely
>> faster for the other DX9-level drivers too.
>
> I can imagine that it's certainly faster for hardware TNL cards. Mapping an
> index buffer that's probably in VRAM, scanning it on the CPU, then
> submitting multiple draw calls doesn't even sound like it would be fast.

Drivers can disable software support in one of two ways:
1. gallium: enable PIPE_CAP_PRIMITIVE_RESTART
2. set ctx->Const.PrimitiveRestartInSoftware = GL_FALSE,
   (similar to patch 3/8 which implements #1 for gallium)

The driver can still call vbo_sw_primitive_restart if they want to
take the software path.

> It also seems like the pure software paths might want to handle it directly
> in their index processing loop rather than chopping up the draw call before
> hand.

Do you mean it is better to not advertise the extension and let GL API
users handle this?

> The real value of these software paths is handling cases that the hardware
> can't do.  The GL spec allows any value to be specified for the restart
> index, but some hardware (*cough*) only supports ~0.

So, what is the consensus here?

I believe that state_tracker enables the NV_primitive_restart
extension for all gallium drivers currently, and enables software
support for drivers that don't advertise the support.

So, this changeset essentially mirrors that behaviour, but under vbo.

-Jordan