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. 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 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? Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
