On 07/31/2012 06:04 PM, Eric Anholt wrote:
> Fixes rendering in l4d2, which assumes sRGB capability without asking. We
> could convince the app to ask for sRGB, except that we don't expose visuals
> with sRGB currently. This gives the app the ability to choose sRGB rendering
> on the typical visual, without having to coordinate with the layer of software
> that's choosing the visual.
> ---
> src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 8 ++++++++
> src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 8 ++++++++
> src/mesa/drivers/dri/intel/intel_screen.c | 11 ++++++++++-
> 3 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> index 0744cc0..1b1b513 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -1118,6 +1118,14 @@ brw_update_renderbuffer_surface(struct brw_context
> *brw,
> else
> format = BRW_SURFACEFORMAT_B8G8R8A8_UNORM;
> break;
> +
> + case MESA_FORMAT_ARGB8888:
> + if (fb->Visual.sRGBCapable && ctx->Color.sRGBEnabled)
> + format = BRW_SURFACEFORMAT_B8G8R8A8_UNORM_SRGB;
> + else
> + format = BRW_SURFACEFORMAT_B8G8R8A8_UNORM;
> + break;
> +
> default:
> format = brw->render_target_format[rb_format];
> if (unlikely(!brw->format_supported_as_render_target[rb_format])) {
> diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> index 4c127ab..26fc24f 100644
> --- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> @@ -493,6 +493,14 @@ gen7_update_renderbuffer_surface(struct brw_context *brw,
> else
> surf->ss0.surface_format = BRW_SURFACEFORMAT_B8G8R8A8_UNORM;
> break;
> +
> + case MESA_FORMAT_ARGB8888:
> + if (fb->Visual.sRGBCapable && ctx->Color.sRGBEnabled)
> + surf->ss0.surface_format = BRW_SURFACEFORMAT_B8G8R8A8_UNORM_SRGB;
> + else
> + surf->ss0.surface_format = BRW_SURFACEFORMAT_B8G8R8A8_UNORM;
> + break;
> +
> default:
> assert(brw_render_target_supported(intel, rb));
> surf->ss0.surface_format = brw->render_target_format[rb_format];
> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
> b/src/mesa/drivers/dri/intel/intel_screen.c
> index e8a4ad1..49e0fb5 100644
> --- a/src/mesa/drivers/dri/intel/intel_screen.c
> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
> @@ -567,8 +567,17 @@ intelCreateBuffer(__DRIscreen * driScrnPriv,
> rgbFormat = MESA_FORMAT_RGB565;
> else if (mesaVis->alphaBits == 0)
> rgbFormat = MESA_FORMAT_XRGB8888;
> - else
> + else {
> + /* Allow sRGB rendering to this window, even without the app having
> + * requested an sRGB visual. Given that it's just a matter of
> + * flipping to MESA_FORMAT_SARGB8 when setting up the renderbuffer,
> + * there's little reason not to allow it.
> + *
> + * Otherwise, we'd have to make apps specifically request sRGB
> visuals and
> + */
You should probably finish your thought here. Otherwise, this seems
sensible.
Patches 2 and 3 are:
Reviewed-by: Kenneth Graunke <kenn...@whitecape.org>
It'd be nice to see acks from some other folks though.
> + fb->Visual.sRGBCapable = true;
> rgbFormat = MESA_FORMAT_ARGB8888;
> + }
>
> /* setup the hardware-based renderbuffers */
> rb = intel_create_renderbuffer(rgbFormat);
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
