[Mesa-dev] [RFC PATCH] mesa/st: don't prematurely optimize for render targets when on virgl

[Gert Wollny]

Am Dienstag, den 10.07.2018, 16:30 +0200 schrieb Erik Faye-Lund:
> > 
[snip]


> On 10. juli 2018 16:23, Gert Wollny wrote:
> > Since this is also written in the 4.5 spec, and the Intel driver
> > advertises this version, but the test to attach such a texture to a
> > frame buffer device results in an incomplete framebuffer, the Intel
> > driver is not up to spec or so it would seem ...
> 
> OpenGL has this other excape hatch, where it alllows drivers to say 
> FRAMEBUFFER_UNSUPPORTED for basically any combination of attachments
> it  doesn't like. Perhaps the Intel is using this as a way out? 
FRAMEBUFFER_UNSUPPORTED is exactly the error message that Intel shows. 

> If so, we  might have to be prepared to do something similar.
In any case, IMHO allocating a 3-comp texture should still try to
succeed without resorting to a four comp texture if possible (and if
render-target was not requested, then it would succeed, hence the way I
proposed the patch).

This is essentially what the Intel driver does: It gives you a texture
like requested without trying to be smart about it and  when you try to
use it as FBO attachment, it sais no. 

The other question is, of course, that gallium should not hit that
assertion ...  

> I don't think Gallium has a way of rejecting framebuffers in this
> way, though. So if that's what's going on, we might have to introduce
> one.
I guess I'll do a bit code-reading ... 

best, 
Gert