Am 12.10.2011 19:35, schrieb Christoph Bumiller: > On 12.10.2011 19:17, Roland Scheidegger wrote: >> Am 12.10.2011 16:31, schrieb Christoph Bumiller: >>>> So do we need to go in and add PIPE_BIND_BLENDABLE to all of our >>>> existing surface-create calls in the state tracker, etc? >>>> >>> Well, that depends on whether we want to put blending fallbacks at the >>> state tracker level (OpenGL is probably the only API that requires them) >>> or let each driver handle them internally. >>> >>> Right now, drivers for GPUs that don't support blending on some formats >>> (e.g. DX10 level hardware for 16 bits per component or SNORM formats) >>> don't care much about doing fallbacks and silently ignore that blending >>> won't work (speaking at least for nv50 here). >>> >>> You pass the flag on resource creation, not surface creation, but since >>> surface creation can specify a different format, it applies only there. >>> >>> I should change the wording to: >>> "If this flag is set, surface creation may fail if blending is not >>> supported for the specified format. If it is not set, a driver may >>> choose to ignore blending on surfaces with formats that would require >>> emulation." >>> >>> That would leave it to the individual driver to choose whether to bother >>> with fallbacks or not. >> How do you emulate blending in some semi-sane way? Looks impossible to me. > > The best I can think of, short of software rendering (which the NV blob > does), is to render each primitive separately with a texture barrier in > between and performing the blend operation at the end of the fragment > shader. That, in contrast to software rendering, sounds potentially useful, but only if you have few large primitives, not really for the general case.
> >> Maybe if proprietary drivers don't do anything useful in that case (that >> is when they are asked to render to a surface with blending they don't >> support) we could just do the same. I don't consider software render >> fallbacks terribly useful hence my preference would be to just not ask >> for the PIPE_BLENDABLE flag when we don't know we need blending (which >> means in the OpenGL state tracker) and just ignore blending in the driver. > > That's what I'd prefer, not changing the GL state tracker at all. > > The presence of the BLENDABLE flag would imply strict checking of > blending functionality and allow drivers to either refuse to perform it > (surface creation to fail, such as with formats that are not supported > at all) or have to fall back to software (guarantee that it works), > while its absence merely indicates that the state tracker leaves it to > the driver to do what seems fit, which is what we have right now. > >> That's not very correct though but since the whole point seems to be you >> want to expose formats (in OpenGL) which aren't blendable and you don't >> expect blending to actually happen how could we do better? > > That, and also, as the comment in the patch says, give other state > trackers (especially d3d1x, which has a blending support query) a means > to check if blending would work / be slow, which, in my opinion, is > quite useful to have. Yes, this looks good to me. The OpenGL side will just be a bit sloppy but not much we can do about. Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
