EXT_transform_feedback for ironlake

[mirh]

@nwnk @kaydenl I hope I am not to bother any one of you, though I just so read an IRC discussion of yours on the argument.

I'm not sure how much still into the thing you are, but I wanted to point out that a patchset for ILK hardware contexts already exist, but was never merged.
Together with chris's (that may or may not be entirely pushed?) I think at the very least OGL3 should be achievable?
EDIT: buddy that had corresponding laptop duped it, so I'm no longer that invested in the enterprise. Still wishing everybody best luck with this.

[kaydenl]

We could likely do transform feedback, but GL 3.0 requires multisampling, so we'd have to fake that somehow...either just lie and do single sampling, or do supersampling or something.

[mirh]

Mhh.. I had even read about your doubts over practical implications of this move (e.g. chrome).
Eventually though (and funnily maybe?) the thing is, that even when "hardware" multisample is supported, google team resolved to blacklist some intel chips because performance was nonetheless abysmal. See here.

Moreover, spec says minimum MAX_SAMPLES_EXT can be 1, so if this isn't checked it's developer's fault.

[kaydenl]

The GL 3.0 spec raises the minimum value of MAX_SAMPLES to 4.

[nwnk]

That extension says 1, but the GL 3.0 spec says 4 (see Table 6.51).

[mirh]

Uh, I see. Weird it's buried that hidden.

I guess like that could be disabled by default (behind drirc switch) maybe, or perhaps not, you are the experts.
Having at least gen5 "OGL 3 minus MSAA" rather than OGL3 minus *quite some things* would be already nice.

Not sure how much you could further strive the hardware then? Are we more in the 3.3 ballpark or "3.0 period"?

[nwnk]

I'm not actually a gen5 expert, so take this with whatever size salt grain is appropriate:

3.1 would require ARB_uniform_buffer_object and ARB_texture_buffer_object. Those are mostly software extensions, but gen5 might not actually have "uniform buffers" in hardware.

3.2 would additionally require ARB_texture_multisample, about which we could presumably get away with lying.

3.3 would require ARB_timer_query and ARB_blend_func_extended. gen5 might have enough hardware support for the former, but almost certainly doesn't have the latter (I assume, because it's just about trivial to enable if your hardware supports it, and the code doesn't enable it in GLES contexts either so it's probably just not there).

[mirh]

Cool, we are more there than we are not.
According to @chrisforbes itself up to 3.2 should be good (bar MSAA ofc).

Then, as per blend_func, this says it should be doable too.

[kaydenl]

Don't forget geometry shaders for 3.2.

[chrisforbes]

Merging the driver's GS with user GS is probably a bit of a nightmare, but maybe better than it would have been pre-nir when I was looking at this.

[mirh]

Also thanks to @ickle for latest work.
EDIT: progressing torvalds/linux@1215d28