Re: [Mesa-dev] [PATCH 2/3] nv50: add more RGB10A2 formats
On Fri, Jan 17, 2014 at 2:48 AM, Ilia Mirkin wrote: > On Wed, Jan 15, 2014 at 6:37 AM, Ilia Mirkin wrote: >> On Wed, Dec 25, 2013 at 11:53 AM, Christoph Bumiller >> wrote: >>> --- >>> src/gallium/drivers/nouveau/nv50/nv50_formats.c | 7 +++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_formats.c >>> b/src/gallium/drivers/nouveau/nv50/nv50_formats.c >>> index 0a7e812..b301890 100644 >>> --- a/src/gallium/drivers/nouveau/nv50/nv50_formats.c >>> +++ b/src/gallium/drivers/nouveau/nv50/nv50_formats.c >>> @@ -202,6 +202,8 @@ const struct nv50_format >>> nv50_format_table[PIPE_FORMAT_COUNT] = >>> TBV, 1), >>> C4A(R10G10B10A2_SNORM, NONE, C0, C1, C2, C3, SNORM, 10_10_10_2, TV, 0), >>> C4A(B10G10R10A2_SNORM, NONE, C2, C1, C0, C3, SNORM, 10_10_10_2, TV, 1), >>> + C4A(R10G10B10A2_UINT, RGB10_A2_UINT, C0, C1, C2, C3, UINT, 10_10_10_2, >>> TRV, 0), >>> + C4A(B10G10R10A2_UINT, RGB10_A2_UINT, C2, C1, C0, C3, UINT, 10_10_10_2, >>> TV, 0), >>> >>> F3B(R11G11B10_FLOAT, R11G11B10_FLOAT, C0, C1, C2, xx, FLOAT, 11_11_10, >>> IB), >>> >>> @@ -394,6 +396,11 @@ const struct nv50_format >>> nv50_format_table[PIPE_FORMAT_COUNT] = >>> F1A(R16_SSCALED, NONE, C0, xx, xx, xx, SSCALED, 16, V), >>> F1A(R16_USCALED, NONE, C0, xx, xx, xx, USCALED, 16, V), >>> >>> + C4A(R10G10B10A2_USCALED, NONE, C0, C1, C2, C3, USCALED, 10_10_10_2, V, >>> 0), >>> + C4A(R10G10B10A2_SSCALED, NONE, C0, C1, C2, C3, SSCALED, 10_10_10_2, V, >>> 0), >>> + C4A(B10G10R10A2_USCALED, NONE, C0, C1, C2, C3, USCALED, 10_10_10_2, V, >>> 1), >>> + C4A(B10G10R10A2_SSCALED, NONE, C0, C1, C2, C3, SSCALED, 10_10_10_2, V, >>> 1), >>> + >>> C4A(R8G8B8A8_SSCALED, NONE, C0, C1, C2, C3, SSCALED, 8_8_8_8, V, 0), >>> C4A(R8G8B8A8_USCALED, NONE, C0, C1, C2, C3, USCALED, 8_8_8_8, V, 0), >>> F3A(R8G8B8_UNORM, NONE, C0, C1, C2, xx, UNORM, 8_8_8, V), >> >> FWIW I ran piglit on this (with your other patches that cause the >> RGB10A2 extensions to actually be turned on), and I saw this failure: >> >> $ bin/draw-vertices-2101010 -auto >> Int vertices - 2/10/10/10 >> Unsigned Int vertices - 2/10/10/10 >> Int Color - 2/10/10/10 >> Probe color at (45,5) >> Expected: 1.00 0.00 0.00 0.333000 >> Observed: 1.00 0.00 0.00 0.00 >> Unsigned Int Color - 2/10/10/10 >> Int BGRA Color - 2/10/10/10 >> Probe color at (85,5) >> Expected: 0.00 0.00 1.00 0.333000 >> Observed: 0.00 0.00 1.00 0.00 >> Unsigned Int BGRA Color - 2/10/10/10 >> Int 2/10/10/10 - test ABI >> Unsigned 2/10/10/10 - test ABI > > BTW, I tried to look into this... > > (a) Shouldn't the second C4A in the first hunk have a 1 for the BGRA > bit? And similarly, shouldn't the components be flipped for the BGRA > formats in the second hunk? Doing this made the > GL_ARB_texture_rgb10_a2ui tests pass (well, mostly -- projective mode, > whatever that is, still doesn't work, but that wasn't tested before) Erm, nevermind. I must have been testing it on llvmpipe somehow... my bad. Everything still fails with those changes too :) But it does work on llvmpipe for the texwrap bordercolor/swizzled tests. But again, that might be because we don't handle bordercolor correctly or something. > > (b) I think that the draw-vertices test might be broken, but not in > any way that matters: > - its i32to2 function is wrong. but it's fine for 0 which is what's > being passed in > - 0 for a signed (2's complement) A2 component should become > 0.6, not 0.3. I think. It's the third of 4 values -- -2, -1, > 0, 1. But that's not what we're seeing anyways. > > (c) When I ran on the blob earlier, it had identical failures, and so > does llvmpipe. > >> >> There were also ARB_texture_rgb10_a2ui failures with texwrap >> bordercolor's, but there are lots of other such failures with integer >> formats, so I assume that's all part of the same thing. For reference: >> >> $ bin/texwrap GL_ARB_texture_rgb10_a2ui bordercolor -fbo -auto >> Testing GL_ARB_texture_rgb10_a2ui. >> Testing the border color only. >> Testing GL_RGB10_A2UI, border color only >> Fail with NEAREST and CLAMP_TO_BORDER at (95,36) @ 0,0 >> Expected: 25 229 127 170 >> Observed: 0 0 0 0 >> Fail with NEAREST and MIRROR_CLAMP_TO_BORDER_EXT at (273,36) @ 0,0 >> Expected: 25 229 127 170 >> Observed: 0 0 0 0 >> >> $ bin/texwrap GL_ARB_texture_rgb10_a2ui bordercolor swizzled -fbo -auto >> Testing GL_ARB_texture_rgb10_a2ui. >> Testing the border color only. >> Using texture swizzling. >> Testing GL_RGB10_A2UI, swizzled, border color only >> Fail with NEAREST and CLAMP_TO_BORDER at (95,36) @ 0,0 >> Expected: 127 25 229 170 >> Observed: 0 0 0 0 >> Fail with NEAREST and MIRROR_CLAMP_TO_BORDER_EXT at (273,36) @ 0,0 >> Expected: 127 25 229 170 >> Observed: 0 0 0 0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/vdpau: check that the format/bindings are valid
Am 17.01.2014 04:19, schrieb Ilia Mirkin:
It's a bit unreasonable to rely on applications doing the queries and
then obeying their results.
Apart from a minor style comment (see below) the patch looks good to me,
but isn't that a bit superfluous? I mean if the format isn't supported
resource_create should probably return NULL anyway.
Signed-off-by: Ilia Mirkin
---
We're starting to see people complaining about flash with newer versions of
nouveau on nv30 cards. These cards don't actually expose any hw caps via
vdpau, but the API is still free to use the surfaces/etc. We were seeing some
errors in the logs that appear to only be able to happen if someone has
managed to create an illegal-type surface. (And nv30 is pretty limited in its
supported renderable format list.)
Or is it just that you guys print en error message to stderr when the
format isn't supported and you want to suppress that?
This adds checks to make sure that the surfaces are valid for the screen in
question. Hopefully I haven't misunderstood gallium or the vdpau state
tracker... My quick test with mplayer (but without hw accel) seems to work.
src/gallium/state_trackers/vdpau/bitmap.c| 5 +++--
src/gallium/state_trackers/vdpau/output.c| 16 ++--
src/gallium/state_trackers/vdpau/vdpau_private.h | 8
3 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/bitmap.c
b/src/gallium/state_trackers/vdpau/bitmap.c
index 469f3e8..24dbc42 100644
--- a/src/gallium/state_trackers/vdpau/bitmap.c
+++ b/src/gallium/state_trackers/vdpau/bitmap.c
@@ -43,7 +43,7 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
VdpBitmapSurface *surface)
{
struct pipe_context *pipe;
- struct pipe_resource res_tmpl, *res;
+ struct pipe_resource res_tmpl, *res = NULL;
struct pipe_sampler_view sv_templ;
vlVdpBitmapSurface *vlsurface = NULL;
@@ -79,7 +79,8 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
res_tmpl.usage = frequently_accessed ? PIPE_USAGE_DYNAMIC :
PIPE_USAGE_STATIC;
pipe_mutex_lock(dev->mutex);
- res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
+ if (CheckSurfaceParams(pipe->screen, &res_tmpl))
+ res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
I would rather code it like this:
if (!CheckSurfaceParams(pipe->screen, &res_tmpl))
goto error_not supported;
It's a bit more obvious when you don't know the code.
That off course implies that we have error handling coded like this,
feel free to change it if it isn't.
Christian.
if (!res) {
pipe_mutex_unlock(dev->mutex);
FREE(dev);
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index e4e1433..76c4611 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -48,7 +48,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
VdpOutputSurface *surface)
{
struct pipe_context *pipe;
- struct pipe_resource res_tmpl, *res;
+ struct pipe_resource res_tmpl, *res = NULL;
struct pipe_sampler_view sv_templ;
struct pipe_surface surf_templ;
@@ -83,7 +83,9 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
res_tmpl.usage = PIPE_USAGE_STATIC;
pipe_mutex_lock(dev->mutex);
- res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
+
+ if (CheckSurfaceParams(pipe->screen, &res_tmpl))
+ res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
if (!res) {
pipe_mutex_unlock(dev->mutex);
FREE(dev);
@@ -117,7 +119,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
FREE(dev);
return VDP_STATUS_ERROR;
}
-
+
pipe_resource_reference(&res, NULL);
vl_compositor_init_state(&vlsurface->cstate, pipe);
@@ -278,7 +280,7 @@ vlVdpOutputSurfacePutBitsIndexed(VdpOutputSurface surface,
enum pipe_format index_format;
enum pipe_format colortbl_format;
- struct pipe_resource *res, res_tmpl;
+ struct pipe_resource *res = NULL, res_tmpl;
struct pipe_sampler_view sv_tmpl;
struct pipe_sampler_view *sv_idx = NULL, *sv_tbl = NULL;
@@ -326,7 +328,8 @@ vlVdpOutputSurfacePutBitsIndexed(VdpOutputSurface surface,
pipe_mutex_lock(vlsurface->device->mutex);
vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL);
- res = context->screen->resource_create(context->screen, &res_tmpl);
+ if (CheckSurfaceParams(context->screen, &res_tmpl))
+ res = context->screen->resource_create(context->screen, &res_tmpl);
if (!res)
goto error_resource;
@@ -359,7 +362,8 @@ vlVdpOutputSurfacePutBitsIndexed(VdpOutputSurface surface,
res_tmpl.usage = PIPE_USAGE_STAGING;
res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW;
- res = context->screen->resource_create(context->screen, &res_tmpl);
+ if (CheckSurfaceParams(context->screen, &res_tmpl))
+ res = context->scr
Re: [Mesa-dev] [V3 PATCH 0/8] mesa: Naming MESA_FORMATs to a specification
I haven't followed the discussion so I can't judge weather or not this is a good idea. But as a general note on writing patches: Please limit the subject line to a sane length! Something between 60 and 80 chars should be ok. Thanks, Christian. Am 17.01.2014 07:37, schrieb Mark Mueller: This series introduces a specification for 3 types of MESA_FORMAT names - Type A (array formats), Type C (compressed formats), and Type P (packed formats), and then performs a series of substitutions grouped by type. Builds of all default gallium and DRI drivers were verified and no regressions were observed w/piglit tests on the i965 driver. The format_unpack functions were used to verify component orders, except with some _REV formats, which appeared to be incorrect, but not used in normal testing. Mark Mueller (8): 1 's/\bgl_format\b/mesa_format/g'. Use better name for Mesa Formats enum 2 Change all 4 color component unsigned byte formats to meet spec: s/MESA_FORMAT_RGBA\b/MESA_FORMAT_ABGR_UNORM8/g s/MESA_FORMAT_RGBA_REV\b/MESA_FORMAT_RGBA_UNORM8/g s/MESA_FORMAT_ARGB\b/MESA_FORMAT_BGRA_UNORM8/g s/MESA_FORMAT_ARGB_REV\b/MESA_FORMAT_ARGB_UNORM8/g s/MESA_FORMAT_RGBX\b/MESA_FORMAT_XBGR_UNORM8/g s/MESA_FORMAT_RGBX_REV\b/MESA_FORMAT_RGBX_UNORM8/g s/MESA_FORMAT_XRGB\b/MESA_FORMAT_BGRX_UNORM8/g s/MESA_FORMAT_XRGB_REV\b/MESA_FORMAT_XRGB_UNORM8/g 3 Update comments. Conversion of the following Type A formats: s/MESA_FORMAT_RGB888\b/MESA_FORMAT_BGR_UNORM8/g s/MESA_FORMAT_BGR888\b/MESA_FORMAT_RGB_UNORM8/g s/MESA_FORMAT_AL88\b/MESA_FORMAT_LA_UNORM8/g s/MESA_FORMAT_AL88_REV\b/MESA_FORMAT_AL_UNORM8/g s/MESA_FORMAT_AL1616\b/MESA_FORMAT_LA_UNORM16/g s/MESA_FORMAT_AL1616_REV\b/MESA_FORMAT_AL_UNORM16/g s/MESA_FORMAT_A8\b/MESA_FORMAT_A_UNORM8/g s/MESA_FORMAT_A16\b/MESA_FORMAT_A_UNORM16/g s/MESA_FORMAT_L8\b/MESA_FORMAT_L_UNORM8/g s/MESA_FORMAT_L16\b/MESA_FORMAT_L_UNORM16/g s/MESA_FORMAT_I8\b/MESA_FORMAT_I_UNORM8/g s/MESA_FORMAT_I16\b/MESA_FORMAT_I_UNORM16/g s/MESA_FORMAT_R8\b/MESA_FORMAT_R_UNORM8/g s/MESA_FORMAT_GR88\b/MESA_FORMAT_RG_UNORM8/g s/MESA_FORMAT_RG88\b/MESA_FORMAT_GR_UNORM8/g s/MESA_FORMAT_R16\b/MESA_FORMAT_R_UNORM16/g s/MESA_FORMAT_GR1616\b/MESA_FORMAT_RG_UNORM16/g s/MESA_FORMAT_RG1616\b/MESA_FORMAT_GR_UNORM16/g s/MESA_FORMAT_Z16\b/MESA_FORMAT_Z_UNORM16/g s/MESA_FORMAT_Z32\b/MESA_FORMAT_Z_UNORM32/g s/MESA_FORMAT_S8\b/MESA_FORMAT_S_UINT8/g s/MESA_FORMAT_SRGBA8\b/MESA_FORMAT_SABGR_UNORM8/g s/MESA_FORMAT_SRGB8\b/MESA_FORMAT_SBGR_UNORM8/g s/MESA_FORMAT_SARGB8\b/MESA_FORMAT_SBGRA_UNORM8/g s/MESA_FORMAT_SL8\b/MESA_FORMAT_SL_UNORM8/g s/MESA_FORMAT_SLA8\b/MESA_FORMAT_SLA_UNORM8/g s/MESA_FORMAT_Z32_FLOAT\b/MESA_FORMAT_Z_FLOAT32/g 4 Conversion of Type P formats as follows (w/related comment fixes): s/\bMESA_FORMAT_RGB565\b/MESA_FORMAT_B5G6R5_UNORM/g s/\bMESA_FORMAT_RGB565_REV\b/MESA_FORMAT_R5G6B5_UNORM/g s/\bMESA_FORMAT_ARGB\b/MESA_FORMAT_B4G4R4A4_UNORM/g s/\bMESA_FORMAT_ARGB_REV\b/MESA_FORMAT_A4R4G4B4_UNORM/g s/\bMESA_FORMAT_RGBA5551\b/MESA_FORMAT_A1B5G5R5_UNORM/g s/\bMESA_FORMAT_ARGB1555\b/MESA_FORMAT_B5G5R5A1_UNORM/g s/\bMESA_FORMAT_ARGB1555_REV\b/MESA_FORMAT_A1R5G5B5_UNORM/g s/\bMESA_FORMAT_AL44\b/MESA_FORMAT_L4A4_UNORM/g s/\bMESA_FORMAT_RGB332\b/MESA_FORMAT_B2G3R3_UNORM/g s/\bMESA_FORMAT_ARGB2101010\b/MESA_FORMAT_B10G10R10A2_UNORM/g s/\bMESA_FORMAT_Z24_S8\b/MESA_FORMAT_S8_UINT_Z24_UNORM/g s/\bMESA_FORMAT_S8_Z24\b/MESA_FORMAT_Z24_UNORM_S8_UINT/g s/\bMESA_FORMAT_X8_Z24\b/MESA_FORMAT_Z24_UNORM_X8_UINT/g s/\bMESA_FORMAT_Z24_X8\b/MESA_FORMAT_X8Z24_UNORM/g s/\bMESA_FORMAT_RGB9_E5_FLOAT\b/MESA_FORMAT_R9G9B9E5_FLOAT/g s/\bMESA_FORMAT_R11_G11_B10_FLOAT\b/MESA_FORMAT_R11G11B10_FLOAT/g s/\bMESA_FORMAT_Z32_FLOAT_X24S8\b/MESA_FORMAT_Z32_FLOAT_S8X24_UINT/g s/\bMESA_FORMAT_ABGR2101010_UINT\b/MESA_FORMAT_R10G10B10A2_UINT/g s/\bMESA_FORMAT_XRGB_UNORM\b/MESA_FORMAT_B4G4R4X4_UNORM/g s/\bMESA_FORMAT_XRGB1555_UNORM\b/MESA_FORMAT_B5G5R5X1_UNORM/g s/\bMESA_FORMAT_XRGB2101010_UNORM\b/MESA_FORMAT_B10G10R10X2_UNORM/g 5 Compressed spelled out color components ALPHA, INTENSITY, and LUMINANCE to A, I, and L: s/\bMESA_FORMAT_ALPHA_UINT8\b/MESA_FORMAT_A_UINT8/g s/\bMESA_FORMAT_ALPHA_UINT16\b/MESA_FORMAT_A_UINT16/g s/\bMESA_FORMAT_ALPHA_UINT32\b/MESA_FORMAT_A_UINT32/g s/\bMESA_FORMAT_ALPHA_INT32\b/MESA_FORMAT_A_INT32/g s/\bMESA_FORMAT_ALPHA_INT16\b/MESA_FORMAT_A_INT16/g s/\bMESA_FORMAT_ALPHA_INT8\b/MESA_FORMAT_A_INT8/g s/\bMESA_FORMAT_INTESITY_UINT8\b/MESA_FORMAT_I_UINT8/g s/\bMESA_FORMAT_INTESITY_UINT16\b/MESA_FORMAT_I_UINT16/g s/\bMESA_FORMAT_INTESITY_UINT32\b/MESA_FORMAT_I_UINT32/g s/\bMESA_FORMAT_INTESITY_INT32\b/MESA_FORMAT_I_INT3
Re: [Mesa-dev] [PATCH] st/vdpau: check that the format/bindings are valid
On Fri, Jan 17, 2014 at 3:19 AM, Christian König
wrote:
> Am 17.01.2014 04:19, schrieb Ilia Mirkin:
>
>> It's a bit unreasonable to rely on applications doing the queries and
>> then obeying their results.
>
>
> Apart from a minor style comment (see below) the patch looks good to me, but
> isn't that a bit superfluous? I mean if the format isn't supported
> resource_create should probably return NULL anyway.
Maybe? My understanding was that we weren't supposed to check for
error conditions like that, and indeed none of the nouveau drivers do.
Is that what should be happening? I heard somewhere that the idea of
gallium was not to check for illegal conditions, when there are
explicit things like is_format_supported going on. Should every
resource_create call start with if (!is_format_supported) return NULL?
I looked at a few drivers and it didn't seem like they did that, but I
could have missed it.
>
>
>
>>
>> Signed-off-by: Ilia Mirkin
>> ---
>>
>> We're starting to see people complaining about flash with newer versions
>> of
>> nouveau on nv30 cards. These cards don't actually expose any hw caps via
>> vdpau, but the API is still free to use the surfaces/etc. We were seeing
>> some
>> errors in the logs that appear to only be able to happen if someone has
>> managed to create an illegal-type surface. (And nv30 is pretty limited in
>> its
>> supported renderable format list.)
>
>
> Or is it just that you guys print en error message to stderr when the format
> isn't supported and you want to suppress that?
dmesg, actually, when the card reports, via interrupt, that an invalid
value was written to a method. It also causes rendering to break.
>
>
>>
>> This adds checks to make sure that the surfaces are valid for the screen
>> in
>> question. Hopefully I haven't misunderstood gallium or the vdpau state
>> tracker... My quick test with mplayer (but without hw accel) seems to
>> work.
>>
>> src/gallium/state_trackers/vdpau/bitmap.c| 5 +++--
>> src/gallium/state_trackers/vdpau/output.c| 16 ++--
>> src/gallium/state_trackers/vdpau/vdpau_private.h | 8
>> 3 files changed, 21 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/vdpau/bitmap.c
>> b/src/gallium/state_trackers/vdpau/bitmap.c
>> index 469f3e8..24dbc42 100644
>> --- a/src/gallium/state_trackers/vdpau/bitmap.c
>> +++ b/src/gallium/state_trackers/vdpau/bitmap.c
>> @@ -43,7 +43,7 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
>>VdpBitmapSurface *surface)
>> {
>> struct pipe_context *pipe;
>> - struct pipe_resource res_tmpl, *res;
>> + struct pipe_resource res_tmpl, *res = NULL;
>> struct pipe_sampler_view sv_templ;
>>vlVdpBitmapSurface *vlsurface = NULL;
>> @@ -79,7 +79,8 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
>> res_tmpl.usage = frequently_accessed ? PIPE_USAGE_DYNAMIC :
>> PIPE_USAGE_STATIC;
>>pipe_mutex_lock(dev->mutex);
>> - res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
>> + if (CheckSurfaceParams(pipe->screen, &res_tmpl))
>> + res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
>
>
> I would rather code it like this:
>
> if (!CheckSurfaceParams(pipe->screen, &res_tmpl))
> goto error_not supported;
>
> It's a bit more obvious when you don't know the code.
>
> That off course implies that we have error handling coded like this, feel
> free to change it if it isn't.
OK, will update and resend.
>
> Christian.
>
>
>> if (!res) {
>> pipe_mutex_unlock(dev->mutex);
>> FREE(dev);
>> diff --git a/src/gallium/state_trackers/vdpau/output.c
>> b/src/gallium/state_trackers/vdpau/output.c
>> index e4e1433..76c4611 100644
>> --- a/src/gallium/state_trackers/vdpau/output.c
>> +++ b/src/gallium/state_trackers/vdpau/output.c
>> @@ -48,7 +48,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>>VdpOutputSurface *surface)
>> {
>> struct pipe_context *pipe;
>> - struct pipe_resource res_tmpl, *res;
>> + struct pipe_resource res_tmpl, *res = NULL;
>> struct pipe_sampler_view sv_templ;
>> struct pipe_surface surf_templ;
>> @@ -83,7 +83,9 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>> res_tmpl.usage = PIPE_USAGE_STATIC;
>>pipe_mutex_lock(dev->mutex);
>> - res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
>> +
>> + if (CheckSurfaceParams(pipe->screen, &res_tmpl))
>> + res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
>> if (!res) {
>> pipe_mutex_unlock(dev->mutex);
>> FREE(dev);
>> @@ -117,7 +119,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>> FREE(dev);
>> return VDP_STATUS_ERROR;
>> }
>> -
>> +
>> pipe_resource_reference(&res, NULL);
>>vl_compositor_init_state(&vlsurface->cstate, pipe);
>> @@ -278,7 +280,7 @@ vlVdpOutputSurfacePutBitsIndexed(VdpOutputSurface
>> surface,
>> enum pipe_format index_format;
>> enum
Re: [Mesa-dev] [PATCH] st/vdpau: check that the format/bindings are valid
Am 17.01.2014 09:37, schrieb Ilia Mirkin:
On Fri, Jan 17, 2014 at 3:19 AM, Christian König
wrote:
Am 17.01.2014 04:19, schrieb Ilia Mirkin:
It's a bit unreasonable to rely on applications doing the queries and
then obeying their results.
Apart from a minor style comment (see below) the patch looks good to me, but
isn't that a bit superfluous? I mean if the format isn't supported
resource_create should probably return NULL anyway.
Maybe? My understanding was that we weren't supposed to check for
error conditions like that, and indeed none of the nouveau drivers do.
Is that what should be happening? I heard somewhere that the idea of
gallium was not to check for illegal conditions, when there are
explicit things like is_format_supported going on. Should every
resource_create call start with if (!is_format_supported) return NULL?
I looked at a few drivers and it didn't seem like they did that, but I
could have missed it.
Good argument. Sounds like you're right we should probably check that in
the state tracker than.
Signed-off-by: Ilia Mirkin
---
We're starting to see people complaining about flash with newer versions
of
nouveau on nv30 cards. These cards don't actually expose any hw caps via
vdpau, but the API is still free to use the surfaces/etc. We were seeing
some
errors in the logs that appear to only be able to happen if someone has
managed to create an illegal-type surface. (And nv30 is pretty limited in
its
supported renderable format list.)
Or is it just that you guys print en error message to stderr when the format
isn't supported and you want to suppress that?
dmesg, actually, when the card reports, via interrupt, that an invalid
value was written to a method. It also causes rendering to break.
This adds checks to make sure that the surfaces are valid for the screen
in
question. Hopefully I haven't misunderstood gallium or the vdpau state
tracker... My quick test with mplayer (but without hw accel) seems to
work.
src/gallium/state_trackers/vdpau/bitmap.c| 5 +++--
src/gallium/state_trackers/vdpau/output.c| 16 ++--
src/gallium/state_trackers/vdpau/vdpau_private.h | 8
3 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/bitmap.c
b/src/gallium/state_trackers/vdpau/bitmap.c
index 469f3e8..24dbc42 100644
--- a/src/gallium/state_trackers/vdpau/bitmap.c
+++ b/src/gallium/state_trackers/vdpau/bitmap.c
@@ -43,7 +43,7 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
VdpBitmapSurface *surface)
{
struct pipe_context *pipe;
- struct pipe_resource res_tmpl, *res;
+ struct pipe_resource res_tmpl, *res = NULL;
struct pipe_sampler_view sv_templ;
vlVdpBitmapSurface *vlsurface = NULL;
@@ -79,7 +79,8 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
res_tmpl.usage = frequently_accessed ? PIPE_USAGE_DYNAMIC :
PIPE_USAGE_STATIC;
pipe_mutex_lock(dev->mutex);
- res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
+ if (CheckSurfaceParams(pipe->screen, &res_tmpl))
+ res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
I would rather code it like this:
if (!CheckSurfaceParams(pipe->screen, &res_tmpl))
goto error_not supported;
It's a bit more obvious when you don't know the code.
That off course implies that we have error handling coded like this, feel
free to change it if it isn't.
OK, will update and resend.
With that fixed the patch has my rb.
Christian.
Christian.
if (!res) {
pipe_mutex_unlock(dev->mutex);
FREE(dev);
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index e4e1433..76c4611 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -48,7 +48,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
VdpOutputSurface *surface)
{
struct pipe_context *pipe;
- struct pipe_resource res_tmpl, *res;
+ struct pipe_resource res_tmpl, *res = NULL;
struct pipe_sampler_view sv_templ;
struct pipe_surface surf_templ;
@@ -83,7 +83,9 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
res_tmpl.usage = PIPE_USAGE_STATIC;
pipe_mutex_lock(dev->mutex);
- res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
+
+ if (CheckSurfaceParams(pipe->screen, &res_tmpl))
+ res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
if (!res) {
pipe_mutex_unlock(dev->mutex);
FREE(dev);
@@ -117,7 +119,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
FREE(dev);
return VDP_STATUS_ERROR;
}
-
+
pipe_resource_reference(&res, NULL);
vl_compositor_init_state(&vlsurface->cstate, pipe);
@@ -278,7 +280,7 @@ vlVdpOutputSurfacePutBitsIndexed(VdpOutputSurface
surface,
enum pipe_format index_format;
enum pipe_format colortbl_format;
- struct pipe_resource *r
Re: [Mesa-dev] [V3 PATCH 0/8] mesa: Naming MESA_FORMATs to a specification
On Fri, Jan 17, 2014 at 9:22 AM, Christian König wrote: > But as a general note on writing patches: Please limit the subject line to a > sane length! Something between 60 and 80 chars should be ok. Indeed. The regex patterns are nice to have. But please, put them in the *body* of the commit message. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] docs: Update GL3.txt due to recent work
On Thursday 16 January 2014, Matt Turner wrote: > On Thu, Jan 16, 2014 at 10:44 AM, Ian Romanick wrote: > > From: Ian Romanick > > > > Signed-off-by: Ian Romanick > > --- > > docs/GL3.txt | 18 +- > > 1 file changed, 9 insertions(+), 9 deletions(-) > > > > diff --git a/docs/GL3.txt b/docs/GL3.txt > > index 0672ec7..be78652 100644 > > --- a/docs/GL3.txt > > +++ b/docs/GL3.txt > > @@ -55,7 +55,7 @@ GL 3.1 --- all DONE: i965, nv50, nvc0, r600, radeonsi > >Forward compatible context support/deprecations DONE () > >Instanced drawing (GL_ARB_draw_instanced) DONE (swrast) > >Buffer copying (GL_ARB_copy_buffer) DONE (r300, swrast) > > - Primitive restart (GL_NV_primitive_restart) DONE (r300, ) > > + Primitive restart (GL_NV_primitive_restart) DONE (r300) > >16 vertex texture image units DONE () > >Texture buffer objs (GL_ARB_texture_buffer_object)DONE for OpenGL > > 3.1 contexts () > >Rectangular textures (GL_ARB_texture_rectangle) DONE (r300, swrast) > > @@ -83,9 +83,9 @@ GL 3.3 --- all DONE: i965 > > > >GLSL 3.30 DONE () > >GL_ARB_blend_func_extendedDONE (nv50, nvc0, > > r600, radeonsi, softpipe) > > - GL_ARB_explicit_attrib_location DONE (i915, nv50, > > nvc0, r300, r600, radeonsi, swrast) > > + GL_ARB_explicit_attrib_location DONE (all drivers > > that support GLSL) > >GL_ARB_occlusion_query2 DONE (nv50, nvc0, > > r300, r600, radeonsi, swrast) > > - GL_ARB_sampler_objectsDONE (nv50, nvc0, > > r300, r600, radeonsi) > > + GL_ARB_sampler_objectsDONE (all drivers) > >GL_ARB_shader_bit_encodingDONE (nv50, nvc0, > > r600, radeonsi) > >GL_ARB_texture_rgb10_a2ui DONE (r600, > > radeonsi) > >GL_ARB_texture_swizzleDONE (nv50, nvc0, > > r300, r600, radeonsi, swrast) > > @@ -117,10 +117,10 @@ GL 4.1: > >GLSL 4.1 not started > >GL_ARB_ES2_compatibility DONE (i965, r300, > > r600, radeonsi) > >GL_ARB_get_program_binaryDONE (0 binary > > formats) > > - GL_ARB_separate_shader_objects some infrastructure > > done > > + GL_ARB_separate_shader_objects started (Ian > > Romanick, Gregory Hainaut) > >GL_ARB_shader_precision not started > >GL_ARB_vertex_attrib_64bit not started > > - GL_ARB_viewport_arraynot started > > + GL_ARB_viewport_arraystarted (Ian > > Romanick, Courtney Goeltzenleuchter) > > > > > > GL 4.2: > > @@ -144,8 +144,8 @@ GL 4.3: > >GLSL 4.3 not started > >GL_ARB_arrays_of_arrays not started > >GL_ARB_ES3_compatibility DONE (i965) > > - GL_ARB_clear_buffer_object not started > > - GL_ARB_compute_shadernot started > > + GL_ARB_clear_buffer_object DONE (all drivers) > > + GL_ARB_compute_shaderstarted (Paul Berry) > >GL_ARB_copy_imagenot started > >GL_KHR_debug DONE (all drivers) > >GL_ARB_explicit_uniform_location not started > > @@ -162,7 +162,7 @@ GL 4.3: > >GL_ARB_texture_buffer_range DONE (nv50, nvc0, > > i965, r600, radeonsi) > >GL_ARB_texture_query_levels DONE (i965) > >GL_ARB_texture_storage_multisample DONE (all drivers > > that support GL_ARB_texture_multisample) > > - GL_ARB_texture_view not started > > + GL_ARB_texture_view started (Courtney > > Goeltzenleuchter, Chris Forbes) > >GL_ARB_vertex_attrib_binding DONE (all drivers) > > > > > > @@ -173,7 +173,7 @@ GL 4.4: > >GL_ARB_buffer_storagenot started > >GL_ARB_clear_texture not started > >GL_ARB_enhanced_layouts not started > > - GL_ARB_multi_bindnot started > > + GL_ARB_multi_bindstarted (Maxence Le > > Doré) > > I don't think we were going forward with Maxence's patches, and rather > going with Fredrik's (Cc'd). Fredrik, what's the current status? It's essentially done. I will post an updated version of my series sh
[Mesa-dev] [PATCH libdrm] modeprint: pretty print connector names
Use same names as the kernel, makes it easier to identify
connectors in the common case.
Signed-off-by: Lucas Stach
---
tests/modeprint/modeprint.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 545ff40a98d4..6f0d03905a46 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -41,6 +41,8 @@
#include "xf86drm.h"
#include "xf86drmMode.h"
+#define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
+
int connectors;
int full_props;
int edid;
@@ -140,13 +142,37 @@ int printProperty(int fd, drmModeResPtr res,
drmModePropertyPtr props, uint64_t
return 0;
}
+static const char * const output_names[] = { "None",
+"VGA",
+"DVI-I",
+"DVI-D",
+"DVI-A",
+"Composite",
+"SVIDEO",
+"LVDS",
+"Component",
+"DIN",
+"DP",
+"HDMI-A",
+"HDMI-B",
+"TV",
+"eDP",
+"Virtual",
+"DSI",
+};
+
int printConnector(int fd, drmModeResPtr res, drmModeConnectorPtr connector,
uint32_t id)
{
int i = 0;
struct drm_mode_modeinfo *mode = NULL;
drmModePropertyPtr props;
- printf("Connector: %d-%d\n", connector->connector_type,
connector->connector_type_id);
+ if (connector->connector_type < ARRAY_SIZE(output_names))
+ printf("Connector: %s-%d\n",
output_names[connector->connector_type],
+ connector->connector_type_id);
+ else
+ printf("Connector: %d-%d\n", connector->connector_type,
+ connector->connector_type_id);
printf("\tid : %i\n", id);
printf("\tencoder id : %i\n", connector->encoder_id);
printf("\tconn : %s\n",
getConnectionText(connector->connection));
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [V3 PATCH 7/8] mesa: Rename XBGR MESA_FORMATs
Remove/update related comments and rename MESA_FORMAT_XBGR A Type formats to match naming spec as follows: s/\bMESA_FORMAT_XBGR_SNORM\b/MESA_FORMAT_RGBX_SNORM8/g s/\bMESA_FORMAT_XBGR_SRGB\b/MESA_FORMAT_SRGBX_UNORM8/g s/\bMESA_FORMAT_XBGR_UINT\b/MESA_FORMAT_RGBX_UINT8/g s/\bMESA_FORMAT_XBGR_SINT\b/MESA_FORMAT_RGBX_SINT8/g s/\bMESA_FORMAT_XBGR16161616_UNORM\b/MESA_FORMAT_RGBX_UNORM16/g s/\bMESA_FORMAT_XBGR16161616_SNORM\b/MESA_FORMAT_RGBX_SNORM16/g s/\bMESA_FORMAT_XBGR16161616_FLOAT\b/MESA_FORMAT_RGBX_FLOAT16/g s/\bMESA_FORMAT_XBGR16161616_UINT\b/MESA_FORMAT_RGBX_UINT16/g s/\bMESA_FORMAT_XBGR16161616_SINT\b/MESA_FORMAT_RGBX_SINT16/g s/\bMESA_FORMAT_XBGR32323232_UNORM\b/MESA_FORMAT_RGBX_UNORM32/g s/\bMESA_FORMAT_XBGR32323232_SNORM\b/MESA_FORMAT_RGBX_SNORM32/g s/\bMESA_FORMAT_XBGR32323232_FLOAT\b/MESA_FORMAT_RGBX_FLOAT32/g s/\bMESA_FORMAT_XBGR32323232_UINT\b/MESA_FORMAT_RGBX_UINT32/g s/\bMESA_FORMAT_XBGR32323232_SINT\b/MESA_FORMAT_RGBX_SINT32/g Signed-off-by: Mark Mueller --- src/mesa/drivers/dri/i965/brw_surface_formats.c | 24 +++--- src/mesa/main/format_pack.c | 60 +++--- src/mesa/main/format_unpack.c | 36 - src/mesa/main/formats.c | 100 src/mesa/main/formats.h | 24 +++--- src/mesa/main/texformat.c | 20 ++--- src/mesa/main/texstore.c| 70 - src/mesa/state_tracker/st_format.c | 48 ++-- src/mesa/swrast/s_texfetch.c| 24 +++--- 9 files changed, 203 insertions(+), 203 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c b/src/mesa/drivers/dri/i965/brw_surface_formats.c index 2620131..f7afce2 100644 --- a/src/mesa/drivers/dri/i965/brw_surface_formats.c +++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c @@ -507,19 +507,19 @@ brw_format_for_mesa_format(mesa_format mesa_format) [MESA_FORMAT_B4G4R4X4_UNORM] = 0, [MESA_FORMAT_B5G5R5X1_UNORM] = BRW_SURFACEFORMAT_B5G5R5X1_UNORM, - [MESA_FORMAT_XBGR_SNORM] = 0, - [MESA_FORMAT_XBGR_SRGB] = 0, - [MESA_FORMAT_XBGR_UINT] = 0, - [MESA_FORMAT_XBGR_SINT] = 0, + [MESA_FORMAT_RGBX_SNORM8] = 0, + [MESA_FORMAT_SRGBX_UNORM8] = 0, + [MESA_FORMAT_RGBX_UINT8] = 0, + [MESA_FORMAT_RGBX_SINT8] = 0, [MESA_FORMAT_B10G10R10X2_UNORM] = BRW_SURFACEFORMAT_B10G10R10X2_UNORM, - [MESA_FORMAT_XBGR16161616_UNORM] = BRW_SURFACEFORMAT_R16G16B16X16_UNORM, - [MESA_FORMAT_XBGR16161616_SNORM] = 0, - [MESA_FORMAT_XBGR16161616_FLOAT] = BRW_SURFACEFORMAT_R16G16B16X16_FLOAT, - [MESA_FORMAT_XBGR16161616_UINT] = 0, - [MESA_FORMAT_XBGR16161616_SINT] = 0, - [MESA_FORMAT_XBGR32323232_FLOAT] = BRW_SURFACEFORMAT_R32G32B32X32_FLOAT, - [MESA_FORMAT_XBGR32323232_UINT] = 0, - [MESA_FORMAT_XBGR32323232_SINT] = 0, + [MESA_FORMAT_RGBX_UNORM16] = BRW_SURFACEFORMAT_R16G16B16X16_UNORM, + [MESA_FORMAT_RGBX_SNORM16] = 0, + [MESA_FORMAT_RGBX_FLOAT16] = BRW_SURFACEFORMAT_R16G16B16X16_FLOAT, + [MESA_FORMAT_RGBX_UINT16] = 0, + [MESA_FORMAT_RGBX_SINT16] = 0, + [MESA_FORMAT_RGBX_FLOAT32] = BRW_SURFACEFORMAT_R32G32B32X32_FLOAT, + [MESA_FORMAT_RGBX_UINT32] = 0, + [MESA_FORMAT_RGBX_SINT32] = 0, }; assert(mesa_format < MESA_FORMAT_COUNT); return table[mesa_format]; diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c index d80e25c..e604cd3 100644 --- a/src/mesa/main/format_pack.c +++ b/src/mesa/main/format_pack.c @@ -1711,7 +1711,7 @@ pack_float_XRGB1555_UNORM(const GLfloat src[4], void *dst) /* - * MESA_FORMAT_XBGR_SNORM + * MESA_FORMAT_RGBX_SNORM8 */ static void @@ -1726,7 +1726,7 @@ pack_float_XBGR_SNORM(const GLfloat src[4], void *dst) /* - * MESA_FORMAT_XBGR_SRGB + * MESA_FORMAT_SRGBX_UNORM8 */ static void @@ -1764,7 +1764,7 @@ pack_float_XRGB2101010_UNORM(const GLfloat src[4], void *dst) } -/* MESA_FORMAT_XBGR16161616_UNORM */ +/* MESA_FORMAT_RGBX_UNORM16 */ static void pack_ubyte_XBGR16161616_UNORM(const GLubyte src[4], void *dst) @@ -1787,7 +1787,7 @@ pack_float_XBGR16161616_UNORM(const GLfloat src[4], void *dst) } -/* MESA_FORMAT_XBGR16161616_SNORM */ +/* MESA_FORMAT_RGBX_SNORM16 */ static void pack_float_XBGR16161616_SNORM(const GLfloat src[4], void *dst) @@ -1800,7 +1800,7 @@ pack_float_XBGR16161616_SNORM(const GLfloat src[4], void *dst) } -/* MESA_FORMAT_XBGR16161616_FLOAT */ +/* MESA_FORMAT_RGBX_FLOAT16 */ static void pack_float_XBGR16161616_FLOAT(const GLfloat src[4], void *dst) @@ -1812,7 +1812,7 @@ pack_float_XBGR16161616_FLOAT(const GLfloat src[4], void *dst) d[3] = _mesa_float_to_half(1.0); } -/* MESA_FORMAT_XBGR32323232_FLOAT */ +/* MESA_FORMAT_RGBX_FLOAT32 */ static void pack_float_XBGR32323232_FLOAT(const GLfloat src[4], void *dst) @@ -2014,19 +2014,19 @@ _mesa
Re: [Mesa-dev] [V3 PATCH 0/8] mesa: Naming MESA_FORMATs to a specification
On Fri, Jan 17, 2014 at 2:43 AM, Erik Faye-Lund wrote: > On Fri, Jan 17, 2014 at 9:22 AM, Christian König > wrote: > > But as a general note on writing patches: Please limit the subject line > to a > > sane length! Something between 60 and 80 chars should be ok. > > Indeed. The regex patterns are nice to have. But please, put them in > the *body* of the commit message. > Ugh. A combination of PEBKAC and using a new editor. Sorry for the substantial noise. Mark ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: fix large point rasterization with point_quad_rasterization
- Original Message -
> From: Roland Scheidegger
>
> The whole round-pointsize-to-int stuff must only be done with GL legacy
> rules (no point_quad_rasterization) or all the wrong edges are lit up.
> This was previously in a private branch (d3d pointsprite test complains
> loudly otherwise) and got lost in a merge. However, it should certainly
> apply to GL point sprite rasterization as well.
> ---
> src/gallium/drivers/llvmpipe/lp_setup_point.c | 31
> +++--
> 1 file changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_setup_point.c
> b/src/gallium/drivers/llvmpipe/lp_setup_point.c
> index 3610c5c..f065676 100644
> --- a/src/gallium/drivers/llvmpipe/lp_setup_point.c
> +++ b/src/gallium/drivers/llvmpipe/lp_setup_point.c
> @@ -307,12 +307,13 @@ subpixel_snap(float a)
> */
> static void
> print_point(struct lp_setup_context *setup,
> - const float (*v0)[4])
> + const float (*v0)[4],
> + const float size)
> {
> const struct lp_setup_variant_key *key = &setup->setup.variant->key;
> uint i;
>
> - debug_printf("llvmpipe point\n");
> + debug_printf("llvmpipe point, width %f\n", size);
> for (i = 0; i < 1 + key->num_inputs; i++) {
> debug_printf(" v0[%d]: %f %f %f %f\n", i,
> v0[i][0], v0[i][1], v0[i][2], v0[i][3]);
> @@ -331,12 +332,6 @@ try_setup_point( struct lp_setup_context *setup,
> const float size
> = (setup->point_size_per_vertex && sizeAttr > 0) ? v0[sizeAttr][0]
> : setup->point_size;
> -
> - /* Point size as fixed point integer, remove rounding errors
> - * and gives minimum width for very small points
> - */
> - int fixed_width = MAX2(FIXED_ONE,
> - (subpixel_snap(size) + FIXED_ONE/2 - 1) &
> ~(FIXED_ONE-1));
>
> /* Yes this is necessary to accurately calculate bounding boxes
> * with the two fill-conventions we support. GL (normally) ends
> @@ -353,6 +348,7 @@ try_setup_point( struct lp_setup_context *setup,
> struct point_info info;
> unsigned viewport_index = 0;
> unsigned layer = 0;
> + int fixed_width;
>
> if (setup->viewport_index_slot > 0) {
> unsigned *udata = (unsigned*)v0[setup->viewport_index_slot];
> @@ -364,7 +360,7 @@ try_setup_point( struct lp_setup_context *setup,
> }
>
> if (0)
> - print_point(setup, v0);
> + print_point(setup, v0, size);
>
> /* Bounding rectangle (in pixels) */
> if (!lp_context->rasterizer ||
> @@ -372,9 +368,14 @@ try_setup_point( struct lp_setup_context *setup,
> /*
> * Rasterize points as quads.
> */
> + int x0, y0;
> + /* Point size as fixed point integer, remove rounding errors
> + * and gives minimum width for very small points.
> + */
> + fixed_width = MAX2(FIXED_ONE, subpixel_snap(size));
>
> - const int x0 = subpixel_snap(v0[0][0] - setup->pixel_offset) -
> fixed_width/2;
> - const int y0 = subpixel_snap(v0[0][1] - setup->pixel_offset) -
> fixed_width/2;
> + x0 = subpixel_snap(v0[0][0] - setup->pixel_offset) - fixed_width/2;
> + y0 = subpixel_snap(v0[0][1] - setup->pixel_offset) - fixed_width/2;
>
> bbox.x0 = (x0 + (FIXED_ONE-1)) >> FIXED_ORDER;
> bbox.x1 = (x0 + fixed_width + (FIXED_ONE-1)) >> FIXED_ORDER;
> @@ -398,7 +399,13 @@ try_setup_point( struct lp_setup_context *setup,
> const int x0 = subpixel_snap(v0[0][0]);
> const int y0 = subpixel_snap(v0[0][1]) - adj;
>
> - int int_width = fixed_width >> FIXED_ORDER;
> + int int_width;
> + /* Point size as fixed point integer. For GL legacy points
> + * the point size is always a whole integer.
> + */
> + fixed_width = MAX2(FIXED_ONE,
> + (subpixel_snap(size) + FIXED_ONE/2 - 1) &
> ~(FIXED_ONE-1));
> + int_width = fixed_width >> FIXED_ORDER;
>
> assert(setup->pixel_offset != 0);
>
Thanks for tracking this down, Roland.
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] svga: fix crash when clearing null color buffer
- Original Message -
> Fixes regression since 9baa45f78b8ca7d66280e36009b6a685055d7cd6
> but some of the piglit fbo-drawbuffers-none tests still don't
> pass.
> ---
> src/gallium/drivers/svga/svga_pipe_clear.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/svga/svga_pipe_clear.c
> b/src/gallium/drivers/svga/svga_pipe_clear.c
> index 47f6258..ebdce3b 100644
> --- a/src/gallium/drivers/svga/svga_pipe_clear.c
> +++ b/src/gallium/drivers/svga/svga_pipe_clear.c
> @@ -111,9 +111,13 @@ svga_clear(struct pipe_context *pipe, unsigned buffers,
> struct svga_context *svga = svga_context( pipe );
> enum pipe_error ret;
>
> - if (buffers & PIPE_CLEAR_COLOR)
> - SVGA_DBG(DEBUG_DMA, "clear sid %p\n",
> - svga_surface(svga->curr.framebuffer.cbufs[0])->handle);
> + if (buffers & PIPE_CLEAR_COLOR) {
> + struct svga_winsys_handle *h = NULL;
> + if (svga->curr.framebuffer.cbufs[0]) {
> + h = svga_surface(svga->curr.framebuffer.cbufs[0])->handle;
> + }
> + SVGA_DBG(DEBUG_DMA, "clear sid %p\n", h);
> + }
>
> /* flush any queued prims (don't want them to appear after the clear!) */
> svga_hwtnl_flush_retry(svga);
> --
> 1.8.3.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=OUomIkBN13xAFvxxWHODUEiG1q28%2B7LMvw3w3IuPljQ%3D%0A&s=10d5e6f10f13a2244c8a47dd8298e9767e20c8236c5f28932cb1fcc82fcbe50c
>
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/16] i965/fs: Calculate interference better in register_coalesce.
On Fri, Jan 10, 2014 at 02:29:04PM -0800, Matt Turner wrote:
> On Wed, Dec 25, 2013 at 2:11 AM, Pohjolainen, Topi
> wrote:
> > On Thu, Dec 19, 2013 at 01:40:23PM -0800, Matt Turner wrote:
> >> Previously we simply considered two registers whose live ranges
> >> overlapped to interfere. Cases such as
> >>
> >>set A --
> >>... |
> >>mov B, A --|
> >>... | B | A
> >>use B --|
> >>... |
> >>use A --
> >>
> >> would be considered to interfere, even though B is an unmodified copy of
> >> A whose live range fit wholly inside that of A.
> >>
> >> If no writes to A or B occur between the mov B, A and the use of B then
> >> we can safely coalesce them.
> >>
> >> Instead of removing MOV instructions, we make them NOPs and remove them
> >> at once after the main pass is finished in order to avoid recomputing
> >> live intervals (which are needed to perform the previous step).
> >>
> >> total instructions in shared programs: 1543768 -> 1513077 (-1.99%)
> >> instructions in affected programs: 951563 -> 920872 (-3.23%)
> >> GAINED:46
> >> LOST: 22
> >> ---
> >> src/mesa/drivers/dri/i965/brw_fs.cpp | 69
> >>
> >> 1 file changed, 62 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> >> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> >> index e4ac0a5..ad56b87 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> >> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> >> @@ -2273,7 +2273,7 @@ fs_visitor::register_coalesce()
> >> int last_use[MAX_SAMPLER_MESSAGE_SIZE];
> >> int next_ip = 0;
> >>
> >> - foreach_list_safe(node, &this->instructions) {
> >> + foreach_list(node, &this->instructions) {
> >>fs_inst *inst = (fs_inst *)node;
> >>
> >>int ip = next_ip;
> >> @@ -2299,8 +2299,39 @@ fs_visitor::register_coalesce()
> >>int var_to = live_intervals->var_from_reg(&inst->dst);
> >>
> >>if (live_intervals->vars_interfere(var_from, var_to) &&
> >> - !inst->dst.equals(inst->src[0]))
> >> - continue;
> >> + !inst->dst.equals(inst->src[0])) {
> >> +
> >> + if (live_intervals->end[var_to] > live_intervals->end[var_from])
> >> +continue;
> >
> > Just checking if I understood things correctly and trying to fill in the
> > caps
> > that I cannot figure out myself: Is the check for the start implicit from
> > somewhere else? This has to apply as well, right?
> >
> > if (live_intervals->start[var_to] <
> > live_intervals->start[var_from])
> >continue;
>
> We know that the live ranges of (A) var_from and (B) var_to interfere
> because of the ->vars_interfere() call above. If the end of B's live
> range is after the end of A's range, then we know two things:
> - the start of B's live range must be in A's live range (since we
> already know the two ranges interfere, this is the only remaining
> possibility)
> - the interference isn't of the form we're looking for (where B is
> entirely inside A)
>
> That's pretty tricky and it took me a while to recreate what I was
> thinking when I wrote the code, so let me know if this makes sense to
> you. :)
That makes sense, thanks!
>
> I think I'll put an explanatory comment there for good measure.
>
> >> +
> >> + bool overwritten = false;
> >> + int scan_ip = -1;
> >> +
> >> + foreach_list(n, &this->instructions) {
> >> + fs_inst *scan_inst = (fs_inst *)n;
> >> +scan_ip++;
> >> +
> >> +if (scan_inst->is_control_flow()) {
> >> + overwritten = true;
> >> + break;
> >> +}
> >
> > Instructions are scanned from the very beginning of the program, and hence
> > we
> > are also scanning for instructions that correspond to control flow changes
> > (i.e., jumps) before either of the start of live intervals of 'var_to' and
> > 'var_from' (in fact if I'm not mistakan above, this should read "before live
> > interval of 'var_from'").
> >
> > And if any such instruction is found the consideration for any coalescing is
> > dropped. Isn't it enough to scan for control flow changes only after the
> > start
> > of the live interval of 'var_from'? (It has been a while since I've been
> > thinking any of this sort of things and I'm easily missing things. But had
> > to
> > ask.)
>
> I'm not sure because of DO instructions that mark the beginning of a
> loop -- if our live ranges are in a loop we probably need to think
> some more about how we can coalesce registers.. I think we can improve
> this later though, because I've seen a lot of shaders with loops that
> contain MOVs that could be removed if register coalescing were a bit
> smarter.
The more I also think about it the less clear it becomes, better to play safe
and think it through properly.
_
Re: [Mesa-dev] code de-duplication and non-pci support v2
On Thu, Jan 16, 2014 at 6:55 PM, Emil Velikov wrote: > On 16/01/14 23:29, Kristian Høgsberg wrote: >> On Sat, Jan 11, 2014 at 04:51:42PM -0500, Rob Clark wrote: >>> On Sat, Jan 11, 2014 at 11:54 AM, Emil Velikov >>> wrote: This is an updated series of Rob's patches * The introduction of the util library is separated from the de-duplication. * Each commit targets individual part of mesa and it should build/work regardless of build system/options. * Handles a couple more cases of de-duplication. * Hides the loader funcs so that they are not exported. * Building platform_android, will correctly set the logger to _eglLog(), which on itself is rapped around Androids (A)LOG. * Non-pci devices support has been ripped out and is left at the end of the series. * automake and scons build tested, Android should after correcting the following defined(PIPE_OS_ANDROID) && !defined(_EGL_NO_DRM) >>> >>> Very cool, thanks for taking this and running with it. Especially the >>> other build systems which I have no clue about :-) >>> >>> I had a look at the patches, and they look good. So with the >>> disclaimer that I am certainly not expert on these parts, for the >>> series: >>> >>> Reviewed-by: Rob Clark >> >> I'm not familiar with the other build systems either, but aside for >> those two issues I pointed out >> > Good points Kristian I'll update patches 1 & 2. > > I'm suspecting that there will not be many more people interested in > reviewing/testing the series, so unless someone has anything to add I > plan on pushing it this Saturday. cool, thanks Emil.. I look forward to being able to run weston without needing some out of tree patches :-) BR, -R > Cheers > Emil > >> Reviewed-by: Kristian Høgsberg >> >> for the series. >> Brief list of which patches affect which build system (android A, automake M, scons S) patch 1 - A, M, S patch 2 - M, S patch 3 - M patch 4 - A, M, S patch 5 - M, S patch 6 - M patch 7 - A, M patch 8 - S Notes: * Eric's comment about moving the driver_name allocation to egl_dri2.c does not seem easily achiveable due to platform_x11. * Keith's patch can be relatively easily rebased on top of this. * Andoid logging should work via (A)LOG. Cheers, Emil Emil Velikov (9): loader: introduce the loader util lib glx: use the loader util lib gbm: use the loader util lib egl-static: use loader util lib st/egl: use loader util lib pipe-loader: use loader util lib egl_dri2: use loader util lib pci_ids: no not include loader.h pipe-loader: add support for non-pci (platform) devices Rob Clark (1): loader: fallback to drmGetVersion() for non-pci devices Android.mk | 1 + configure.ac | 1 + include/pci_ids/pci_id_driver_map.h| 27 +- src/Makefile.am| 2 +- src/SConscript | 1 + src/egl/drivers/dri2/Android.mk| 5 +- src/egl/drivers/dri2/Makefile.am | 5 +- src/egl/drivers/dri2/common.c | 144 --- src/egl/drivers/dri2/egl_dri2.h| 5 - src/egl/drivers/dri2/platform_android.c| 107 +--- src/egl/drivers/dri2/platform_drm.c| 5 +- src/egl/drivers/dri2/platform_wayland.c| 5 +- src/egl/main/Android.mk| 1 + src/gallium/auxiliary/pipe-loader/Makefile.am | 8 +- src/gallium/auxiliary/pipe-loader/pipe_loader.h| 1 + .../auxiliary/pipe-loader/pipe_loader_drm.c| 92 +-- src/gallium/state_trackers/clover/core/device.cpp | 2 + src/gallium/state_trackers/egl/Makefile.am | 2 + src/gallium/state_trackers/egl/SConscript | 4 + src/gallium/state_trackers/egl/drm/native_drm.c| 44 +--- .../state_trackers/gbm/gbm_gallium_drmint.h| 1 - src/gallium/targets/egl-static/Android.mk | 1 + src/gallium/targets/egl-static/Makefile.am | 2 + src/gallium/targets/egl-static/SConscript | 2 + src/gallium/targets/egl-static/egl.c | 185 +- src/gbm/Makefile.am| 13 +- src/gbm/backends/dri/driver_name.c | 89 --- src/gbm/backends/dri/gbm_dri.c | 3 +- src/gbm/backends/dri/gbm_driint.h | 4 - src/gbm/main/common.c | 88 --- src/gbm/main/common.h | 42 >>>
[Mesa-dev] [PATCH 1/2] trace: Re-license trace.xsl under MIT license.
From: José Fonseca I was the sole author, as Tungsten Graphics employee, which was since then acquired by VMware Inc. --- src/gallium/drivers/trace/trace.xsl | 36 ++-- 1 file changed, 22 insertions(+), 14 deletions(-) diff --git a/src/gallium/drivers/trace/trace.xsl b/src/gallium/drivers/trace/trace.xsl index 7be95e0..12458ae 100644 --- a/src/gallium/drivers/trace/trace.xsl +++ b/src/gallium/drivers/trace/trace.xsl @@ -2,20 +2,28 @@ -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] trace: Re-license trace.xsl under MIT license.
On 01/17/2014 08:33 AM, jfons...@vmware.com wrote: From: José Fonseca I was the sole author, as Tungsten Graphics employee, which was since then acquired by VMware Inc. --- src/gallium/drivers/trace/trace.xsl | 36 ++-- 1 file changed, 22 insertions(+), 14 deletions(-) diff --git a/src/gallium/drivers/trace/trace.xsl b/src/gallium/drivers/trace/trace.xsl index 7be95e0..12458ae 100644 --- a/src/gallium/drivers/trace/trace.xsl +++ b/src/gallium/drivers/trace/trace.xsl @@ -2,20 +2,28 @@
[Mesa-dev] [Bug 73746] New: Gallum HUD not always visible with Rust
https://bugs.freedesktop.org/show_bug.cgi?id=73746 Priority: medium Bug ID: 73746 Assignee: mesa-dev@lists.freedesktop.org Summary: Gallum HUD not always visible with Rust Severity: normal Classification: Unclassified OS: All Reporter: v10la...@myway.de Hardware: Other Status: NEW Version: 10.0 Component: Mesa core Product: Mesa I wanted to get some FPS infos from the game Rust ( http://store.steampowered.com/app/252490 ) but it doesn't work. The Gallium HUD is visible while the game shows the loading screen but as soon as the information about the steam overlay fades away the HUD fades away, too. After that point the HUD shows up with the steam overlay only (so while a message from steam pops in or you press shift + tab). -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [wip 9/9] mesa: OES_get_program_binary extension functionality
On 16 January 2014 05:37, Tapani Pälli wrote:
> On 01/15/2014 06:13 PM, Paul Berry wrote:
>
> On 2 January 2014 03:58, Tapani Pälli wrote:
>
>> Signed-off-by: Tapani Pälli
>> ---
>> src/mesa/main/shaderapi.c | 44
>> ++--
>> 1 file changed, 38 insertions(+), 6 deletions(-)
>>
>> + char *data = mesa_program_serialize(shProg, &size);
>> +
>> + /* we have more data that can fit to user given buffer */
>> + if (size > bufSize) {
>> + _mesa_error(ctx, GL_INVALID_OPERATION, __FUNCTION__);
>> + if (data)
>> + free(data);
>>
>
> Why would we ever expect mesa_program_serialize to set size to a nonzero
> value but return NULL? It seems like this could only happen if there's a
> bug, in which case this really ought to be
>
> assert(data !=NULL);
>
> Also, it's safe to call free() on a NULL pointer. According to the C
> standard, freeing a NULL pointer does nothing.
>
>
> sure, will fix
>
>
>
>
>> + return;
>> + }
>> +
>> + if (data) {
>>
>
> Similarly, this if-statement is unnecessary.
>
>
> it is required for memcpy but not for free
>
Oops, you're right.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [V3 PATCH 1/8] mesa: 's/\bgl_format\b/mesa_format/g'. Use better name for Mesa Formats enum
On 01/16/2014 10:13 PM, Mark Mueller wrote: This series encompases the much discussed specification and renaming of MESA_FORMATs, which now is packed into 8 patches Signed-off-by: Mark Mueller --- Well, our other enum typedefs (and structs) all use the gl_ prefix. But the other enum values don't use MESA_ prefixes so gl_formats are weird that way. I'm kind on the fence about this change. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [wip 8/9] glsl: functions to serialize gl_shader and gl_shader_program
On 15 January 2014 02:46, Tapani wrote: > On 01/14/2014 07:53 PM, Paul Berry wrote: > > On 2 January 2014 03:58, Tapani Pälli wrote: > >> +static void >>> +serialize_uniform_storage(gl_uniform_storage *uni, memory_writer &blob) >>> >> >> I don't think this is right. The ARB_get_program_binary spec says: >> >> 8. How does ProgramBinary interact with uniform values, including >>shader-specified defaults? >> >> RESOLVED: All uniforms specified in the binary are reset to their >> shader- >> specified defaults, or to zero if they aren't specified, when the >> program >> binary is loaded. The spec language has been updated to specify this >> behavior. >> >> The OES_get_program_binary spec doesn't mention uniforms at all, but I >> believe this is not intended to indicate a behavioural difference--it's >> just a consequence of the fact that ARB_get_program_binary was written >> later, so they had a chance to clarify things. In fact, issue #7 in >> ARB_get_program_binary specifically says: >> >> 7. How does this spec differ from the OES_get_program_binary and why? >> >> ... >> >> There are other areas where language was clarified, but this is meant >> to >> be consistent with the intent of the original specification and not to >> alter previously established behavior. >> >> So I believe we shouldn't be serializing uniform values. >> >> >> For me this seemed much easier way to serialize than recreate it though. > Would it be enough if I reset the default values in place? > Yes, I think that would be reasonable. Thanks! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [V3 PATCH 2/8] mesa: Change 4 color component ubyte formats
On 01/17/2014 03:45 AM, Mark Mueller wrote:
Change all 4 color component unsigned byte formats to meet spec:
s/MESA_FORMAT_RGBA\b/MESA_FORMAT_ABGR_UNORM8/g
s/MESA_FORMAT_RGBA_REV\b/MESA_FORMAT_RGBA_UNORM8/g
s/MESA_FORMAT_ARGB\b/MESA_FORMAT_BGRA_UNORM8/g
s/MESA_FORMAT_ARGB_REV\b/MESA_FORMAT_ARGB_UNORM8/g
s/MESA_FORMAT_RGBX\b/MESA_FORMAT_XBGR_UNORM8/g
s/MESA_FORMAT_RGBX_REV\b/MESA_FORMAT_RGBX_UNORM8/g
s/MESA_FORMAT_XRGB\b/MESA_FORMAT_BGRX_UNORM8/g
s/MESA_FORMAT_XRGB_REV\b/MESA_FORMAT_XRGB_UNORM8/g
I'm not sure this is right. If you look at the existing code such as
src/mesa/main/format_{un}pack.c you'll see that these formats are
treated as packed formats, not arrays.
Changing these formats from packed to array would cause even more
big/little-endian grief, right?
Same comment on some of the other patches.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [wip 1/9] glsl: memory_writer helper class for data serialization
On 14 January 2014 02:35, Tapani Pälli wrote:
> On 01/13/2014 08:27 PM, Paul Berry wrote:
>
> On 2 January 2014 03:58, Tapani Pälli wrote:
>
>> Class will be used by the shader binary cache implementation.
>>
>> Signed-off-by: Tapani Pälli
>> ---
>> src/glsl/memory_writer.h | 147
>> +++
>> 1 file changed, 147 insertions(+)
>> create mode 100644 src/glsl/memory_writer.h
>>
>> diff --git a/src/glsl/memory_writer.h b/src/glsl/memory_writer.h
>> new file mode 100644
>> index 000..a6c6b55
>> --- /dev/null
>> +++ b/src/glsl/memory_writer.h
>> @@ -0,0 +1,147 @@
>> +/* -*- c++ -*- */
>> +/*
>> + * Copyright © 2013 Intel Corporation
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining
>> a
>> + * copy of this software and associated documentation files (the
>> "Software"),
>> + * to deal in the Software without restriction, including without
>> limitation
>> + * the rights to use, copy, modify, merge, publish, distribute,
>> sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the
>> next
>> + * paragraph) shall be included in all copies or substantial portions of
>> the
>> + * Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> EXPRESS OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
>> SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
>> OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> + * DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +#pragma once
>> +#ifndef MEMORY_WRITER_H
>> +#define MEMORY_WRITER_H
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#ifdef __cplusplus
>> +/**
>> + * Helper class for writing data to memory
>> + *
>> + * This class maintains a dynamically-sized memory buffer and allows
>> + * for data to be efficiently appended to it with automatic resizing.
>> + */
>> +class memory_writer
>> +{
>> +public:
>> + memory_writer() :
>> + memory(NULL),
>> + curr_size(0),
>> + pos(0) {}
>> +
>> + ~memory_writer()
>> + {
>> + free(memory);
>> + }
>> +
>> + /* user wants to claim the memory */
>> + char *release_memory(size_t *size)
>> + {
>> + /* final realloc to free allocated but unused memory */
>> + char *result = (char *) realloc(memory, pos);
>> + *size = pos;
>> + memory = NULL;
>> + curr_size = 0;
>> + pos = 0;
>> + return result;
>> + }
>> +
>> +/**
>> + * write functions per type
>> + */
>> +#define DECL_WRITER(type) int write_ ##type (const type data) {\
>> + return write(&data, sizeof(type));\
>> +}
>> +
>> + DECL_WRITER(int32_t);
>> + DECL_WRITER(int64_t);
>> + DECL_WRITER(uint8_t);
>> + DECL_WRITER(uint32_t);
>> +
>> + int write_bool(bool data)
>> + {
>> + uint8_t val = data;
>> + return write_uint8_t(val);
>> + }
>> +
>> + /* write function that reallocates more memory if required */
>> + int write(const void *data, int32_t size)
>> + {
>> + if (!memory || pos > (int32_t)(curr_size - size))
>> + if (grow(size))
>> +return -1;
>> +
>> + memcpy(memory + pos, data, size);
>> +
>> + pos += size;
>> + return 0;
>> + }
>> +
>> + int overwrite(const void *data, int32_t size, int32_t offset)
>> + {
>> + if (offset < 0 || offset + size > pos)
>> + return -1;
>> + memcpy(memory + offset, data, size);
>> + return 0;
>> + }
>> +
>> + int write_string(const char *str)
>> + {
>> + if (!str)
>> + return -1;
>> + char terminator = '\0';
>> + write(str, strlen(str));
>> + write(&terminator, 1);
>>
>
> C strings include a terminator, so there's no reason to write out the
> string contents and the terminator separtely. You can just do:
>
> write(str, strlen(str) + 1);
>
> Also, don't forget to propagate the return code to the caller:
>
> return write(str, strlen(str) + 1);
>
>
> Ah right, will do. It could be that this needs to be modified back to how
> it was though (to write to length of the string too). I think it is
> otherwise impossible for the reader side to know if terminator really
> exists and it might continue to read forever (or call strlen for
> unterminated string).
>
I don't know of any C library function that does exactly what you want. Of
course you could always code up your own loop. But I think I agree that
storing the length first is the best approach.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [wip 6/9] glsl: ir_deserializer class for the binary shader cache
On 14 January 2014 03:35, Tapani Pälli wrote:
> On 01/14/2014 01:24 AM, Paul Berry wrote:
>
> On 2 January 2014 03:58, Tapani Pälli wrote:
>
> + var->state_slots = NULL;
>> +
>> + if (var->num_state_slots > 0) {
>> + var->state_slots = ralloc_array(var, ir_state_slot,
>> + var->num_state_slots);
>>
>
> Security issue: if the shader blob is corrupted, num_state_slots could
> be outrageously large, causing this memory allocation to fail (which would
> then cause the loop below to perform illegal memory accesses). We should
> validate that num_state_slots is within a reasonable range, and if it
> isn't, abort reading the binary blob.
>
>
> What is the expected reasonable range for state_slots?
>
I believe the uniform with the most state slots is gl_LightSource, which
has 96.
What I'd suggest doing (in a separate patch) is: add a
#define MAX_NUM_STATE_SLOTS 96
somewhere, and then in builtin_variable_generator::add_uniform(), right
after setting uni->num_state_slots, add:
assert(uni->num_state_slots <= MAX_NUM_STATE_SLOTS);
That way, in the unlikely event that we ever add a GL feature that requires
more than this number of state slots, the assertion failure will alert us
that we need to increase MAX_NUM_STATE_SLOTS.
>
>
>+ /* fill parse state from shader header information */
>> + switch (shader->Type) {
>> + case GL_VERTEX_SHADER:
>> + state->target = MESA_SHADER_VERTEX;
>> + break;
>> + case GL_FRAGMENT_SHADER:
>> + state->target = MESA_SHADER_FRAGMENT;
>> + break;
>> + case GL_GEOMETRY_SHADER_ARB:
>> + state->target = MESA_SHADER_GEOMETRY;
>> + break;
>>
>
> There should be a default case here to handle corrupted blobs with an
> illegal type.
>
>
> I'm now doing _mesa_shader_enum_to_shader_stage(shader->Type) here which
> will assert if type is illegal.
>
An assertion isn't good enough, because assertions don't get checked in
release builds.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73746] Gallum HUD not always visible with Rust
https://bugs.freedesktop.org/show_bug.cgi?id=73746 --- Comment #1 from Marek Olšák --- Did you compile Mesa with --enable-gallium-egl? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] draw: clean up d3d style point clipping
From: Roland Scheidegger
Instead of skipping x/y clipping completely if there's point_tri_clip points
use guard band clipping. This should be easier (previously we could not disable
generating the x/y bits in the clip mask for llvm path, hence requiring custom
clip path), and it also allows us to enable this for tris-as-points more easily
too (this would require custom tri clip filtering too otherwise). Moreover,
some unexpected things could have happen if there's a NaN or just a huge number
in some tri-turned-point, as the driver's rasterizer would need to deal with it
and that might well lead to undefined behavior in typical rasterizers (which
need to convert these numbers to fixed point). Using a guardband should hence
be more robust, while "usually" guaranteeing the same results. (Only "usually"
because unlike hw guardbands draw guardband is always just twice the vp size,
hence small vp but large points could still lead to different results.)
Unfortunately because the clipmask generated is completely unaffected by guard
band clipping, we still need a custom clip stage for points (but not for tris,
as the actual clipping there takes guard band into account).
---
src/gallium/auxiliary/draw/draw_context.c |8 ++---
src/gallium/auxiliary/draw/draw_pipe_clip.c| 34 ++--
src/gallium/auxiliary/draw/draw_private.h |2 +-
.../auxiliary/draw/draw_pt_fetch_shade_pipeline.c | 15 +
.../draw/draw_pt_fetch_shade_pipeline_llvm.c |8 +++--
5 files changed, 42 insertions(+), 25 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_context.c
b/src/gallium/auxiliary/draw/draw_context.c
index 9b5bcb5..842fdd3 100644
--- a/src/gallium/auxiliary/draw/draw_context.c
+++ b/src/gallium/auxiliary/draw/draw_context.c
@@ -262,10 +262,10 @@ static void update_clip_flags( struct draw_context *draw )
draw->rasterizer && draw->rasterizer->depth_clip);
draw->clip_user = draw->rasterizer &&
draw->rasterizer->clip_plane_enable != 0;
- draw->clip_points_xy = draw->clip_xy &&
- (!draw->driver.bypass_clip_points ||
- (draw->rasterizer &&
- !draw->rasterizer->point_tri_clip));
+ draw->guard_band_points_xy = draw->guard_band_xy ||
+(draw->driver.bypass_clip_points &&
+(draw->rasterizer &&
+ draw->rasterizer->point_tri_clip));
}
/**
diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c
b/src/gallium/auxiliary/draw/draw_pipe_clip.c
index adfa4b6..9b339ae 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_clip.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_clip.c
@@ -615,19 +615,33 @@ clip_point( struct draw_stage *stage,
stage->next->point( stage->next, header );
}
+
/*
* Clip points but ignore the first 4 (xy) clip planes.
- * (This is necessary because we don't generate a different shader variant
- * just for points hence xy clip bits are still generated. This is not really
- * optimal because of the extra calculations both in generating clip masks
- * and executing the clip stage but it gets the job done.)
+ * (Because the generated clip mask is completely unaffacted by guard band,
+ * we still need to manually evaluate the x/y planes if they are outside
+ * the guard band and not just outside the vp.)
*/
static void
-clip_point_no_xy( struct draw_stage *stage,
- struct prim_header *header )
+clip_point_guard_xy( struct draw_stage *stage,
+ struct prim_header *header )
{
- if ((header->v[0]->clipmask & 0xfff0) == 0)
- stage->next->point( stage->next, header );
+ unsigned clipmask = header->v[0]->clipmask;
+ if ((clipmask & 0x) == 0)
+ stage->next->point(stage->next, header);
+ else if ((clipmask & 0xfff0) == 0) {
+ while (clipmask) {
+ const unsigned plane_idx = ffs(clipmask)-1;
+ clipmask &= ~(1 << plane_idx); /* turn off this plane's bit */
+ /* TODO: this should really do proper guardband clipping,
+ * currently just throw out infs/nans.
+ */
+ if (util_is_inf_or_nan(header->v[0]->clip[0]) ||
+ util_is_inf_or_nan(header->v[0]->clip[1]))
+return;
+ }
+ stage->next->point(stage->next, header);
+ }
}
@@ -636,7 +650,7 @@ static void
clip_first_point( struct draw_stage *stage,
struct prim_header *header )
{
- stage->point = stage->draw->clip_points_xy ? clip_point : clip_point_no_xy;
+ stage->point = stage->draw->guard_band_points_xy ? clip_point_guard_xy :
clip_point;
stage->point(stage, header);
}
@@ -662,7 +676,7 @@ clip_line( struct draw_stage *stage,
static void
clip_tri( struct draw_stage *stage,
- struct prim_header *header )
+ struct prim_header *header )
{
unsigned clipmask = (header->v[0]->c
[Mesa-dev] [Bug 73746] Gallum HUD not always visible with Rust
https://bugs.freedesktop.org/show_bug.cgi?id=73746 --- Comment #2 from Thomas Rohloff --- (In reply to comment #1) > Did you compile Mesa with --enable-gallium-egl? Yes. Also with other games (for example: Left 4 Dead 2) it works. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/16] i965/fs: Add local value numbering optimization pass.
On Thu, Dec 19, 2013 at 1:40 PM, Matt Turner wrote:
> total instructions in shared programs: 1520829 -> 1511991 (-0.58%)
> instructions in affected programs: 559725 -> 550887 (-1.58%)
> GAINED:6
> LOST: 9
> ---
> src/mesa/drivers/dri/i965/Makefile.sources | 1 +
> src/mesa/drivers/dri/i965/brw_fs.cpp | 37 +-
> src/mesa/drivers/dri/i965/brw_fs.h | 1 +
> .../drivers/dri/i965/brw_fs_value_numbering.cpp| 398
> +
> 4 files changed, 435 insertions(+), 2 deletions(-)
> create mode 100644 src/mesa/drivers/dri/i965/brw_fs_value_numbering.cpp
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index 43f152e..36d8261 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -63,6 +63,7 @@ i965_FILES = \
> brw_fs_peephole_predicated_break.cpp \
> brw_fs_reg_allocate.cpp \
> brw_fs_sel_peephole.cpp \
> + brw_fs_value_numbering.cpp \
> brw_fs_vector_splitting.cpp \
> brw_fs_visitor.cpp \
> brw_gs.c \
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index e4a4737..08837da 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -3285,9 +3285,11 @@ fs_visitor::run()
>remove_dead_constants();
>setup_pull_constants();
>
> - bool progress;
> + bool progress, cp_progress, vn_progress;
>do {
> progress = false;
> + cp_progress = false;
> + vn_progress = false;
>
> compact_virtual_grfs();
>
> @@ -3295,16 +3297,47 @@ fs_visitor::run()
>
> progress = opt_algebraic() || progress;
> progress = opt_cse() || progress;
> -progress = opt_copy_propagate() || progress;
> progress = opt_peephole_predicated_break() || progress;
> +cp_progress = opt_copy_propagate();
There is a tab here, according to:
git show mattst88/register-coalesce~5|grep -P "\+(\s*\t\s*)"
> progress = dead_code_eliminate() || progress;
> progress = dead_code_eliminate_local() || progress;
> progress = opt_peephole_sel() || progress;
> progress = dead_control_flow_eliminate(this) || progress;
> + vn_progress = opt_value_numbering();
Could something like this help with the fighting, and remove the need
for the 'fixup' block below?
if (progress || !cp_progress)
vn_progress = opt_value_numbering();
-Jordan
> progress = register_coalesce() || progress;
> progress = compute_to_mrf() || progress;
> +
> + /* Value numbering rewrites
> + *
> + *MOV g5, 1.0F
> + *MOV g6, 1.0F
> + *
> + * into
> + *
> + *MOV g5, 1.0F
> + *MOV g6, g5
> + *
> + * but constant propagation undoes this. If these were the only two
> + * passes to make progress, they're just fighting.
> + */
> + if (!progress && (cp_progress != vn_progress)) {
> +progress = true;
> + }
>} while (progress);
>
> + /* Copy propagation and value numbering were fighting, which means that
> + * the last changes made by value numbering weren't useful, so rerun
> + * copy propagation and the rest of the optimizations after it, modulo
> + * value numbering.
> + */
> + if (cp_progress && vn_progress) {
> + opt_copy_propagate();
> + dead_code_eliminate();
> + dead_code_eliminate_local();
> + register_coalesce();
> + compute_to_mrf();
> + }
> +
>lower_uniform_pull_constant_loads();
>
>assign_curb_setup();
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Stop doing our optimization on a copy of the GLSL IR.
On 01/13/2014 10:28 PM, Eric Anholt wrote:
> The original intent was that we'd keep a driver-private copy, and there
> would be the normal copy for swrast to make use of without the tuning (or
> anything more invasive we might do) specific to i965. Only, we don't
> generate swrast code any more, because swrast can't render current shaders
> anyway. Thus, our private copy is rather a waste, and we can just do our
> backend-specific operations on the linked shader.
I was thinking there were some other goofy issues (interactions of
glLinkProgram w/o glUseProgram, and releasing the IR after
glDeleteProgram), but neither of those appear to be problems.
Both patches are
Reviewed-by: Ian Romanick
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 3 --
> src/mesa/drivers/dri/i965/brw_fs.cpp | 4 +-
> src/mesa/drivers/dri/i965/brw_shader.cpp | 55
> ++-
> src/mesa/drivers/dri/i965/brw_vec4.cpp| 4 +-
> src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 2 +-
> 5 files changed, 28 insertions(+), 40 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 63dd4a0..099f2f6 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -320,9 +320,6 @@ struct brw_shader {
> struct gl_shader base;
>
> bool compiled_once;
> -
> - /** Shader IR transformed for native compile, at link time. */
> - struct exec_list *ir;
> };
>
> /* Note: If adding fields that need anything besides a normal memcmp() for
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index baf9220..3536cbe 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -3156,7 +3156,7 @@ fs_visitor::run()
> * functions called "main").
> */
>if (shader) {
> - foreach_list(node, &*shader->ir) {
> + foreach_list(node, &*shader->base.ir) {
> ir_instruction *ir = (ir_instruction *)node;
> base_ir = ir;
> this->result = reg_undef;
> @@ -3305,7 +3305,7 @@ brw_wm_fs_emit(struct brw_context *brw, struct
> brw_wm_compile *c,
> if (unlikely(INTEL_DEBUG & DEBUG_WM)) {
>if (prog) {
> printf("GLSL IR for native fragment shader %d:\n", prog->Name);
> - _mesa_print_ir(shader->ir, NULL);
> + _mesa_print_ir(shader->base.ir, NULL);
> printf("\n\n");
>} else {
> printf("ARB_fragment_program %d ir for native fragment shader\n",
> diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
> b/src/mesa/drivers/dri/i965/brw_shader.cpp
> index cf9ca4b..5752348 100644
> --- a/src/mesa/drivers/dri/i965/brw_shader.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
> @@ -135,24 +135,18 @@ brw_link_shader(struct gl_context *ctx, struct
> gl_shader_program *shProg)
>
>_mesa_copy_linked_program_data((gl_shader_stage) stage, shProg, prog);
>
> - void *mem_ctx = ralloc_context(NULL);
>bool progress;
>
> - if (shader->ir)
> - ralloc_free(shader->ir);
> - shader->ir = new(shader) exec_list;
> - clone_ir_list(mem_ctx, shader->ir, shader->base.ir);
> -
>/* lower_packing_builtins() inserts arithmetic instructions, so it
> * must precede lower_instructions().
> */
> - brw_lower_packing_builtins(brw, (gl_shader_stage) stage, shader->ir);
> - do_mat_op_to_vec(shader->ir);
> + brw_lower_packing_builtins(brw, (gl_shader_stage) stage,
> shader->base.ir);
> + do_mat_op_to_vec(shader->base.ir);
>const int bitfield_insert = brw->gen >= 7
>? BITFIELD_INSERT_TO_BFM_BFI
>: 0;
>const int lrp_to_arith = brw->gen < 6 ? LRP_TO_ARITH : 0;
> - lower_instructions(shader->ir,
> + lower_instructions(shader->base.ir,
>MOD_TO_FRACT |
>DIV_TO_MUL_RCP |
>SUB_TO_ADD_NEG |
> @@ -166,17 +160,17 @@ brw_link_shader(struct gl_context *ctx, struct
> gl_shader_program *shProg)
> * if-statements need to be flattened.
> */
>if (brw->gen < 6)
> - lower_if_to_cond_assign(shader->ir, 16);
> -
> - do_lower_texture_projection(shader->ir);
> - brw_lower_texture_gradients(brw, shader->ir);
> - do_vec_index_to_cond_assign(shader->ir);
> - lower_vector_insert(shader->ir, true);
> - brw_do_cubemap_normalize(shader->ir);
> - brw_do_lower_offset_arrays(shader->ir);
> - brw_do_lower_unnormalized_offset(shader->ir);
> - lower_noise(shader->ir);
> - lower_quadop_vector(shader->ir, false);
> + lower_if_to_cond_assign(shader->base.ir, 16);
> +
> + do_lower_texture_projection(shader->base.ir);
> + brw_lower_texture_gradients(brw, shader->base.ir);
> + do_vec_index_to_
Re: [Mesa-dev] [V3 PATCH 2/8] mesa: Change 4 color component ubyte formats
On Fri, Jan 17, 2014 at 8:58 AM, Brian Paul wrote:
> On 01/17/2014 03:45 AM, Mark Mueller wrote:
>
>> Change all 4 color component unsigned byte formats to meet spec:
>> s/MESA_FORMAT_RGBA\b/MESA_FORMAT_ABGR_UNORM8/g
>> s/MESA_FORMAT_RGBA_REV\b/MESA_FORMAT_RGBA_UNORM8/g
>> s/MESA_FORMAT_ARGB\b/MESA_FORMAT_BGRA_UNORM8/g
>> s/MESA_FORMAT_ARGB_REV\b/MESA_FORMAT_ARGB_UNORM8/g
>> s/MESA_FORMAT_RGBX\b/MESA_FORMAT_XBGR_UNORM8/g
>> s/MESA_FORMAT_RGBX_REV\b/MESA_FORMAT_RGBX_UNORM8/g
>> s/MESA_FORMAT_XRGB\b/MESA_FORMAT_BGRX_UNORM8/g
>> s/MESA_FORMAT_XRGB_REV\b/MESA_FORMAT_XRGB_UNORM8/g
>>
>>
>
> I'm not sure this is right. If you look at the existing code such as
> src/mesa/main/format_{un}pack.c you'll see that these formats are treated
> as packed formats, not arrays.
>
>
Ah. Array formats are really rare with OGL, that was unexpected but now
really ancient issues with memory throughput optimization are surfacing.
Those were the days.
Thus Array Types would only include the much smaller group of all 32
bit-per-component formats, and formats with an odd number of 8 or 16 bit
components. Right?
So the naming convention would be a derivation of
MESA_FORMAT_R8G8B8A8_UNORM for these.
Mark
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] trace: Re-license trace.xsl under MIT license.
Brian Paul writes: > On 01/17/2014 08:33 AM, jfons...@vmware.com wrote: >> From: José Fonseca >> >> I was the sole author, as Tungsten Graphics employee, which was since >> then acquired by VMware Inc. >> --- >> src/gallium/drivers/trace/trace.xsl | 36 >> ++-- >> 1 file changed, 22 insertions(+), 14 deletions(-) >> >> diff --git a/src/gallium/drivers/trace/trace.xsl >> b/src/gallium/drivers/trace/trace.xsl >> index 7be95e0..12458ae 100644 >> --- a/src/gallium/drivers/trace/trace.xsl >> +++ b/src/gallium/drivers/trace/trace.xsl >> @@ -2,20 +2,28 @@ >> >>
[Mesa-dev] [PATCH V2 1/3] i965: Add an option to ignore sample qualifier
This will be useful in my next patch which depends on a functionality
of _mesa_get_min_invocations_per_fragment() to ignore the sample
qualifier (prog->IsSample) based on a flag passed to it.
Signed-off-by: Anuj Phogat
Cc: Chris Forbes
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/brw_wm.c| 2 +-
src/mesa/drivers/dri/i965/gen6_wm_state.c | 2 +-
src/mesa/drivers/dri/i965/gen7_wm_state.c | 4 ++--
src/mesa/program/program.c| 5 +++--
src/mesa/program/program.h| 3 ++-
5 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
b/src/mesa/drivers/dri/i965/brw_wm.c
index 6739a91..dee73c0 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -504,7 +504,7 @@ static void brw_wm_populate_key( struct brw_context *brw,
/* _NEW_BUFFERS _NEW_MULTISAMPLE */
key->compute_pos_offset =
- _mesa_get_min_invocations_per_fragment(ctx, &fp->program) > 1 &&
+ _mesa_get_min_invocations_per_fragment(ctx, &fp->program, false) > 1 &&
fp->program.Base.SystemValuesRead & SYSTEM_BIT_SAMPLE_POS;
key->compute_sample_id =
diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c
b/src/mesa/drivers/dri/i965/gen6_wm_state.c
index 83a1708..0bb5ef3 100644
--- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
@@ -161,7 +161,7 @@ upload_wm_state(struct brw_context *brw)
* better performance than 'SIMD8 only' dispatch.
*/
int min_inv_per_frag =
- _mesa_get_min_invocations_per_fragment(ctx, brw->fragment_program);
+ _mesa_get_min_invocations_per_fragment(ctx, brw->fragment_program,
false);
assert(min_inv_per_frag >= 1);
if (brw->wm.prog_data->prog_offset_16) {
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c
b/src/mesa/drivers/dri/i965/gen7_wm_state.c
index b6561bb..8dcefc2 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_state.c
@@ -103,7 +103,7 @@ upload_wm_state(struct brw_context *brw)
else
dw1 |= GEN7_WM_MSRAST_OFF_PIXEL;
- if (_mesa_get_min_invocations_per_fragment(ctx, brw->fragment_program) >
1)
+ if (_mesa_get_min_invocations_per_fragment(ctx, brw->fragment_program,
false) > 1)
dw2 |= GEN7_WM_MSDISPMODE_PERSAMPLE;
else
dw2 |= GEN7_WM_MSDISPMODE_PERPIXEL;
@@ -236,7 +236,7 @@ upload_ps_state(struct brw_context *brw)
* better performance than 'SIMD8 only' dispatch.
*/
int min_inv_per_frag =
- _mesa_get_min_invocations_per_fragment(ctx, brw->fragment_program);
+ _mesa_get_min_invocations_per_fragment(ctx, brw->fragment_program,
false);
assert(min_inv_per_frag >= 1);
if (brw->wm.prog_data->prog_offset_16) {
diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c
index 3c19e8c..ea8eb0d 100644
--- a/src/mesa/program/program.c
+++ b/src/mesa/program/program.c
@@ -1023,7 +1023,8 @@ _mesa_postprocess_program(struct gl_context *ctx, struct
gl_program *prog)
*/
GLint
_mesa_get_min_invocations_per_fragment(struct gl_context *ctx,
- const struct gl_fragment_program *prog)
+ const struct gl_fragment_program *prog,
+ bool ignore_sample_qualifier)
{
/* From ARB_sample_shading specification:
* "Using gl_SampleID in a fragment shader causes the entire shader
@@ -1041,7 +1042,7 @@ _mesa_get_min_invocations_per_fragment(struct gl_context
*ctx,
* "Use of the "sample" qualifier on a fragment shader input
* forces per-sample shading"
*/
- if (prog->IsSample)
+ if (prog->IsSample && !ignore_sample_qualifier)
return MAX2(ctx->DrawBuffer->Visual.samples, 1);
if (prog->Base.SystemValuesRead & (SYSTEM_BIT_SAMPLE_ID |
diff --git a/src/mesa/program/program.h b/src/mesa/program/program.h
index 0e350cd..c47ac1c 100644
--- a/src/mesa/program/program.h
+++ b/src/mesa/program/program.h
@@ -189,7 +189,8 @@ _mesa_postprocess_program(struct gl_context *ctx, struct
gl_program *prog);
extern GLint
_mesa_get_min_invocations_per_fragment(struct gl_context *ctx,
- const struct gl_fragment_program *prog);
+ const struct gl_fragment_program *prog,
+ bool ignore_sample_qualifier);
static inline GLuint
_mesa_program_enum_to_shader_stage(GLenum v)
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V2 3/3] i965: Ignore 'centroid' interpolation qualifier in case of persample shading
This patch handles the use of 'centroid' qualifier with 'in' variables
in a fragment shader when persample shading is enabled. Per sample
shading for the whole fragment shader can be enabled by:
glEnable(GL_SAMPLE_SHADING) or using {gl_SamplePosition, gl_SampleID}
builtin variables in fragment shader. Explaining it below in more
detail.
/* Enable sample shading using OpenGL API */
glEnable(GL_SAMPLE_SHADING);
glMinSampleShading(1.0);
Example fragment shader:
in vec4 a;
centroid in vec4 b;
main()
{
...
}
Variable 'a' will be interpolated at sample location. But, what
interpolation should we use for variable 'b' ?
ARB_sample_shading recommends interpolation at sample position for
all the variables. GLSL 400 (and earlier) spec says that:
"When an interpolation qualifier is used, it overrides settings
established through the OpenGL API."
But, this text got deleted in later versions of GLSL.
NVIDIA's and AMD's proprietary linux drivers (at OpenGL 4.3)
interpolates at sample position. This convinces me to use
the similar approach on intel hardware.
Signed-off-by: Anuj Phogat
Cc: Chris Forbes
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 520443d..66170c0 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1089,7 +1089,7 @@ fs_visitor::emit_general_interpolation(ir_variable *ir)
*/
struct brw_reg interp = interp_reg(location, k);
emit_linterp(attr, fs_reg(interp), interpolation_mode,
-ir->data.centroid,
+ir->data.centroid && !c->key.persample_shading,
ir->data.sample || c->key.persample_shading);
if (brw->needs_unlit_centroid_workaround && ir->data.centroid) {
/* Get the pixel/sample mask into f0 so that we know
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V2 2/3] i965: Use sample barycentric coordinates with per sample shading
Current implementation of arb_sample_shading doesn't set 'Barycentric
Interpolation Mode' correctly. We use pixel barycentric coordinates
for per sample shading. Instead we should select perspective sample
or non-perspective sample barycentric coordinates.
It also enables using sample barycentric coordinates in case of a
fragment shader variable declared with 'sample' qualifier.
e.g. sample in vec4 pos;
A piglit test to verify the implementation has been posted on piglit
mailing list for review.
V2: Do not interpolate all the 'in' variables at sample position
if fragment shader uses 'sample' qualifier with one of them.
For example we have a fragment shader:
#version 330
#extension ARB_gpu_shader5: require
sample in vec4 a;
in vec4 b;
main()
{
...
}
Only 'a' should be sampled at sample location, not 'b'.
Signed-off-by: Anuj Phogat
Cc: Chris Forbes
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 13 ++---
src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
src/mesa/drivers/dri/i965/brw_wm.c | 20 ++--
src/mesa/drivers/dri/i965/brw_wm.h | 1 +
4 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index baf9220..520443d 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -998,7 +998,7 @@ fs_visitor::emit_fragcoord_interpolation(ir_variable *ir)
fs_inst *
fs_visitor::emit_linterp(const fs_reg &attr, const fs_reg &interp,
glsl_interp_qualifier interpolation_mode,
- bool is_centroid)
+ bool is_centroid, bool is_sample)
{
brw_wm_barycentric_interp_mode barycoord_mode;
if (brw->gen >= 6) {
@@ -1007,6 +1007,11 @@ fs_visitor::emit_linterp(const fs_reg &attr, const
fs_reg &interp,
barycoord_mode = BRW_WM_PERSPECTIVE_CENTROID_BARYCENTRIC;
else
barycoord_mode = BRW_WM_NONPERSPECTIVE_CENTROID_BARYCENTRIC;
+ } else if (is_sample) {
+ if (interpolation_mode == INTERP_QUALIFIER_SMOOTH)
+barycoord_mode = BRW_WM_PERSPECTIVE_SAMPLE_BARYCENTRIC;
+ else
+barycoord_mode = BRW_WM_NONPERSPECTIVE_SAMPLE_BARYCENTRIC;
} else {
if (interpolation_mode == INTERP_QUALIFIER_SMOOTH)
barycoord_mode = BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC;
@@ -1084,7 +1089,8 @@ fs_visitor::emit_general_interpolation(ir_variable *ir)
*/
struct brw_reg interp = interp_reg(location, k);
emit_linterp(attr, fs_reg(interp), interpolation_mode,
-ir->data.centroid);
+ir->data.centroid,
+ir->data.sample || c->key.persample_shading);
if (brw->needs_unlit_centroid_workaround && ir->data.centroid) {
/* Get the pixel/sample mask into f0 so that we know
* which pixels are lit. Then, for each channel that is
@@ -1093,7 +1099,8 @@ fs_visitor::emit_general_interpolation(ir_variable *ir)
*/
emit(FS_OPCODE_MOV_DISPATCH_TO_FLAGS);
fs_inst *inst = emit_linterp(attr, fs_reg(interp),
- interpolation_mode, false);
+ interpolation_mode,
+ false, false);
inst->predicate = BRW_PREDICATE_NORMAL;
inst->predicate_inverse = true;
}
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 9bef07c..b5656bf 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -336,7 +336,7 @@ public:
fs_reg *emit_fragcoord_interpolation(ir_variable *ir);
fs_inst *emit_linterp(const fs_reg &attr, const fs_reg &interp,
glsl_interp_qualifier interpolation_mode,
- bool is_centroid);
+ bool is_centroid, bool is_sample);
fs_reg *emit_frontfacing_interpolation(ir_variable *ir);
fs_reg *emit_samplepos_setup(ir_variable *ir);
fs_reg *emit_sampleid_setup(ir_variable *ir);
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
b/src/mesa/drivers/dri/i965/brw_wm.c
index dee73c0..e61e11f 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -49,6 +49,7 @@
static unsigned
brw_compute_barycentric_interp_modes(struct brw_context *brw,
bool shade_model_flat,
+ bool persample_shading,
const struct gl_fragment_program *fprog)
{
unsigned barycentric_interp_modes = 0;
@@ -62,6 +63,8 @@ brw_compute_barycentric_interp_modes(struct brw_context *brw,
enum
Re: [Mesa-dev] [PATCH 2/2] s/Tungsten Graphics/VMware/
On 01/17/2014 08:33 AM, jfons...@vmware.com wrote:
> diff --git a/src/mesa/drivers/dri/r200/r200_context.c
> b/src/mesa/drivers/dri/r200/r200_context.c
> index f82424b..f613e56 100644
> --- a/src/mesa/drivers/dri/r200/r200_context.c
> +++ b/src/mesa/drivers/dri/r200/r200_context.c
> @@ -29,7 +29,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> SOFTWARE.
>
> /*
> * Authors:
> - * Keith Whitwell
> + * Keith Whitwell
> */
>
> #include
> @@ -80,7 +80,7 @@ static const GLubyte *r200GetString( struct gl_context
> *ctx, GLenum name )
>
> switch ( name ) {
> case GL_VENDOR:
> - return (GLubyte *)"Tungsten Graphics, Inc.";
> + return (GLubyte *)"VMware, Inc.";
>
Since VMware isn't maintaining radeon or r200, I seems like this should
be "Mesa Project", like swrast.
> case GL_RENDERER:
>offset = driGetRendererString( buffer, "R200", agp_mode );
> diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.c
> b/src/mesa/drivers/dri/radeon/radeon_common_context.c
> index 6dec137..487cb83 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_common_context.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_common_context.c
> @@ -80,7 +80,7 @@ static const GLubyte *radeonGetString(struct gl_context *
> ctx, GLenum name)
>
> switch (name) {
> case GL_VENDOR:
> - return (GLubyte *) "Tungsten Graphics, Inc.";
> + return (GLubyte *) "VMware, Inc.";
>
> case GL_RENDERER:
> {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] s/Tungsten Graphics/VMware/
On 01/17/2014 12:56 PM, Ian Romanick wrote:
On 01/17/2014 08:33 AM, jfons...@vmware.com wrote:
diff --git a/src/mesa/drivers/dri/r200/r200_context.c
b/src/mesa/drivers/dri/r200/r200_context.c
index f82424b..f613e56 100644
--- a/src/mesa/drivers/dri/r200/r200_context.c
+++ b/src/mesa/drivers/dri/r200/r200_context.c
@@ -29,7 +29,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
/*
* Authors:
- * Keith Whitwell
+ * Keith Whitwell
*/
#include
@@ -80,7 +80,7 @@ static const GLubyte *r200GetString( struct gl_context *ctx,
GLenum name )
switch ( name ) {
case GL_VENDOR:
- return (GLubyte *)"Tungsten Graphics, Inc.";
+ return (GLubyte *)"VMware, Inc.";
Since VMware isn't maintaining radeon or r200, I seems like this should
be "Mesa Project", like swrast.
Yeah, the last thing we need is people contacting us when they have
problems with these drivers.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: munmap_chunk(): invalid pointer in libgl1-mesa-dri_9.2.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/2014 10:42 PM, scarp wrote: > Hi, > > I originally posted this to dri-users and got no response. I > thought about it further and decided it's really a bug and deserves > to be posted to dri-devel, after all it is a crash and crashes are > supposed to be handled. These days dri-* is generally for kernel related discussions. mesa-* is the right place. I'm moving the discussion to mesa-dev. > Any custom configurations provided by Whonix can be found in: > > Gateway VM that has Tor process: > https://github.com/adrelanos/Whonix/tree/master/whonix_gateway > > Shared, files that are used in both virtual machines > https://github.com/adrelanos/Whonix/tree/master/whonix_shared > > Files only used in the Workstation VM > https://github.com/adrelanos/Whonix/tree/master/whonix_workstation > > > In case this is something like a grub config option or something > like that is why I posted these. > > > Original Message Subject: munmap_chunk(): invalid > pointer in libgl1-mesa-dri_9.2.1-1 Date: Thu, 26 Dec 2013 07:13:45 > + From: scarp To: > dri-us...@lists.freedesktop.org > > Hi, > > I've been testing the privacy orientated virtual machine > distribution Whonix http://whonix.org. It's a Debian blend > specifically designed to be an anonymous operating system. In this > case I am using the latest VirtualBox (4.3.6) - without guest > utilities. > > Recently I started having some problems with xvideo, in things > like mplayer and vlc, and also glxinfo from mesa-utils. Where they > would simply crash with an error and a backtrace. Exactly this one: > (full crash attached) > > *** Error in `glxinfo': munmap_chunk(): invalid pointer: > 0x0138d8a0 *** === Backtrace: = > /lib/x86_64-linux-gnu/libc.so.6(+0x7aa16)[0x7f88a36f2a16] > /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so(+0x248688)[0x7f88a04e6688] > > /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so(+0x3263a3)[0x7f88a05c43a3] > /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so(+0x14f412)[0x7f88a03ed412] > > /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so(dri_destroy_context+0x38)[0x7f88a0597a58] > /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so(+0x450c3)[0x7f88a02e30c3] > > /usr/lib/x86_64-linux-gnu/libGL.so.1(+0x3b34f)[0x7f88a42aa34f] > /usr/lib/x86_64-linux-gnu/libGL.so.1(+0x1c281)[0x7f88a428b281] > /usr/lib/x86_64-linux-gnu/libGL.so.1(+0x1c305)[0x7f88a428b305] > /usr/lib/x86_64-linux-gnu/libX11.so.6(XCloseDisplay+0xa2)[0x7f88a3c55c02] > > glxinfo[0x401c14] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f88a365] > > glxinfo[0x401ee6] If this distro has "debug" packages, you should install those for libgl1-mesa-dri. That way the backtrace can have source file names and line numbers. You might also try running with valgrind. > I discovered the problem was directly related to libgl1-mesa-dri. > Rolling back to the previous version of the package made the > problem disappear. > > libgl1-mesa-dri_9.1.7-1 works > http://snapshot.debian.org/package/mesa/9.1.7-1/#libgl1-mesa-dri_9.1.7-1 > > libgl1-mesa-dri_9.2.1-1 doesn't > http://snapshot.debian.org/package/mesa/9.2-1/#libgl1-mesa-dri_9.2-1 > > I'm wondering what could have changed in between these two > versions? > > I installed the whole "xorg" metapackage from Debian and it didn't > seem to help. I thought maybe some functionality of > libgl1-mesa-dri might have been modularized into another package. > Rolling that package back seemed to fix it. > > Whonix by default uses KDE, however I was able to reproduce the > crash when using TWM as well. > > The interesting thing is I couldn't reproduce it with a stock > standard desktop install from debian-testing-amd64-kde-CD-1.iso I > did a comparison of the packages installed ie dpkg -l in both > Whonix and debian-testing-amd64-kde-CD-1.iso and didn't find that > anything was missing. > > It has been reported by one other user > https://www.whonix.org/wiki/Special:AWCforum/st/id282/vlc_video_crash.html > > and while a work around for VLC was found it doesn't really solve this > issue. > > If anyone doesn't know what could be causing this perhaps you can > give me some tips on how to find out what is. > > > > > ___ dri-devel mailing > list dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iEYEARECAAYFAlLZmnUACgkQX1gOwKyEAw81+ACcCqyjnMfMu4SzW0YAXY9cNLy2 ZVcAn13HVtF/AATtrMW0+TPzIAwfmC3z =Yko4 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/16] i965/fs: Add local value numbering optimization pass.
On Thu, Dec 19, 2013 at 1:40 PM, Matt Turner wrote:
Could you add some commit message text?
Maybe with a small example.
> total instructions in shared programs: 1520829 -> 1511991 (-0.58%)
> instructions in affected programs: 559725 -> 550887 (-1.58%)
> GAINED:6
> LOST: 9
> ---
> src/mesa/drivers/dri/i965/Makefile.sources | 1 +
> src/mesa/drivers/dri/i965/brw_fs.cpp | 37 +-
> src/mesa/drivers/dri/i965/brw_fs.h | 1 +
> .../drivers/dri/i965/brw_fs_value_numbering.cpp| 398
> +
> 4 files changed, 435 insertions(+), 2 deletions(-)
> create mode 100644 src/mesa/drivers/dri/i965/brw_fs_value_numbering.cpp
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index 43f152e..36d8261 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -63,6 +63,7 @@ i965_FILES = \
> brw_fs_peephole_predicated_break.cpp \
> brw_fs_reg_allocate.cpp \
> brw_fs_sel_peephole.cpp \
> + brw_fs_value_numbering.cpp \
> brw_fs_vector_splitting.cpp \
> brw_fs_visitor.cpp \
> brw_gs.c \
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index e4a4737..08837da 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -3285,9 +3285,11 @@ fs_visitor::run()
>remove_dead_constants();
>setup_pull_constants();
>
> - bool progress;
> + bool progress, cp_progress, vn_progress;
>do {
> progress = false;
> + cp_progress = false;
> + vn_progress = false;
>
> compact_virtual_grfs();
>
> @@ -3295,16 +3297,47 @@ fs_visitor::run()
>
> progress = opt_algebraic() || progress;
> progress = opt_cse() || progress;
> -progress = opt_copy_propagate() || progress;
> progress = opt_peephole_predicated_break() || progress;
> +cp_progress = opt_copy_propagate();
> progress = dead_code_eliminate() || progress;
> progress = dead_code_eliminate_local() || progress;
> progress = opt_peephole_sel() || progress;
> progress = dead_control_flow_eliminate(this) || progress;
> + vn_progress = opt_value_numbering();
> progress = register_coalesce() || progress;
> progress = compute_to_mrf() || progress;
> +
> + /* Value numbering rewrites
> + *
> + *MOV g5, 1.0F
> + *MOV g6, 1.0F
> + *
> + * into
> + *
> + *MOV g5, 1.0F
> + *MOV g6, g5
> + *
> + * but constant propagation undoes this. If these were the only two
> + * passes to make progress, they're just fighting.
> + */
> + if (!progress && (cp_progress != vn_progress)) {
> +progress = true;
> + }
>} while (progress);
>
> + /* Copy propagation and value numbering were fighting, which means that
> + * the last changes made by value numbering weren't useful, so rerun
> + * copy propagation and the rest of the optimizations after it, modulo
> + * value numbering.
> + */
> + if (cp_progress && vn_progress) {
> + opt_copy_propagate();
> + dead_code_eliminate();
> + dead_code_eliminate_local();
> + register_coalesce();
> + compute_to_mrf();
> + }
> +
>lower_uniform_pull_constant_loads();
>
>assign_curb_setup();
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
> b/src/mesa/drivers/dri/i965/brw_fs.h
> index 853cf3c..75de18e 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.h
> +++ b/src/mesa/drivers/dri/i965/brw_fs.h
> @@ -312,6 +312,7 @@ public:
> bool opt_algebraic();
> bool opt_cse();
> bool opt_cse_local(bblock_t *block, exec_list *aeb);
> + bool opt_value_numbering();
> bool opt_copy_propagate();
> bool try_copy_propagate(fs_inst *inst, int arg, acp_entry *entry);
> bool try_constant_propagate(fs_inst *inst, acp_entry *entry);
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_value_numbering.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_value_numbering.cpp
> new file mode 100644
> index 000..fc7299c
> --- /dev/null
> +++ b/src/mesa/drivers/dri/i965/brw_fs_value_numbering.cpp
> @@ -0,0 +1,398 @@
> +/*
> + * Copyright © 2013 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject
Re: [Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.
The test seems to work correctly with 32 textures per stage. It tests that all textures return the correct color, but the sampler state is always the same. Marek On Thu, Jan 16, 2014 at 1:28 AM, Kenneth Graunke wrote: > On 01/15/2014 12:56 PM, Chris Forbes wrote: >> Does this actually work for >16? >> >> Sampler messages' descriptor only has 4 bits for the sampler index, so >> it seems you'd silently lose the top bit and get the wrong sampler >> parameters. > > Oh, wow. No...no, it can't possibly work then. (Apparently that Piglit > test isn't sufficient...I just glanced at it...) > > It looks like the Intel Windows driver has bumped this to 32 on Haswell > (but not earlier). I'm guessing that they use the "Sampler State > Pointer" field in the message /header/, instead of the "Sampler Index" > field in the message /descriptor/. On Haswell, that changed to be > relative to Dynamic State Base Address instead of General State Base > Address. Which probably helps. > > Still, that's probably going to be kind of miserable. I'll have to look > into what they're doing. > > NAK on patch 2. > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] code de-duplication and non-pci support
With Kristian's comment about keeping the original copyright notices intact addressed, patches 1, 2, 3, 4, 7, 8, and 10 are Reviewed-by: Ian Romanick On 12/14/2013 11:28 AM, Rob Clark wrote: > From: Rob Clark > > It seems that over time, code related to finding driver name, dealing > with pci-id table, etc, has been copy/pasted everywhere it was needed. > Which is lame. And annoying if you have a device which is not pci. > > This patchset refactors it out into a simple loader util lib which is > statically linked wherever it is needed. Perhaps there is some room > for sharing other util bits (like _eglLog, perhaps) later. > > And once all this code is collected in one place, the 2nd patch only > has to fix one place to add support for platform devices ;-) > > Rob Clark (2): > loader: refactor duplicated code into loader util lib > loader: fallback to drmGetVersion() for non-pci devices > > configure.ac | 1 + > include/pci_ids/pci_id_driver_map.h| 29 ++- > src/Makefile.am| 2 +- > src/egl/drivers/dri2/Makefile.am | 5 +- > src/egl/drivers/dri2/common.c | 144 --- > src/egl/drivers/dri2/egl_dri2.h| 5 - > src/egl/drivers/dri2/platform_android.c| 105 +--- > src/egl/drivers/dri2/platform_drm.c| 5 +- > src/egl/drivers/dri2/platform_wayland.c| 5 +- > src/gallium/auxiliary/pipe-loader/Makefile.am | 4 + > src/gallium/auxiliary/pipe-loader/pipe_loader.h| 1 + > .../auxiliary/pipe-loader/pipe_loader_drm.c| 92 +-- > src/gallium/state_trackers/clover/core/device.cpp | 2 + > src/gallium/targets/egl-static/Makefile.am | 2 + > src/gallium/targets/egl-static/egl.c | 186 +- > src/gbm/Makefile.am| 10 +- > src/gbm/backends/dri/driver_name.c | 89 --- > src/gbm/backends/dri/gbm_dri.c | 3 +- > src/gbm/backends/dri/gbm_driint.h | 3 - > src/glx/dri3_common.c | 146 --- > src/glx/dri3_glx.c | 3 +- > src/glx/dri3_priv.h| 3 - > src/loader/Makefile.am | 37 +++ > src/loader/loader.c| 276 > + > src/loader/loader.h| 57 + > 25 files changed, 442 insertions(+), 773 deletions(-) > delete mode 100644 src/egl/drivers/dri2/common.c > delete mode 100644 src/gbm/backends/dri/driver_name.c > delete mode 100644 src/glx/dri3_common.c > create mode 100644 src/loader/Makefile.am > create mode 100644 src/loader/loader.c > create mode 100644 src/loader/loader.h > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.
On 01/17/2014 01:08 PM, Marek Olšák wrote: > The test seems to work correctly with 32 textures per stage. It tests > that all textures return the correct color, but the sampler state is > always the same. Which is the problem. The method we're using to access samplers works fine for up to 16, but fails after that... by dropping the high-order index bits. If all the samplers are the same, the test won't notice that Ken's implementation is garbage. :( > Marek > > On Thu, Jan 16, 2014 at 1:28 AM, Kenneth Graunke > wrote: >> On 01/15/2014 12:56 PM, Chris Forbes wrote: >>> Does this actually work for >16? >>> >>> Sampler messages' descriptor only has 4 bits for the sampler index, so >>> it seems you'd silently lose the top bit and get the wrong sampler >>> parameters. >> >> Oh, wow. No...no, it can't possibly work then. (Apparently that Piglit >> test isn't sufficient...I just glanced at it...) >> >> It looks like the Intel Windows driver has bumped this to 32 on Haswell >> (but not earlier). I'm guessing that they use the "Sampler State >> Pointer" field in the message /header/, instead of the "Sampler Index" >> field in the message /descriptor/. On Haswell, that changed to be >> relative to Dynamic State Base Address instead of General State Base >> Address. Which probably helps. >> >> Still, that's probably going to be kind of miserable. I'll have to look >> into what they're doing. >> >> NAK on patch 2. >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [V3 PATCH 2/8] mesa: Change 4 color component ubyte formats
Incorrect. You have to manually check if the pack and unpack functions
access the components using bitwise operations or arrays.
Consider char pix[]. The array formats use arrays for accessing, for example:
char *p = &pix[(y*width+x)*4];
p[0] = r;
p[1] = g;
p[2] = b;
p[3] = a;
Packed formats use bitwise operators for accessing, for example:
uint32_t *p = &pix[(y*width+x)*4];
*p = r | (g << 8) | (b << 16) | (a << 24);
It's okay to have both RGBA8 array and packed formats. For example,
Gallium has these array formats:
PIPE_FORMAT_R8G8B8A8_UNORM
PIPE_FORMAT_B8G8R8A8_UNORM
PIPE_FORMAT_A8R8G8B8_UNORM
PIPE_FORMAT_A8B8G8R8_UNORM
And it defines these packed formats by using the array formats
according to the CPU architecture:
#if defined(PIPE_ARCH_LITTLE_ENDIAN)
#define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
#define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
#define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#elif defined(PIPE_ARCH_BIG_ENDIAN)
#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
#define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
#define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
#define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#endif
This way, Gallium has all the possible RGBA8 array formats and also
the possible RGBA8 packed formats, so we can use whatever we want.
Marek
On Fri, Jan 17, 2014 at 9:41 PM, Mark Mueller wrote:
>
>
>
> On Fri, Jan 17, 2014 at 8:58 AM, Brian Paul wrote:
>>
>> On 01/17/2014 03:45 AM, Mark Mueller wrote:
>>>
>>> Change all 4 color component unsigned byte formats to meet spec:
>>> s/MESA_FORMAT_RGBA\b/MESA_FORMAT_ABGR_UNORM8/g
>>> s/MESA_FORMAT_RGBA_REV\b/MESA_FORMAT_RGBA_UNORM8/g
>>> s/MESA_FORMAT_ARGB\b/MESA_FORMAT_BGRA_UNORM8/g
>>> s/MESA_FORMAT_ARGB_REV\b/MESA_FORMAT_ARGB_UNORM8/g
>>> s/MESA_FORMAT_RGBX\b/MESA_FORMAT_XBGR_UNORM8/g
>>> s/MESA_FORMAT_RGBX_REV\b/MESA_FORMAT_RGBX_UNORM8/g
>>> s/MESA_FORMAT_XRGB\b/MESA_FORMAT_BGRX_UNORM8/g
>>> s/MESA_FORMAT_XRGB_REV\b/MESA_FORMAT_XRGB_UNORM8/g
>>>
>>
>>
>> I'm not sure this is right. If you look at the existing code such as
>> src/mesa/main/format_{un}pack.c you'll see that these formats are treated as
>> packed formats, not arrays.
>>
>
> Ah. Array formats are really rare with OGL, that was unexpected but now
> really ancient issues with memory throughput optimization are surfacing.
> Those were the days.
>
> Thus Array Types would only include the much smaller group of all 32
> bit-per-component formats, and formats with an odd number of 8 or 16 bit
> components. Right?
>
> So the naming convention would be a derivation of MESA_FORMAT_R8G8B8A8_UNORM
> for these.
>
> Mark
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [V3 PATCH 2/8] mesa: Change 4 color component ubyte formats
On 01/17/2014 12:41 PM, Mark Mueller wrote:
On Fri, Jan 17, 2014 at 8:58 AM, Brian Paul mailto:bri...@vmware.com>> wrote:
On 01/17/2014 03:45 AM, Mark Mueller wrote:
Change all 4 color component unsigned byte formats to meet spec:
s/MESA_FORMAT_RGBA\b/MESA___FORMAT_ABGR_UNORM8/g
s/MESA_FORMAT_RGBA_REV\b/__MESA_FORMAT_RGBA_UNORM8/g
s/MESA_FORMAT_ARGB\b/MESA___FORMAT_BGRA_UNORM8/g
s/MESA_FORMAT_ARGB_REV\b/__MESA_FORMAT_ARGB_UNORM8/g
s/MESA_FORMAT_RGBX\b/MESA___FORMAT_XBGR_UNORM8/g
s/MESA_FORMAT_RGBX_REV\b/__MESA_FORMAT_RGBX_UNORM8/g
s/MESA_FORMAT_XRGB\b/MESA___FORMAT_BGRX_UNORM8/g
s/MESA_FORMAT_XRGB_REV\b/__MESA_FORMAT_XRGB_UNORM8/g
I'm not sure this is right. If you look at the existing code such
as src/mesa/main/format_{un}pack.__c you'll see that these formats
are treated as packed formats, not arrays.
Ah. Array formats are really rare with OGL, that was unexpected but now
really ancient issues with memory throughput optimization are surfacing.
Those were the days.
Thus Array Types would only include the much smaller group of all 32
bit-per-component formats, and formats with an odd number of 8 or 16 bit
components. Right?
For the time being, I think the mesa formats which are packed should
stay packed and arrays stay as arrays. Otherwise, the
format_{un}pack.c, texstore, and s_texfetch.c code would need to be
changed accordingly.
Over time, we could probably migrate some of the packed formats to being
array formats.
So the naming convention would be a derivation of
MESA_FORMAT_R8G8B8A8_UNORM for these.
For the packed formats, yes. I believe that was the consensus from the
thread 3 days ago.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.
Ken, Assuming the caches don't completely derail things, you ought to be able to make this work with pretty minimal impact: - Keep the low four bits of the sampler index where they are - If the 5th bit is set: - Force message header on - Add 16*sizeof(sampler_state) to the copy of r0.3 in the header. We already mangle the copy of r0.2 in various ways for offsetting / channel select so this isn't a huge change. With 4.0/ARB_gpu_shader5 you need to emit conditional code in some cases since you don't always know the sampler index at compile time, but it's still pretty manageable. -- Chris On Sat, Jan 18, 2014 at 10:22 AM, Ian Romanick wrote: > On 01/17/2014 01:08 PM, Marek Olšák wrote: >> The test seems to work correctly with 32 textures per stage. It tests >> that all textures return the correct color, but the sampler state is >> always the same. > > Which is the problem. The method we're using to access samplers works > fine for up to 16, but fails after that... by dropping the high-order > index bits. If all the samplers are the same, the test won't notice > that Ken's implementation is garbage. :( > >> Marek >> >> On Thu, Jan 16, 2014 at 1:28 AM, Kenneth Graunke >> wrote: >>> On 01/15/2014 12:56 PM, Chris Forbes wrote: Does this actually work for >16? Sampler messages' descriptor only has 4 bits for the sampler index, so it seems you'd silently lose the top bit and get the wrong sampler parameters. >>> >>> Oh, wow. No...no, it can't possibly work then. (Apparently that Piglit >>> test isn't sufficient...I just glanced at it...) >>> >>> It looks like the Intel Windows driver has bumped this to 32 on Haswell >>> (but not earlier). I'm guessing that they use the "Sampler State >>> Pointer" field in the message /header/, instead of the "Sampler Index" >>> field in the message /descriptor/. On Haswell, that changed to be >>> relative to Dynamic State Base Address instead of General State Base >>> Address. Which probably helps. >>> >>> Still, that's probably going to be kind of miserable. I'll have to look >>> into what they're doing. >>> >>> NAK on patch 2. >>> ___ >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 13/16] i965/fs: Add a saturation propagation optimization pass.
On Thu, Dec 19, 2013 at 1:40 PM, Matt Turner wrote:
> Transforms, for example,
>
> mul vgrf3, vgrf2, vgrf1
> mov.sat vgrf4, vgrf3
>
> into
>
> mul.sat vgrf3, vgrf2, vgrf1
> mov vgrf4, vgrf3
>
> which gives register_coalescing an opportunity to remove the MOV
> instruction.
>
> total instructions in shared programs: 1512588 -> 1501297 (-0.75%)
> instructions in affected programs: 723097 -> 711806 (-1.56%)
> GAINED:0
> LOST: 4
> ---
> src/mesa/drivers/dri/i965/Makefile.sources | 1 +
> src/mesa/drivers/dri/i965/brw_fs.cpp | 1 +
> src/mesa/drivers/dri/i965/brw_fs.h | 1 +
> .../dri/i965/brw_fs_saturate_propagation.cpp | 102
> +
> 4 files changed, 105 insertions(+)
> create mode 100644 src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index 36d8261..3f901da 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -62,6 +62,7 @@ i965_FILES = \
> brw_fs_live_variables.cpp \
> brw_fs_peephole_predicated_break.cpp \
> brw_fs_reg_allocate.cpp \
> + brw_fs_saturate_propagation.cpp \
> brw_fs_sel_peephole.cpp \
> brw_fs_value_numbering.cpp \
> brw_fs_vector_splitting.cpp \
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 08837da..12b6d4a 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -3304,6 +3304,7 @@ fs_visitor::run()
> progress = opt_peephole_sel() || progress;
> progress = dead_control_flow_eliminate(this) || progress;
> vn_progress = opt_value_numbering();
> + progress = opt_saturate_propagation() || progress;
> progress = register_coalesce() || progress;
> progress = compute_to_mrf() || progress;
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
> b/src/mesa/drivers/dri/i965/brw_fs.h
> index 75de18e..07360ae 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.h
> +++ b/src/mesa/drivers/dri/i965/brw_fs.h
> @@ -368,6 +368,7 @@ public:
> void try_replace_with_sel();
> bool opt_peephole_sel();
> bool opt_peephole_predicated_break();
> + bool opt_saturate_propagation();
> void emit_bool_to_cond_code(ir_rvalue *condition);
> void emit_if_gen6(ir_if *ir);
> void emit_unspill(fs_inst *inst, fs_reg reg, uint32_t spill_offset,
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
> new file mode 100644
> index 000..91a1338
> --- /dev/null
> +++ b/src/mesa/drivers/dri/i965/brw_fs_saturate_propagation.cpp
> @@ -0,0 +1,102 @@
> +/*
> + * Copyright © 2013 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include "brw_fs.h"
> +#include "brw_fs_live_variables.h"
> +#include "brw_cfg.h"
> +
> +/** @file brw_fs_saturate_propagation.cpp
> + */
> +
> +static bool
> +opt_saturate_propagation_local(fs_visitor *v, bblock_t *block)
> +{
> + bool progress = false;
> + int ip = block->start_ip;
> +
> + for (fs_inst *inst = (fs_inst *)block->start;
> +inst != block->end->next;
> +inst = (fs_inst *) inst->next) {
> + ip++;
> +
> + if (inst->opcode != BRW_OPCODE_MOV ||
> + inst->dst.file != GRF ||
> + !inst->saturate)
> + continue;
> +
> + int src_var = v->live_intervals->var_from_reg(&inst->src[0]);
> + int src_end_ip = v->live_intervals->end[src_var];
> + if (src_end_ip > ip && !inst->dst.equals(inst->src[0]))
> + continue;
> +
> + int scan_ip = ip;
> + bool interfered = f
Re: [Mesa-dev] [PATCH 2/2] s/Tungsten Graphics/VMware/
- Original Message -
> On 01/17/2014 12:56 PM, Ian Romanick wrote:
> > On 01/17/2014 08:33 AM, jfons...@vmware.com wrote:
> >> diff --git a/src/mesa/drivers/dri/r200/r200_context.c
> >> b/src/mesa/drivers/dri/r200/r200_context.c
> >> index f82424b..f613e56 100644
> >> --- a/src/mesa/drivers/dri/r200/r200_context.c
> >> +++ b/src/mesa/drivers/dri/r200/r200_context.c
> >> @@ -29,7 +29,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> >> SOFTWARE.
> >>
> >> /*
> >> * Authors:
> >> - * Keith Whitwell
> >> + * Keith Whitwell
> >> */
> >>
> >> #include
> >> @@ -80,7 +80,7 @@ static const GLubyte *r200GetString( struct gl_context
> >> *ctx, GLenum name )
> >>
> >> switch ( name ) {
> >> case GL_VENDOR:
> >> - return (GLubyte *)"Tungsten Graphics, Inc.";
> >> + return (GLubyte *)"VMware, Inc.";
> >>
> >
> > Since VMware isn't maintaining radeon or r200, I seems like this should
> > be "Mesa Project", like swrast.
>
> Yeah, the last thing we need is people contacting us when they have
> problems with these drivers.
Sounds good to me too.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73631] es2tri fragment shader did not compile AMD ARUBA
https://bugs.freedesktop.org/show_bug.cgi?id=73631 --- Comment #1 from Ian Romanick --- It sounds like the shader is broken. Probably just add precision mediump float; at global scope before any float (or vec, or mat) types are used. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Modify some error messages to refer to "vec4" instead of "vs".
These messages are in code that is shared between the VS and GS
back-ends, so use the terminology "vec4" to avoid confusion.
---
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 8
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index c1ef81d..51e88d2 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
@@ -327,7 +327,7 @@ vec4_generator::generate_tex(vec4_instruction *inst,
}
break;
default:
-assert(!"should not get here: invalid VS texture opcode");
+assert(!"should not get here: invalid vec4 texture opcode");
break;
}
} else {
@@ -356,7 +356,7 @@ vec4_generator::generate_tex(vec4_instruction *inst,
assert(inst->mlen == 2);
break;
default:
-assert(!"should not get here: invalid VS texture opcode");
+assert(!"should not get here: invalid vec4 texture opcode");
break;
}
}
@@ -1218,10 +1218,10 @@
vec4_generator::generate_vec4_instruction(vec4_instruction *instruction,
default:
if (inst->opcode < (int) ARRAY_SIZE(opcode_descs)) {
- _mesa_problem(&brw->ctx, "Unsupported opcode in `%s' in VS\n",
+ _mesa_problem(&brw->ctx, "Unsupported opcode in `%s' in vec4\n",
opcode_descs[inst->opcode].name);
} else {
- _mesa_problem(&brw->ctx, "Unsupported opcode %d in VS", inst->opcode);
+ _mesa_problem(&brw->ctx, "Unsupported opcode %d in vec4",
inst->opcode);
}
abort();
}
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 3b8cef6..81906e8 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -3343,7 +3343,7 @@ vec4_visitor::fail(const char *format, ...)
va_start(va, format);
msg = ralloc_vasprintf(mem_ctx, format, va);
va_end(va);
- msg = ralloc_asprintf(mem_ctx, "VS compile failed: %s\n", msg);
+ msg = ralloc_asprintf(mem_ctx, "vec4 compile failed: %s\n", msg);
this->fail_msg = msg;
--
1.8.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73631] es2tri fragment shader did not compile AMD ARUBA
https://bugs.freedesktop.org/show_bug.cgi?id=73631 --- Comment #2 from Emil Velikov --- Nice one Ian, adding "precision mediump float;" before the vec4 variable declaration in the fragment shader did the job. Running nouveau on a nv96, in case it matters. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] cl: Add support for OpenCV unit tests v2
From: Tom Stellard
This enables piglit to run and interpret the results from OpenCV's
gtest based opencv_test_ocl program.
This patch adds two new CMake configuration variables:
OPENCL_OpenCVTestOCL_BINDIR: You can use this variable to enable
the OpenCV tests by setting it to the full path of the
bin directory in your opencv build tree (e.g. /home/user/opencv/build/bin).
OPENCL_OpenCVTestOCL_WORKDIR: (Optional)If you don't want to use
OpenCV's default work directory, you can use this variable to specify
a different one.
v2:
- Python code cleanups
XXX: opencv
---
CMakeLists.txt| 9 ++-
tests/all_cl.py | 4 ++
tests/cl/program/execute/opencv-merge-hist.cl | 98 ---
tests/ocl_config.py.in| 31 +
tests/opencv.py | 76 +
5 files changed, 119 insertions(+), 99 deletions(-)
delete mode 100644 tests/cl/program/execute/opencv-merge-hist.cl
create mode 100644 tests/ocl_config.py.in
create mode 100644 tests/opencv.py
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 1befffb..37eac65 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -92,7 +92,10 @@ if(PIGLIT_BUILD_GLES3_TESTS AND NOT PIGLIT_USE_WAFFLE)
endif(PIGLIT_BUILD_GLES3_TESTS AND NOT PIGLIT_USE_WAFFLE)
if(PIGLIT_BUILD_CL_TESTS)
- find_package(OpenCL REQUIRED)
+find_package(OpenCL REQUIRED)
+set(OPENCL_OpenCVTestOCL_BINDIR "" CACHE STRING "Directory with the
opencv_ocl_test program" )
+set(OPENCL_OpenCVTestOCL_WORKDIR "" CACHE STRING
+"Directory with the opencv test resources (This is not needed if
your OpenCV build directory was $(opencv_src_dir)/build )" )
endif(PIGLIT_BUILD_CL_TESTS)
IF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
@@ -356,6 +359,10 @@ configure_file(
"${piglit_SOURCE_DIR}/tests/util/config.h.in"
"${piglit_BINARY_DIR}/tests/util/config.h"
)
+configure_file(
+ "${piglit_SOURCE_DIR}/tests/ocl_config.py.in"
+ "${piglit_BINARY_DIR}/tests/ocl_config.py"
+)
include(cmake/piglit_util.cmake)
include(cmake/piglit_glapi.cmake)
diff --git a/tests/all_cl.py b/tests/all_cl.py
index a7d7106..b9c112a 100644
--- a/tests/all_cl.py
+++ b/tests/all_cl.py
@@ -7,6 +7,8 @@ __all__ = ['profile']
import os
import os.path as path
+from tests.opencv import add_opencv_tests
+
from framework.core import Group, TestProfile
from framework.exectest import PlainExecTest
@@ -122,3 +124,5 @@ add_program_test_dir(program_execute_builtin,
'generated_tests/cl/builtin/relati
program_execute_store = Group()
program["Execute"]["Store"] = program_execute_store
add_program_test_dir(program_execute_store, 'generated_tests/cl/store')
+
+add_opencv_tests(profile)
diff --git a/tests/cl/program/execute/opencv-merge-hist.cl
b/tests/cl/program/execute/opencv-merge-hist.cl
deleted file mode 100644
index 8dccf24..000
--- a/tests/cl/program/execute/opencv-merge-hist.cl
+++ /dev/null
@@ -1,98 +0,0 @@
-/*!
-[config]
-name: OpenCV merge-hist
-kernel_name: merge_hist
-dimensions: 1
-global_size: 65536 1 1
-local_size: 256 1 1
-
-# This test checks that the loop:
-# for(int stride = HISTOGRAM256_WORK_GROUP_SIZE /2; stride > 0; stride >>= 1)
-# in this kernel is unrolled correctly or not unrolled at all. The Clang
-# OpenCL frontend was unrolling this in way that created illegal uses of the
-# barrier() builtin which resulted in GPU hangs on r600g.
-[test]
-arg_in: 0 buffer int[65536] repeat 0
-arg_out: 1 buffer int[256] repeat 0
-arg_in: 2 int 256
-
-!*/
-
-// The kernel in this test is taken from the opencv library (opencv.org)
-// File: modules/ocl/src/opencl/imgproc_histogram.cl
-//
-// License Agreement
-//For Open Source Computer Vision Library
-//
-// Copyright (C) 2010-2012, Institute Of Software Chinese Academy Of Science,
all rights reserved.
-// Copyright (C) 2010-2012, Advanced Micro Devices, Inc., all rights reserved.
-// Copyright (C) 2010-2012, Multicoreware, Inc., all rights reserved.
-// Third party copyrights are property of their respective owners.
-//
-// @Authors
-//Niko Li, newlife20080...@gmail.com
-//Jia Haipeng, jiahaipen...@gmail.com
-//Xu Pang, pangxu...@163.com
-//Wenju He, we...@multicorewareinc.com
-// Redistribution and use in source and binary forms, with or without
modification,
-// are permitted provided that the following conditions are met:
-//
-// * Redistribution's of source code must retain the above copyright notice,
-// this list of conditions and the following disclaimer.
-//
-// * Redistribution's in binary form must reproduce the above copyright
notice,
-// this list of conditions and the following disclaimer in the
documentation
-// and/or other GpuMaterials provided with the distribution.
-//
-// * The name of the copyright holders may not be used to endorse or promote
products
-// derived
Re: [Mesa-dev] [PATCH] i965: Modify some error messages to refer to "vec4" instead of "vs".
Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Modify some error messages to refer to "vec4" instead of "vs".
On 01/17/2014 02:14 PM, Paul Berry wrote:
> These messages are in code that is shared between the VS and GS
> back-ends, so use the terminology "vec4" to avoid confusion.
Reviewed-by: Ian Romanick
> ---
> src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 8
> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> index c1ef81d..51e88d2 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> @@ -327,7 +327,7 @@ vec4_generator::generate_tex(vec4_instruction *inst,
> }
> break;
>default:
> - assert(!"should not get here: invalid VS texture opcode");
> + assert(!"should not get here: invalid vec4 texture opcode");
>break;
>}
> } else {
> @@ -356,7 +356,7 @@ vec4_generator::generate_tex(vec4_instruction *inst,
>assert(inst->mlen == 2);
>break;
>default:
> - assert(!"should not get here: invalid VS texture opcode");
> + assert(!"should not get here: invalid vec4 texture opcode");
>break;
>}
> }
> @@ -1218,10 +1218,10 @@
> vec4_generator::generate_vec4_instruction(vec4_instruction *instruction,
>
> default:
>if (inst->opcode < (int) ARRAY_SIZE(opcode_descs)) {
> - _mesa_problem(&brw->ctx, "Unsupported opcode in `%s' in VS\n",
> + _mesa_problem(&brw->ctx, "Unsupported opcode in `%s' in vec4\n",
> opcode_descs[inst->opcode].name);
>} else {
> - _mesa_problem(&brw->ctx, "Unsupported opcode %d in VS",
> inst->opcode);
> + _mesa_problem(&brw->ctx, "Unsupported opcode %d in vec4",
> inst->opcode);
>}
>abort();
> }
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> index 3b8cef6..81906e8 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> @@ -3343,7 +3343,7 @@ vec4_visitor::fail(const char *format, ...)
> va_start(va, format);
> msg = ralloc_vasprintf(mem_ctx, format, va);
> va_end(va);
> - msg = ralloc_asprintf(mem_ctx, "VS compile failed: %s\n", msg);
> + msg = ralloc_asprintf(mem_ctx, "vec4 compile failed: %s\n", msg);
>
> this->fail_msg = msg;
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Add GS support to INTEL_DEBUG=shader_time.
Previously, time spent in geometry shaders would be counted as part of
the vertex shader time.
---
src/mesa/drivers/dri/i965/brw_context.h | 3 +++
src/mesa/drivers/dri/i965/brw_program.c | 10 +-
src/mesa/drivers/dri/i965/brw_vec4.cpp| 6 +++---
src/mesa/drivers/dri/i965/brw_vec4.h | 9 -
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 3 ++-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp| 10 --
src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp | 3 ++-
src/mesa/drivers/dri/i965/test_vec4_register_coalesce.cpp | 3 ++-
8 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 9c51646..972eb9f 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -783,6 +783,9 @@ enum shader_time_shader_type {
ST_VS,
ST_VS_WRITTEN,
ST_VS_RESET,
+ ST_GS,
+ ST_GS_WRITTEN,
+ ST_GS_RESET,
ST_FS8,
ST_FS8_WRITTEN,
ST_FS8_RESET,
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index abfc921..a6a2403 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -288,7 +288,7 @@ get_written_and_reset(struct brw_context *brw, int i,
uint64_t *written, uint64_t *reset)
{
enum shader_time_shader_type type = brw->shader_time.types[i];
- assert(type == ST_VS || type == ST_FS8 || type == ST_FS16);
+ assert(type == ST_VS || type == ST_GS || type == ST_FS8 || type == ST_FS16);
/* Find where we recorded written and reset. */
int wi, ri;
@@ -340,6 +340,8 @@ brw_report_shader_time(struct brw_context *brw)
switch (type) {
case ST_VS_WRITTEN:
case ST_VS_RESET:
+ case ST_GS_WRITTEN:
+ case ST_GS_RESET:
case ST_FS8_WRITTEN:
case ST_FS8_RESET:
case ST_FS16_WRITTEN:
@@ -349,6 +351,7 @@ brw_report_shader_time(struct brw_context *brw)
continue;
case ST_VS:
+ case ST_GS:
case ST_FS8:
case ST_FS16:
get_written_and_reset(brw, i, &written, &reset);
@@ -372,6 +375,7 @@ brw_report_shader_time(struct brw_context *brw)
switch (type) {
case ST_VS:
+ case ST_GS:
case ST_FS8:
case ST_FS16:
total_by_type[type] += scaled[i];
@@ -432,6 +436,9 @@ brw_report_shader_time(struct brw_context *brw)
case ST_VS:
stage = "vs";
break;
+ case ST_GS:
+ stage = "gs";
+ break;
case ST_FS8:
stage = "fs8";
break;
@@ -449,6 +456,7 @@ brw_report_shader_time(struct brw_context *brw)
printf("\n");
print_shader_time_line("total", "vs", -1, total_by_type[ST_VS], total);
+ print_shader_time_line("total", "gs", -1, total_by_type[ST_GS], total);
print_shader_time_line("total", "fs8", -1, total_by_type[ST_FS8], total);
print_shader_time_line("total", "fs16", -1, total_by_type[ST_FS16], total);
}
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 9d3735a..2e319e38 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1494,10 +1494,10 @@ vec4_visitor::emit_shader_time_end()
*/
emit(ADD(diff, src_reg(diff), src_reg(-2u)));
- emit_shader_time_write(ST_VS, src_reg(diff));
- emit_shader_time_write(ST_VS_WRITTEN, src_reg(1u));
+ emit_shader_time_write(st_base, src_reg(diff));
+ emit_shader_time_write(st_written, src_reg(1u));
emit(BRW_OPCODE_ELSE);
- emit_shader_time_write(ST_VS_RESET, src_reg(1u));
+ emit_shader_time_write(st_reset, src_reg(1u));
emit(BRW_OPCODE_ENDIF);
}
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index d4029d8..f2ecb2b 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -231,7 +231,10 @@ public:
struct brw_shader *shader,
void *mem_ctx,
bool debug_flag,
-bool no_spills);
+bool no_spills,
+shader_time_shader_type st_base,
+shader_time_shader_type st_written,
+shader_time_shader_type st_reset);
~vec4_visitor();
dst_reg dst_null_f()
@@ -547,6 +550,10 @@ private:
* If true, then register allocation should fail instead of spilling.
*/
const bool no_spills;
+
+ const shader_time_shader_type st_base;
+ const shader_time_shader_type st_written;
+ const shader_time_shader_type st_reset;
};
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index 5d5b169..8d8db5e 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visito
[Mesa-dev] [Bug 73100] Please use AC_PATH_TOOL instead of AC_PATH_PROG for llvm-config
https://bugs.freedesktop.org/show_bug.cgi?id=73100 Michał Górny changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Michał Górny --- My patch has been committed already :) [1] [1]:http://cgit.freedesktop.org/mesa/mesa/commit/?id=5ea23763349346f -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [V3 PATCH 2/8] mesa: Change 4 color component ubyte formats
On Fri, Jan 17, 2014 at 1:24 PM, Marek Olšák wrote:
> Incorrect. You have to manually check if the pack and unpack functions
> access the components using bitwise operations or arrays.
>
> Consider char pix[]. The array formats use arrays for accessing, for
> example:
>
> char *p = &pix[(y*width+x)*4];
> p[0] = r;
> p[1] = g;
> p[2] = b;
> p[3] = a;
>
> Packed formats use bitwise operators for accessing, for example:
>
> uint32_t *p = &pix[(y*width+x)*4];
> *p = r | (g << 8) | (b << 16) | (a << 24);
>
Hang on, that's precisely what I did and when I tallied up the results from
the manual inspection, the rule I provided below fit. For example, in
format_pack.c, any pack_ubyte function that does not use a PACK_COLOR_
macro is either 32 bits per component, or an odd number of components with
8 or 16 bits: MESA_FORMAT_R_UNORM8, MESA_FORMAT_RGB_UNORM8. I admit that I
messed one, which is 16 bit floats - those are arrays too.
>
>
> It's okay to have both RGBA8 array and packed formats. For example,
> Gallium has these array formats:
> PIPE_FORMAT_R8G8B8A8_UNORM
> PIPE_FORMAT_B8G8R8A8_UNORM
> PIPE_FORMAT_A8R8G8B8_UNORM
> PIPE_FORMAT_A8B8G8R8_UNORM
>
> And it defines these packed formats by using the array formats
> according to the CPU architecture:
>
> #if defined(PIPE_ARCH_LITTLE_ENDIAN)
> #define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
> #define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
> #define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
> #define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
> #elif defined(PIPE_ARCH_BIG_ENDIAN)
> #define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
> #define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
> #define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
> #define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
> #endif
>
> This way, Gallium has all the possible RGBA8 array formats and also
> the possible RGBA8 packed formats, so we can use whatever we want.
>
The MESA_FORMATs are used to literally tag the application's Internal
formats such that the driver can better know the application's intention
(admittedly I'm also looking beyond _mesa_choose_tex_format, but that is
for another time). The Array Type formats were proposed to indicate that
the component order is independent of endianess, whereas Packed Type
component orders _do_ depend on endianess. Acknowledging these Types is an
attempt to eradicate the confusion. I have no input about mixing types
within Gallium, but within Mesa my preference is to adhere to that
distinction. I find Francisco's method to be less confusing then Gallium's
(not just because of the helpful comment). Here it is with P Type formats:
/*
* Define endian-invariant aliases for some mesa formats that are
* defined in terms of their channel layout from LSB to MSB in a
* 32-bit word. The actual byte offsets matter here because the user
* is allowed to bit-cast one format into another and get predictable
* results.
*/
#ifdef MESA_BIG_ENDIAN
# define MESA_FORMAT_RGBA_8 MESA_FORMAT_A8B8G8R8_UNORM
# define MESA_FORMAT_RG_16 MESA_FORMAT_G16R16_UNORM
# define MESA_FORMAT_RG_8 MESA_FORMAT_G8R8_UNORM
# define MESA_FORMAT_SIGNED_RGBA_8 MESA_FORMAT_A8B8G8R8_SNORM
# define MESA_FORMAT_SIGNED_RG_16 MESA_FORMAT_G16R16_SNORM
# define MESA_FORMAT_SIGNED_RG_8 MESA_FORMAT_G8R8_SNORM
#else
# define MESA_FORMAT_RGBA_8 MESA_FORMAT_R8G8B8A8_UNORM
# define MESA_FORMAT_RG_16 MESA_FORMAT_R16G16_UNORM
# define MESA_FORMAT_RG_8 MESA_FORMAT_R8G8_UNORM
# define MESA_FORMAT_SIGNED_RGBA_8 MESA_FORMAT_R8G8B8A8_SNORM
# define MESA_FORMAT_SIGNED_RG_16 MESA_FORMAT_R16G16_SNORM
# define MESA_FORMAT_SIGNED_RG_8 MESA_FORMAT_R8G8_SNORM
#endif
Mark
>
> Marek
>
> On Fri, Jan 17, 2014 at 9:41 PM, Mark Mueller
> wrote:
> >
> >
> >
> > On Fri, Jan 17, 2014 at 8:58 AM, Brian Paul wrote:
> >>
> >> On 01/17/2014 03:45 AM, Mark Mueller wrote:
> >>>
> >>> Change all 4 color component unsigned byte formats to meet spec:
> >>> s/MESA_FORMAT_RGBA\b/MESA_FORMAT_ABGR_UNORM8/g
> >>> s/MESA_FORMAT_RGBA_REV\b/MESA_FORMAT_RGBA_UNORM8/g
> >>> s/MESA_FORMAT_ARGB\b/MESA_FORMAT_BGRA_UNORM8/g
> >>> s/MESA_FORMAT_ARGB_REV\b/MESA_FORMAT_ARGB_UNORM8/g
> >>> s/MESA_FORMAT_RGBX\b/MESA_FORMAT_XBGR_UNORM8/g
> >>> s/MESA_FORMAT_RGBX_REV\b/MESA_FORMAT_RGBX_UNORM8/g
> >>> s/MESA_FORMAT_XRGB\b/MESA_FORMAT_BGRX_UNORM8/g
> >>> s/MESA_FORMAT_XRGB_REV\b/MESA_FORMAT_XRGB_UNORM8/g
> >>>
> >>
> >>
> >> I'm not sure this is right. If you look at the existing code such as
> >> src/mesa/main/format_{un}pack.c you'll see that these formats are
> treated as
> >> packed formats, not arrays.
> >>
> >
> > Ah. Array formats are really rare with OGL, that was unexpected but now
> > really ancient issues with memory throughput optimization are surfacing.
> > Those were the days.
> >
> > Thus Array Types would only include the much smaller group of all 32
> > bit-per-component formats, and
Re: [Mesa-dev] [V3 PATCH 2/8] mesa: Change 4 color component ubyte formats
On Sat, Jan 18, 2014 at 12:45 AM, Mark Mueller wrote: > > > > On Fri, Jan 17, 2014 at 1:24 PM, Marek Olšák wrote: >> >> Incorrect. You have to manually check if the pack and unpack functions >> access the components using bitwise operations or arrays. >> >> Consider char pix[]. The array formats use arrays for accessing, for >> example: >> >> char *p = &pix[(y*width+x)*4]; >> p[0] = r; >> p[1] = g; >> p[2] = b; >> p[3] = a; >> >> Packed formats use bitwise operators for accessing, for example: >> >> uint32_t *p = &pix[(y*width+x)*4]; >> *p = r | (g << 8) | (b << 16) | (a << 24); > > > Hang on, that's precisely what I did and when I tallied up the results from I thought you hadn't. Nevermind then. > the manual inspection, the rule I provided below fit. For example, in > format_pack.c, any pack_ubyte function that does not use a PACK_COLOR_ macro > is either 32 bits per component, or an odd number of components with 8 or 16 > bits: MESA_FORMAT_R_UNORM8, MESA_FORMAT_RGB_UNORM8. I admit that I messed > one, which is 16 bit floats - those are arrays too. > > >> >> >> >> It's okay to have both RGBA8 array and packed formats. For example, >> Gallium has these array formats: >> PIPE_FORMAT_R8G8B8A8_UNORM >> PIPE_FORMAT_B8G8R8A8_UNORM >> PIPE_FORMAT_A8R8G8B8_UNORM >> PIPE_FORMAT_A8B8G8R8_UNORM >> >> And it defines these packed formats by using the array formats >> according to the CPU architecture: >> >> #if defined(PIPE_ARCH_LITTLE_ENDIAN) >> #define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_R8G8B8A8_UNORM >> #define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_B8G8R8A8_UNORM >> #define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_A8R8G8B8_UNORM >> #define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM >> #elif defined(PIPE_ARCH_BIG_ENDIAN) >> #define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_R8G8B8A8_UNORM >> #define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_B8G8R8A8_UNORM >> #define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_A8R8G8B8_UNORM >> #define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM >> #endif >> >> This way, Gallium has all the possible RGBA8 array formats and also >> the possible RGBA8 packed formats, so we can use whatever we want. > > > The MESA_FORMATs are used to literally tag the application's Internal > formats such that the driver can better know the application's intention > (admittedly I'm also looking beyond _mesa_choose_tex_format, but that is for > another time). The Array Type formats were proposed to indicate that the > component order is independent of endianess, whereas Packed Type component > orders _do_ depend on endianess. Acknowledging these Types is an attempt to > eradicate the confusion. I have no input about mixing types within Gallium, > but within Mesa my preference is to adhere to that distinction. I find > Francisco's method to be less confusing then Gallium's (not just because of > the helpful comment). Here it is with P Type formats: > > /* > * Define endian-invariant aliases for some mesa formats that are > * defined in terms of their channel layout from LSB to MSB in a > * 32-bit word. The actual byte offsets matter here because the user > * is allowed to bit-cast one format into another and get predictable > * results. > */ > #ifdef MESA_BIG_ENDIAN > # define MESA_FORMAT_RGBA_8 MESA_FORMAT_A8B8G8R8_UNORM > # define MESA_FORMAT_RG_16 MESA_FORMAT_G16R16_UNORM > # define MESA_FORMAT_RG_8 MESA_FORMAT_G8R8_UNORM > # define MESA_FORMAT_SIGNED_RGBA_8 MESA_FORMAT_A8B8G8R8_SNORM > # define MESA_FORMAT_SIGNED_RG_16 MESA_FORMAT_G16R16_SNORM > # define MESA_FORMAT_SIGNED_RG_8 MESA_FORMAT_G8R8_SNORM > #else > # define MESA_FORMAT_RGBA_8 MESA_FORMAT_R8G8B8A8_UNORM > # define MESA_FORMAT_RG_16 MESA_FORMAT_R16G16_UNORM > # define MESA_FORMAT_RG_8 MESA_FORMAT_R8G8_UNORM > # define MESA_FORMAT_SIGNED_RGBA_8 MESA_FORMAT_R8G8B8A8_SNORM > # define MESA_FORMAT_SIGNED_RG_16 MESA_FORMAT_R16G16_SNORM > # define MESA_FORMAT_SIGNED_RG_8 MESA_FORMAT_R8G8_SNORM > #endif I'm not sure what you're trying to say here. It looks the same as gallium, except that it's the other way around (array formats defined using packed formats). Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/37] GL_ARB_viewport_array v2
This is the overall v2 of the GL_ARB_viewport_array series. It is mostly the same as the previous series, but there are some differences worth noting. Patch "i965: Consider all scissor rectangles in noop_scissor" in the original series was replaced by "i965: Consider only the scissor rectangle for viewport 0" in this series. As I mentioned on the previous e-mail thread, the original patch was incorrect. In addition, per Ken's suggestion, "mesa: Update viewport state for viewport_array" in the previous series has been split into several patches (05 through 08) in the new series. There were a couple non-cosmetic changes in the process (e.g., changing the Viewport[XYHW] storage in meta to float). I believe this series is good to go, and I'd like to land it Monday or Tuesday. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/37] mesa: Add extension tracking bit for ARB_viewport_array
From: Courtney Goeltzenleuchter
v2 (idr): Split these changes out from the original patch. Only
advertise GL_ARB_viewport_array in a core profile because it requires
geometry shaders.
Signed-off-by: Courtney Goeltzenleuchter
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/extensions.c | 1 +
src/mesa/main/mtypes.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 2e0ccc3..c2c9c09 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -176,6 +176,7 @@ static const struct extension extension_table[] = {
{ "GL_ARB_vertex_shader", o(ARB_vertex_shader),
GL, 2002 },
{ "GL_ARB_vertex_type_10f_11f_11f_rev",
o(ARB_vertex_type_10f_11f_11f_rev), GL, 2013 },
{ "GL_ARB_vertex_type_2_10_10_10_rev",
o(ARB_vertex_type_2_10_10_10_rev), GL, 2009 },
+ { "GL_ARB_viewport_array", o(ARB_viewport_array),
GLC,2010 },
{ "GL_ARB_window_pos", o(dummy_true),
GLL,2001 },
/* EXT extensions */
{ "GL_EXT_abgr",o(dummy_true),
GL, 1995 },
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 33df682..93390ec 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3434,6 +3434,7 @@ struct gl_extensions
GLboolean ARB_vertex_shader;
GLboolean ARB_vertex_type_10f_11f_11f_rev;
GLboolean ARB_vertex_type_2_10_10_10_rev;
+ GLboolean ARB_viewport_array;
GLboolean EXT_blend_color;
GLboolean EXT_blend_equation_separate;
GLboolean EXT_blend_func_separate;
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/37] mesa: Allow glGet of values that are 2 doubles
From: Courtney Goeltzenleuchter
This will be used when the viewport near and far plane are stored as
doubles instead of as floats.
v4 (idr): Split out from a single megapatch. Suggested by Ken. Also
drop value_double_4. It's never used anywhere in the patch series.
Signed-off-by: Courtney Goeltzenleuchter
Signed-off-by: Ian Romanick
---
src/mesa/main/get.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index dd6ac31..2189b31 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -113,6 +113,7 @@ enum value_type {
TYPE_FLOATN_3,
TYPE_FLOATN_4,
TYPE_DOUBLEN,
+ TYPE_DOUBLEN_2,
TYPE_MATRIX,
TYPE_MATRIX_T,
TYPE_CONST
@@ -162,6 +163,7 @@ struct value_desc {
union value {
GLfloat value_float;
GLfloat value_float_4[4];
+ GLdouble value_double_2[2];
GLmatrix *value_matrix;
GLint value_int;
GLint value_int_4[4];
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/37] mesa: Update gl_scissor_attrib to support ARB_viewport_array
From: Courtney Goeltzenleuchter
Update Mesa and drivers to access updated gl_scissor_attrib.
Now have an enable bitfield and array of gl_scissor_rects.
Drivers have been updated to the new scissor enable state
attribute (gl_context.scissor.EnableFlags) but still treat it
as a single boolean which is okay as mesa will only use
bit 0 when communicating with a driver that does not support
ARB_viewport_array.
v2 (idr): Rebase fixes.
v3 (idr): Small code formatting fix suggsted by Ken.
Signed-off-by: Courtney Goeltzenleuchter
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/common/driverfuncs.c | 2 +-
src/mesa/drivers/common/meta.c | 6 +++---
src/mesa/drivers/dri/i915/i830_state.c | 24 ++--
src/mesa/drivers/dri/i915/i915_state.c | 24 ++--
src/mesa/drivers/dri/i915/intel_fbo.c | 2 +-
src/mesa/drivers/dri/i965/brw_clear.c | 12 ++--
src/mesa/drivers/dri/i965/brw_sf_state.c| 2 +-
src/mesa/drivers/dri/i965/gen6_sf_state.c | 2 +-
src/mesa/drivers/dri/i965/gen7_sf_state.c | 2 +-
src/mesa/drivers/dri/i965/intel_fbo.c | 2 +-
src/mesa/drivers/dri/radeon/radeon_common.c | 6 +++---
src/mesa/main/attrib.c | 22 --
src/mesa/main/enable.c | 29 -
src/mesa/main/framebuffer.c | 19 ++-
src/mesa/main/get.c | 12
src/mesa/main/get_hash_params.py| 2 +-
src/mesa/main/mtypes.h | 8 ++--
src/mesa/main/scissor.c | 26 +-
src/mesa/state_tracker/st_atom_rasterizer.c | 2 +-
src/mesa/state_tracker/st_atom_scissor.c| 14 +++---
src/mesa/state_tracker/st_cb_bitmap.c | 2 +-
src/mesa/state_tracker/st_cb_clear.c| 10 +-
src/mesa/state_tracker/st_cb_drawpixels.c | 2 +-
src/mesa/swrast/s_context.c | 2 +-
24 files changed, 140 insertions(+), 94 deletions(-)
diff --git a/src/mesa/drivers/common/driverfuncs.c
b/src/mesa/drivers/common/driverfuncs.c
index e8dcb24..6d56838 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -274,7 +274,7 @@ _mesa_init_driver_state(struct gl_context *ctx)
ctx->Driver.Enable(ctx, GL_LIGHTING, ctx->Light.Enabled);
ctx->Driver.Enable(ctx, GL_LINE_SMOOTH, ctx->Line.SmoothFlag);
ctx->Driver.Enable(ctx, GL_POLYGON_STIPPLE, ctx->Polygon.StippleFlag);
- ctx->Driver.Enable(ctx, GL_SCISSOR_TEST, ctx->Scissor.Enabled);
+ ctx->Driver.Enable(ctx, GL_SCISSOR_TEST, ctx->Scissor.EnableFlags);
ctx->Driver.Enable(ctx, GL_STENCIL_TEST, ctx->Stencil._Enabled);
ctx->Driver.Enable(ctx, GL_TEXTURE_1D, GL_FALSE);
ctx->Driver.Enable(ctx, GL_TEXTURE_2D, GL_FALSE);
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 1294514..173b45c 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -933,9 +933,9 @@ _mesa_meta_end(struct gl_context *ctx)
}
if (state & MESA_META_SCISSOR) {
- _mesa_set_enable(ctx, GL_SCISSOR_TEST, save->Scissor.Enabled);
- _mesa_Scissor(save->Scissor.X, save->Scissor.Y,
-save->Scissor.Width, save->Scissor.Height);
+ _mesa_set_enable(ctx, GL_SCISSOR_TEST, save->Scissor.EnableFlags);
+ _mesa_Scissor(save->Scissor.ScissorArray[0].X,
save->Scissor.ScissorArray[0].Y,
+save->Scissor.ScissorArray[0].Width,
save->Scissor.ScissorArray[0].Height);
}
if (state & MESA_META_SHADER) {
diff --git a/src/mesa/drivers/dri/i915/i830_state.c
b/src/mesa/drivers/dri/i915/i830_state.c
index 7fe20bf..bae9204 100644
--- a/src/mesa/drivers/dri/i915/i830_state.c
+++ b/src/mesa/drivers/dri/i915/i830_state.c
@@ -536,23 +536,27 @@ i830Scissor(struct gl_context * ctx)
return;
DBG("%s %d,%d %dx%d\n", __FUNCTION__,
- ctx->Scissor.X, ctx->Scissor.Y,
- ctx->Scissor.Width, ctx->Scissor.Height);
+ ctx->Scissor.ScissorArray[0].X, ctx->Scissor.ScissorArray[0].Y,
+ ctx->Scissor.ScissorArray[0].Width,
ctx->Scissor.ScissorArray[0].Height);
if (_mesa_is_winsys_fbo(ctx->DrawBuffer)) {
- x1 = ctx->Scissor.X;
- y1 = ctx->DrawBuffer->Height - (ctx->Scissor.Y + ctx->Scissor.Height);
- x2 = ctx->Scissor.X + ctx->Scissor.Width - 1;
- y2 = y1 + ctx->Scissor.Height - 1;
+ x1 = ctx->Scissor.ScissorArray[0].X;
+ y1 = ctx->DrawBuffer->Height - (ctx->Scissor.ScissorArray[0].Y
+ + ctx->Scissor.ScissorArray[0].Height);
+ x2 = ctx->Scissor.ScissorArray[0].X
+ + ctx->Scissor.ScissorArray[0].Width - 1;
+ y2 = y1 + ctx->Scissor.ScissorArray[0].Height - 1;
DBG("%s %d..%d,%d..%d (inverted)\n", __FUNCTION__, x1, x2, y1, y2);
}
else {
/* FBO - not inverted
*
[Mesa-dev] [PATCH 06/37] mesa: Convert gl_viewport_attrib::Near and ::Far to double
From: Courtney Goeltzenleuchter
v4: Split out from a single megapatch. Suggested by Ken.
Signed-off-by: Ian Romanick
---
src/mesa/main/get.c | 5 +
src/mesa/main/get_hash_params.py | 2 +-
src/mesa/main/mtypes.h | 2 +-
src/mesa/main/viewport.c | 4 ++--
src/mesa/math/m_matrix.c | 6 +++---
src/mesa/math/m_matrix.h | 2 +-
6 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 2189b31..ad6096b 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -697,6 +697,11 @@ find_custom_value(struct gl_context *ctx, const struct
value_desc *d, union valu
v->value_int_4[3] = ctx->Viewport.Height;
break;
+ case GL_DEPTH_RANGE:
+ v->value_double_2[0] = ctx->Viewport.Near;
+ v->value_double_2[1] = ctx->Viewport.Far;
+ break;
+
case GL_ACTIVE_STENCIL_FACE_EXT:
v->value_enum = ctx->Stencil.ActiveFace ? GL_BACK : GL_FRONT;
break;
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 6fcd4f6..8e2fdae 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -11,7 +11,7 @@ descriptor=[
[ "DEPTH_BITS", "BUFFER_INT(Visual.depthBits), extra_new_buffers" ],
[ "DEPTH_CLEAR_VALUE", "CONTEXT_FIELD(Depth.Clear, TYPE_DOUBLEN), NO_EXTRA"
],
[ "DEPTH_FUNC", "CONTEXT_ENUM(Depth.Func), NO_EXTRA" ],
- [ "DEPTH_RANGE", "CONTEXT_FIELD(Viewport.Near, TYPE_FLOATN_2), NO_EXTRA" ],
+ [ "DEPTH_RANGE", "LOC_CUSTOM, TYPE_DOUBLEN_2, 0, NO_EXTRA" ],
[ "DEPTH_TEST", "CONTEXT_BOOL(Depth.Test), NO_EXTRA" ],
[ "DEPTH_WRITEMASK", "CONTEXT_BOOL(Depth.Mask), NO_EXTRA" ],
[ "DITHER", "CONTEXT_BOOL(Color.DitherFlag), NO_EXTRA" ],
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 9dbfa6b..1d5dd48 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1434,7 +1434,7 @@ struct gl_viewport_attrib
{
GLint X, Y; /**< position */
GLsizei Width, Height; /**< size */
- GLfloat Near, Far; /**< Depth buffer range */
+ GLdouble Near, Far; /**< Depth buffer range */
GLmatrix _WindowMap;/**< Mapping transformation as a
matrix. */
};
diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
index 3bc89ab..8eede51 100644
--- a/src/mesa/main/viewport.c
+++ b/src/mesa/main/viewport.c
@@ -127,8 +127,8 @@ _mesa_DepthRange(GLclampd nearval, GLclampd farval)
ctx->Viewport.Far == farval)
return;
- ctx->Viewport.Near = (GLfloat) CLAMP(nearval, 0.0, 1.0);
- ctx->Viewport.Far = (GLfloat) CLAMP(farval, 0.0, 1.0);
+ ctx->Viewport.Near = CLAMP(nearval, 0.0, 1.0);
+ ctx->Viewport.Far = CLAMP(farval, 0.0, 1.0);
ctx->NewState |= _NEW_VIEWPORT;
#if 1
diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
index 274f969..38fa51e 100644
--- a/src/mesa/math/m_matrix.c
+++ b/src/mesa/math/m_matrix.c
@@ -,14 +,14 @@ _math_matrix_translate( GLmatrix *mat, GLfloat x,
GLfloat y, GLfloat z )
*/
void
_math_matrix_viewport(GLmatrix *m, GLint x, GLint y, GLint width, GLint height,
- GLfloat zNear, GLfloat zFar, GLfloat depthMax)
+ GLdouble zNear, GLdouble zFar, GLdouble depthMax)
{
m->m[MAT_SX] = (GLfloat) width / 2.0F;
m->m[MAT_TX] = m->m[MAT_SX] + x;
m->m[MAT_SY] = (GLfloat) height / 2.0F;
m->m[MAT_TY] = m->m[MAT_SY] + y;
- m->m[MAT_SZ] = depthMax * ((zFar - zNear) / 2.0F);
- m->m[MAT_TZ] = depthMax * ((zFar - zNear) / 2.0F + zNear);
+ m->m[MAT_SZ] = (GLfloat) (depthMax * ((zFar - zNear) / 2.0));
+ m->m[MAT_TZ] = (GLfloat) (depthMax * ((zFar - zNear) / 2.0 + zNear));
m->flags = MAT_FLAG_GENERAL_SCALE | MAT_FLAG_TRANSLATION;
m->type = MATRIX_3D_NO_ROT;
}
diff --git a/src/mesa/math/m_matrix.h b/src/mesa/math/m_matrix.h
index 2b097cb..fc65f84 100644
--- a/src/mesa/math/m_matrix.h
+++ b/src/mesa/math/m_matrix.h
@@ -123,7 +123,7 @@ _math_matrix_frustum( GLmatrix *mat,
extern void
_math_matrix_viewport(GLmatrix *m, GLint x, GLint y, GLint width, GLint height,
- GLfloat zNear, GLfloat zFar, GLfloat depthMax);
+ GLdouble zNear, GLdouble zFar, GLdouble depthMax);
extern void
_math_matrix_set_identity( GLmatrix *dest );
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/37] mesa: Restore all the scissor rectangles in _mesa_PopAttrib
From: Ian Romanick
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/attrib.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index f55433e..db659ad 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1269,15 +1269,19 @@ _mesa_PopAttrib(void)
break;
case GL_SCISSOR_BIT:
{
+ unsigned i;
const struct gl_scissor_attrib *scissor;
scissor = (const struct gl_scissor_attrib *) attr->data;
- _mesa_set_scissor(ctx, 0,
- scissor->ScissorArray[0].X,
- scissor->ScissorArray[0].Y,
- scissor->ScissorArray[0].Width,
- scissor->ScissorArray[0].Height);
- _mesa_set_enable(ctx, GL_SCISSOR_TEST, scissor->EnableFlags &
1);
+ for (i = 0; i < ctx->Const.MaxViewports; i++) {
+ _mesa_set_scissor(ctx, i,
+scissor->ScissorArray[i].X,
+scissor->ScissorArray[i].Y,
+scissor->ScissorArray[i].Width,
+scissor->ScissorArray[i].Height);
+ _mesa_set_enablei(ctx, GL_SCISSOR_TEST, i,
+(scissor->EnableFlags >> i) & 1);
+ }
}
break;
case GL_STENCIL_BUFFER_BIT:
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 22/37] mesa: Add custom get function for SCISSOR_TEST to _mesa_IsEnabledi
From: Courtney Goeltzenleuchter
Now that the scissor enable state is a bitfield need a custom function
to extract the correct value from gl_context. Modeled
Scissor.EnableFlags after Color.BlendEnabled.
Signed-off-by: Courtney Goeltzenleuchter
Reviewed-by: Kenneth Graunke
---
src/mesa/main/enable.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index a624690..640db84 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -1136,6 +1136,13 @@ _mesa_IsEnabledi( GLenum cap, GLuint index )
return GL_FALSE;
}
return (ctx->Color.BlendEnabled >> index) & 1;
+ case GL_SCISSOR_TEST:
+ if (index >= ctx->Const.MaxViewports) {
+ _mesa_error(ctx, GL_INVALID_VALUE, "glIsEnabledIndexed(index=%u)",
+ index);
+ return GL_FALSE;
+ }
+ return (ctx->Scissor.EnableFlags >> index) & 1;
default:
_mesa_error(ctx, GL_INVALID_ENUM, "glIsEnabledIndexed(cap=%s)",
_mesa_lookup_enum_by_nr(cap));
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/37] mesa: Refactor scissor rectangle setting even more
From: Ian Romanick
Create an internal function that just writes data into the scissor
rectangle. In future patches this will see more use because we only
want to call dd_function_table::Scissor once after setting all of the
scissor rectangles instead of once per scissor rectangle.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/scissor.c | 42 +++---
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/src/mesa/main/scissor.c b/src/mesa/main/scissor.c
index 7ec927e..cc4ce69 100644
--- a/src/mesa/main/scissor.c
+++ b/src/mesa/main/scissor.c
@@ -30,6 +30,31 @@
/**
+ * Set scissor rectangle data directly in ScissorArray
+ *
+ * This is an internal function that performs no error checking on the
+ * supplied data. It also does \b not call \c dd_function_table::Scissor.
+ *
+ * \sa _mesa_set_scissor
+ */
+static void
+set_scissor_no_notify(struct gl_context *ctx, unsigned idx,
+ GLint x, GLint y, GLsizei width, GLsizei height)
+{
+ if (x == ctx->Scissor.ScissorArray[idx].X &&
+ y == ctx->Scissor.ScissorArray[idx].Y &&
+ width == ctx->Scissor.ScissorArray[idx].Width &&
+ height == ctx->Scissor.ScissorArray[idx].Height)
+ return;
+
+ FLUSH_VERTICES(ctx, _NEW_SCISSOR);
+ ctx->Scissor.ScissorArray[idx].X = x;
+ ctx->Scissor.ScissorArray[idx].Y = y;
+ ctx->Scissor.ScissorArray[idx].Width = width;
+ ctx->Scissor.ScissorArray[idx].Height = height;
+}
+
+/**
* Called via glScissor
*/
void GLAPIENTRY
@@ -66,17 +91,7 @@ void
_mesa_set_scissor(struct gl_context *ctx,
GLint x, GLint y, GLsizei width, GLsizei height)
{
- if (x == ctx->Scissor.ScissorArray[0].X &&
- y == ctx->Scissor.ScissorArray[0].Y &&
- width == ctx->Scissor.ScissorArray[0].Width &&
- height == ctx->Scissor.ScissorArray[0].Height)
- return;
-
- FLUSH_VERTICES(ctx, _NEW_SCISSOR);
- ctx->Scissor.ScissorArray[0].X = x;
- ctx->Scissor.ScissorArray[0].Y = y;
- ctx->Scissor.ScissorArray[0].Width = width;
- ctx->Scissor.ScissorArray[0].Height = height;
+ set_scissor_no_notify(ctx, 0, x, y, width, height);
if (ctx->Driver.Scissor)
ctx->Driver.Scissor(ctx);
@@ -92,8 +107,5 @@ _mesa_init_scissor(struct gl_context *ctx)
{
/* Scissor group */
ctx->Scissor.EnableFlags = GL_FALSE;
- ctx->Scissor.ScissorArray[0].X = 0;
- ctx->Scissor.ScissorArray[0].Y = 0;
- ctx->Scissor.ScissorArray[0].Width = 0;
- ctx->Scissor.ScissorArray[0].Height = 0;
+ set_scissor_no_notify(ctx, 0, 0, 0, 0, 0);
}
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 19/37] meta: Restore all scissor state
From: Ian Romanick
Previously the restore code would enable all scissor rectangles if any
scissor rectangles were enabled on entry to meta. When there is only
one scissor rectangle, this is fine. As soon as a driver supports
multiple viewports, this will be a problem.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/common/meta.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 9a8f7a5..3855536 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -933,9 +933,17 @@ _mesa_meta_end(struct gl_context *ctx)
}
if (state & MESA_META_SCISSOR) {
- _mesa_set_enable(ctx, GL_SCISSOR_TEST, save->Scissor.EnableFlags);
- _mesa_Scissor(save->Scissor.ScissorArray[0].X,
save->Scissor.ScissorArray[0].Y,
-save->Scissor.ScissorArray[0].Width,
save->Scissor.ScissorArray[0].Height);
+ unsigned i;
+
+ for (i = 0; i < ctx->Const.MaxViewports; i++) {
+ _mesa_set_scissor(ctx, i,
+ save->Scissor.ScissorArray[i].X,
+ save->Scissor.ScissorArray[i].Y,
+ save->Scissor.ScissorArray[i].Width,
+ save->Scissor.ScissorArray[i].Height);
+ _mesa_set_enablei(ctx, GL_SCISSOR_TEST, i,
+ (save->Scissor.EnableFlags >> i) & 1);
+ }
}
if (state & MESA_META_SHADER) {
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/37] mesa: Converty gl_viewport_attrib::X, ::Y, ::Width, and ::Height to float
From: Courtney Goeltzenleuchter
v4: Split out from a single megapatch. Suggested by Ken. Also make
meta's save_state::ViewportX, ::ViewportY, ::ViewportW, and ::ViewportH
to match gl_viewport_attrib.
Signed-off-by: Courtney Goeltzenleuchter
Signed-off-by: Ian Romanick
---
src/mesa/drivers/common/meta.c | 6 +++---
src/mesa/drivers/dri/i965/brw_clip_state.c | 8
src/mesa/drivers/dri/i965/gen6_clip_state.c | 4 ++--
src/mesa/drivers/dri/i965/gen6_viewport_state.c | 4 ++--
src/mesa/drivers/dri/i965/gen7_viewport_state.c | 4 ++--
src/mesa/main/get.c | 8
src/mesa/main/get_hash_params.py| 2 +-
src/mesa/main/mtypes.h | 4 ++--
src/mesa/math/m_matrix.c| 7 ---
src/mesa/math/m_matrix.h| 2 +-
src/mesa/state_tracker/st_atom_viewport.c | 8
src/mesa/swrast/s_context.c | 4 ++--
12 files changed, 31 insertions(+), 30 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 173b45c..3608ee8 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -170,7 +170,7 @@ struct save_state
struct gl_buffer_object *ArrayBufferObj;
/** MESA_META_VIEWPORT */
- GLint ViewportX, ViewportY, ViewportW, ViewportH;
+ GLfloat ViewportX, ViewportY, ViewportW, ViewportH;
GLclampd DepthNear, DepthFar;
/** MESA_META_CLAMP_FRAGMENT_COLOR */
@@ -744,8 +744,8 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state)
/* set viewport to match window size */
if (ctx->Viewport.X != 0 ||
ctx->Viewport.Y != 0 ||
- ctx->Viewport.Width != ctx->DrawBuffer->Width ||
- ctx->Viewport.Height != ctx->DrawBuffer->Height) {
+ ctx->Viewport.Width != (float) ctx->DrawBuffer->Width ||
+ ctx->Viewport.Height != (float) ctx->DrawBuffer->Height) {
_mesa_set_viewport(ctx, 0, 0,
ctx->DrawBuffer->Width, ctx->DrawBuffer->Height);
}
diff --git a/src/mesa/drivers/dri/i965/brw_clip_state.c
b/src/mesa/drivers/dri/i965/brw_clip_state.c
index a0bdb43..021acc8 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_state.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_state.c
@@ -43,8 +43,8 @@ upload_clip_vp(struct brw_context *brw)
sizeof(*vp), 32, &brw->clip.vp_offset);
const float maximum_post_clamp_delta = 4096;
- float gbx = maximum_post_clamp_delta / (float) ctx->Viewport.Width;
- float gby = maximum_post_clamp_delta / (float) ctx->Viewport.Height;
+ float gbx = maximum_post_clamp_delta / ctx->Viewport.Width;
+ float gby = maximum_post_clamp_delta / ctx->Viewport.Height;
vp->xmin = -gbx;
vp->xmax = gbx;
@@ -127,8 +127,8 @@ brw_upload_clip_unit(struct brw_context *brw)
/* enable guardband clipping if we can */
if (ctx->Viewport.X == 0 &&
ctx->Viewport.Y == 0 &&
- ctx->Viewport.Width == fb->Width &&
- ctx->Viewport.Height == fb->Height)
+ ctx->Viewport.Width == (float) fb->Width &&
+ ctx->Viewport.Height == (float) fb->Height)
{
clip->clip5.guard_band_enable = 1;
clip->clip6.clipper_viewport_state_ptr =
diff --git a/src/mesa/drivers/dri/i965/gen6_clip_state.c
b/src/mesa/drivers/dri/i965/gen6_clip_state.c
index 6cec0ff..8dcca84 100644
--- a/src/mesa/drivers/dri/i965/gen6_clip_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_clip_state.c
@@ -98,8 +98,8 @@ upload_clip_state(struct brw_context *brw)
if (ctx->Viewport.X == 0 &&
ctx->Viewport.Y == 0 &&
- ctx->Viewport.Width == fb->Width &&
- ctx->Viewport.Height == fb->Height) {
+ ctx->Viewport.Width == (float) fb->Width &&
+ ctx->Viewport.Height == (float) fb->Height) {
dw2 |= GEN6_CLIP_GB_TEST;
}
diff --git a/src/mesa/drivers/dri/i965/gen6_viewport_state.c
b/src/mesa/drivers/dri/i965/gen6_viewport_state.c
index 0335920..4c5135b 100644
--- a/src/mesa/drivers/dri/i965/gen6_viewport_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_viewport_state.c
@@ -55,8 +55,8 @@ gen6_upload_clip_vp(struct brw_context *brw)
* drawable.
*/
const float maximum_post_clamp_delta = 8192;
- float gbx = maximum_post_clamp_delta / (float) ctx->Viewport.Width;
- float gby = maximum_post_clamp_delta / (float) ctx->Viewport.Height;
+ float gbx = maximum_post_clamp_delta / ctx->Viewport.Width;
+ float gby = maximum_post_clamp_delta / ctx->Viewport.Height;
vp->xmin = -gbx;
vp->xmax = gbx;
diff --git a/src/mesa/drivers/dri/i965/gen7_viewport_state.c
b/src/mesa/drivers/dri/i965/gen7_viewport_state.c
index 8c5fcac..66c1838 100644
--- a/src/mesa/drivers/dri/i965/gen7_viewport_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_viewport_state.c
@@ -54,8 +54,8 @@ gen7_upload_sf_clip_viewport(struct brw_context *brw)
* drawable.
*/
const float maximum_guardband_extent = 8192;
- f
[Mesa-dev] [PATCH 29/37] i965: Set the maximum VPIndex
From: Ian Romanick
At various stages the hardware clamps the gl_ViewportIndex to these
values. Setting them to zero effectively makes gl_ViewportIndex be
ignored. This is acutally useful in blorp (so that we don't have to
modify all of the viewport / scissor state).
v2: Use INTEL_MASK to create GEN6_CLIP_MAX_VP_INDEX_MASK. Suggested by
Ken.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_defines.h | 1 +
src/mesa/drivers/dri/i965/brw_gs_state.c| 2 ++
src/mesa/drivers/dri/i965/gen6_clip_state.c | 3 ++-
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index fe5a147..656179e 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1537,6 +1537,7 @@ enum brw_message_target {
# define GEN6_CLIP_MIN_POINT_WIDTH_SHIFT 17
# define GEN6_CLIP_MAX_POINT_WIDTH_SHIFT 6
# define GEN6_CLIP_FORCE_ZERO_RTAINDEX (1 << 5)
+# define GEN6_CLIP_MAX_VP_INDEX_MASK INTEL_MASK(3, 0)
#define _3DSTATE_SF0x7813 /* GEN6+ */
/* DW1 (for gen6) */
diff --git a/src/mesa/drivers/dri/i965/brw_gs_state.c
b/src/mesa/drivers/dri/i965/brw_gs_state.c
index 9532614..d0c92fa 100644
--- a/src/mesa/drivers/dri/i965/brw_gs_state.c
+++ b/src/mesa/drivers/dri/i965/brw_gs_state.c
@@ -83,6 +83,8 @@ brw_upload_gs_unit(struct brw_context *brw)
if (unlikely(INTEL_DEBUG & DEBUG_STATS))
gs->thread4.stats_enable = 1;
+ gs->gs6.max_vp_index = brw->ctx.Const.MaxViewports - 1;
+
brw->state.dirty.cache |= CACHE_NEW_FF_GS_UNIT;
}
diff --git a/src/mesa/drivers/dri/i965/gen6_clip_state.c
b/src/mesa/drivers/dri/i965/gen6_clip_state.c
index e4dc278..3499e37 100644
--- a/src/mesa/drivers/dri/i965/gen6_clip_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_clip_state.c
@@ -121,7 +121,8 @@ upload_clip_state(struct brw_context *brw)
dw2);
OUT_BATCH(U_FIXED(0.125, 3) << GEN6_CLIP_MIN_POINT_WIDTH_SHIFT |
U_FIXED(255.875, 3) << GEN6_CLIP_MAX_POINT_WIDTH_SHIFT |
- (fb->MaxNumLayers > 0 ? 0 : GEN6_CLIP_FORCE_ZERO_RTAINDEX));
+ (fb->MaxNumLayers > 0 ? 0 : GEN6_CLIP_FORCE_ZERO_RTAINDEX) |
+ ((ctx->Const.MaxViewports - 1) & GEN6_CLIP_MAX_VP_INDEX_MASK));
ADVANCE_BATCH();
}
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/37] mesa: Convert gl_context::Viewport to gl_context::ViewportArray
From: Courtney Goeltzenleuchter
Only element 0 of the array is used anywhere at this time, so there
should be no changes.
v4: Split out from a single megapatch. Suggested by Ken.
Signed-off-by: Courtney Goeltzenleuchter
Signed-off-by: Ian Romanick
---
src/mesa/drivers/common/meta.c | 28 ++---
src/mesa/drivers/dri/i915/i915_state.c | 24 ++--
src/mesa/drivers/dri/i965/brw_cc.c | 4 +-
src/mesa/drivers/dri/i965/brw_clip_state.c | 12 +++---
src/mesa/drivers/dri/i965/brw_sf_state.c| 2 +-
src/mesa/drivers/dri/i965/gen6_clip_state.c | 8 ++--
src/mesa/drivers/dri/i965/gen6_viewport_state.c | 6 +--
src/mesa/drivers/dri/i965/gen7_viewport_state.c | 6 +--
src/mesa/drivers/dri/nouveau/nouveau_util.h | 4 +-
src/mesa/drivers/dri/nouveau/nv10_state_fb.c| 2 +-
src/mesa/drivers/dri/r200/r200_state.c | 4 +-
src/mesa/drivers/dri/radeon/radeon_state.c | 4 +-
src/mesa/main/attrib.c | 5 ++-
src/mesa/main/context.c | 18 +
src/mesa/main/get.c | 12 +++---
src/mesa/main/mtypes.h | 2 +-
src/mesa/main/rastpos.c | 5 ++-
src/mesa/main/state.c | 8 ++--
src/mesa/main/viewport.c| 52 -
src/mesa/program/prog_statevars.c | 6 +--
src/mesa/state_tracker/st_atom_viewport.c | 12 +++---
src/mesa/swrast/s_context.c | 8 ++--
src/mesa/swrast/s_depth.c | 10 ++---
src/mesa/swrast_setup/ss_context.c | 4 +-
src/mesa/tnl/t_rasterpos.c | 16
25 files changed, 134 insertions(+), 128 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 3608ee8..48203c7 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -737,21 +737,21 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state)
if (state & MESA_META_VIEWPORT) {
/* save viewport state */
- save->ViewportX = ctx->Viewport.X;
- save->ViewportY = ctx->Viewport.Y;
- save->ViewportW = ctx->Viewport.Width;
- save->ViewportH = ctx->Viewport.Height;
+ save->ViewportX = ctx->ViewportArray[0].X;
+ save->ViewportY = ctx->ViewportArray[0].Y;
+ save->ViewportW = ctx->ViewportArray[0].Width;
+ save->ViewportH = ctx->ViewportArray[0].Height;
/* set viewport to match window size */
- if (ctx->Viewport.X != 0 ||
- ctx->Viewport.Y != 0 ||
- ctx->Viewport.Width != (float) ctx->DrawBuffer->Width ||
- ctx->Viewport.Height != (float) ctx->DrawBuffer->Height) {
+ if (ctx->ViewportArray[0].X != 0 ||
+ ctx->ViewportArray[0].Y != 0 ||
+ ctx->ViewportArray[0].Width != (float) ctx->DrawBuffer->Width ||
+ ctx->ViewportArray[0].Height != (float) ctx->DrawBuffer->Height) {
_mesa_set_viewport(ctx, 0, 0,
ctx->DrawBuffer->Width, ctx->DrawBuffer->Height);
}
/* save depth range state */
- save->DepthNear = ctx->Viewport.Near;
- save->DepthFar = ctx->Viewport.Far;
+ save->DepthNear = ctx->ViewportArray[0].Near;
+ save->DepthFar = ctx->ViewportArray[0].Far;
/* set depth range to default */
_mesa_DepthRange(0.0, 1.0);
}
@@ -1089,10 +1089,10 @@ _mesa_meta_end(struct gl_context *ctx)
}
if (state & MESA_META_VIEWPORT) {
- if (save->ViewportX != ctx->Viewport.X ||
- save->ViewportY != ctx->Viewport.Y ||
- save->ViewportW != ctx->Viewport.Width ||
- save->ViewportH != ctx->Viewport.Height) {
+ if (save->ViewportX != ctx->ViewportArray[0].X ||
+ save->ViewportY != ctx->ViewportArray[0].Y ||
+ save->ViewportW != ctx->ViewportArray[0].Width ||
+ save->ViewportH != ctx->ViewportArray[0].Height) {
_mesa_set_viewport(ctx, save->ViewportX, save->ViewportY,
save->ViewportW, save->ViewportH);
}
diff --git a/src/mesa/drivers/dri/i915/i915_state.c
b/src/mesa/drivers/dri/i915/i915_state.c
index 94be237..f31b271 100644
--- a/src/mesa/drivers/dri/i915/i915_state.c
+++ b/src/mesa/drivers/dri/i915/i915_state.c
@@ -404,21 +404,21 @@ intelCalcViewport(struct gl_context * ctx)
if (_mesa_is_winsys_fbo(ctx->DrawBuffer)) {
_math_matrix_viewport(&intel->ViewportMatrix,
- ctx->Viewport.X,
- ctx->DrawBuffer->Height - ctx->Viewport.Y,
- ctx->Viewport.Width,
- -ctx->Viewport.Height,
- ctx->Viewport.Near,
- ctx->Viewport.Far,
+ ctx->ViewportArray[0].X,
+ ctx->DrawBuffer->Height - ctx->ViewportArray[0].Y,
+
[Mesa-dev] [PATCH 04/37] mesa: Move parameter validation from _mesa_set_viewport to _mesa_Viewport
From: Ian Romanick
Internal callers should do the right thing.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/viewport.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
index 3aaab2d..3bc89ab 100644
--- a/src/mesa/main/viewport.c
+++ b/src/mesa/main/viewport.c
@@ -47,6 +47,16 @@ _mesa_Viewport(GLint x, GLint y, GLsizei width, GLsizei
height)
{
GET_CURRENT_CONTEXT(ctx);
FLUSH_VERTICES(ctx, 0);
+
+ if (MESA_VERBOSE & VERBOSE_API)
+ _mesa_debug(ctx, "glViewport %d %d %d %d\n", x, y, width, height);
+
+ if (width < 0 || height < 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glViewport(%d, %d, %d, %d)", x, y, width, height);
+ return;
+ }
+
_mesa_set_viewport(ctx, x, y, width, height);
}
@@ -64,15 +74,6 @@ void
_mesa_set_viewport(struct gl_context *ctx, GLint x, GLint y,
GLsizei width, GLsizei height)
{
- if (MESA_VERBOSE & VERBOSE_API)
- _mesa_debug(ctx, "glViewport %d %d %d %d\n", x, y, width, height);
-
- if (width < 0 || height < 0) {
- _mesa_error(ctx, GL_INVALID_VALUE,
- "glViewport(%d, %d, %d, %d)", x, y, width, height);
- return;
- }
-
/* clamp width and height to the implementation dependent range */
width = MIN2(width, (GLsizei) ctx->Const.MaxViewportWidth);
height = MIN2(height, (GLsizei) ctx->Const.MaxViewportHeight);
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/37] mesa: Add an index parameter to _mesa_set_viewport
From: Ian Romanick
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/common/meta.c | 14 +++---
src/mesa/main/context.c| 2 +-
src/mesa/main/viewport.c | 24 ++--
src/mesa/main/viewport.h | 2 +-
4 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 48203c7..9a8f7a5 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -746,7 +746,7 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state)
ctx->ViewportArray[0].Y != 0 ||
ctx->ViewportArray[0].Width != (float) ctx->DrawBuffer->Width ||
ctx->ViewportArray[0].Height != (float) ctx->DrawBuffer->Height) {
- _mesa_set_viewport(ctx, 0, 0,
+ _mesa_set_viewport(ctx, 0, 0, 0,
ctx->DrawBuffer->Width, ctx->DrawBuffer->Height);
}
/* save depth range state */
@@ -1093,7 +1093,7 @@ _mesa_meta_end(struct gl_context *ctx)
save->ViewportY != ctx->ViewportArray[0].Y ||
save->ViewportW != ctx->ViewportArray[0].Width ||
save->ViewportH != ctx->ViewportArray[0].Height) {
- _mesa_set_viewport(ctx, save->ViewportX, save->ViewportY,
+ _mesa_set_viewport(ctx, 0, save->ViewportX, save->ViewportY,
save->ViewportW, save->ViewportH);
}
_mesa_DepthRange(save->DepthNear, save->DepthFar);
@@ -1761,7 +1761,7 @@ blitframebuffer_texture(struct gl_context *ctx,
}
/* setup viewport */
- _mesa_set_viewport(ctx, dstX, dstY, dstW, dstH);
+ _mesa_set_viewport(ctx, 0, dstX, dstY, dstW, dstH);
_mesa_ColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
_mesa_DepthMask(GL_FALSE);
_mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
@@ -1916,7 +1916,7 @@ _mesa_meta_BlitFramebuffer(struct gl_context *ctx,
_mesa_BufferSubData(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
}
- _mesa_set_viewport(ctx, dstX, dstY, dstW, dstH);
+ _mesa_set_viewport(ctx, 0, dstX, dstY, dstW, dstH);
_mesa_ColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
_mesa_set_enable(ctx, GL_DEPTH_TEST, GL_FALSE);
_mesa_DepthMask(GL_FALSE);
@@ -1965,7 +1965,7 @@ _mesa_meta_BlitFramebuffer(struct gl_context *ctx,
_mesa_DepthFunc(GL_ALWAYS);
_mesa_DepthMask(GL_TRUE);
- _mesa_set_viewport(ctx, dstX, dstY, dstW, dstH);
+ _mesa_set_viewport(ctx, 0, dstX, dstY, dstW, dstH);
_mesa_BufferSubData(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
_mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
mask &= ~GL_DEPTH_BUFFER_BIT;
@@ -3782,7 +3782,7 @@ _mesa_meta_GenerateMipmap(struct gl_context *ctx, GLenum
target,
assert(dstHeight == ctx->DrawBuffer->Height);
/* setup viewport */
- _mesa_set_viewport(ctx, 0, 0, dstWidth, dstHeight);
+ _mesa_set_viewport(ctx, 0, 0, 0, dstWidth, dstHeight);
_mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
}
@@ -4072,7 +4072,7 @@ decompress_texture_image(struct gl_context *ctx,
_mesa_MatrixMode(GL_PROJECTION);
_mesa_LoadIdentity();
_mesa_Ortho(0.0, width, 0.0, height, -1.0, 1.0);
- _mesa_set_viewport(ctx, 0, 0, width, height);
+ _mesa_set_viewport(ctx, 0, 0, 0, width, height);
/* upload new vertex data */
_mesa_BufferSubData(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 5c67159..5af0c02 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1437,7 +1437,7 @@ _mesa_check_init_viewport(struct gl_context *ctx, GLuint
width, GLuint height)
* potential infinite recursion.
*/
ctx->ViewportInitialized = GL_TRUE;
- _mesa_set_viewport(ctx, 0, 0, width, height);
+ _mesa_set_viewport(ctx, 0, 0, 0, width, height);
_mesa_set_scissor(ctx, 0, 0, width, height);
}
}
diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
index 360f066..d4b0393 100644
--- a/src/mesa/main/viewport.c
+++ b/src/mesa/main/viewport.c
@@ -57,7 +57,7 @@ _mesa_Viewport(GLint x, GLint y, GLsizei width, GLsizei
height)
return;
}
- _mesa_set_viewport(ctx, x, y, width, height);
+ _mesa_set_viewport(ctx, 0, x, y, width, height);
}
@@ -66,22 +66,23 @@ _mesa_Viewport(GLint x, GLint y, GLsizei width, GLsizei
height)
* matrix). Usually called from _mesa_Viewport().
*
* \param ctx GL context.
+ * \param idxIndex of the viewport to be updated.
* \param x, y coordinates of the lower left corner of the viewport rectangle.
* \param width width of the viewport rectangle.
* \param height height of the viewport rectangle.
*/
void
-_mesa_set_viewport(struct gl_context *ctx, GLint x, GLint y,
+_mesa_set_viewport(struct gl_context *ctx, unsigned idx, GLint x, GLint y,
GLsizei width, GLsizei height)
[Mesa-dev] [PATCH 33/37] i965: Set all the supported scissor rectangles for GEN7
From: Ian Romanick
Currently MaxViewports is still 1, so this won't affect any change.
v2: Minor code reformatting suggested by Ken.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen6_scissor_state.c | 60 ++
1 file changed, 33 insertions(+), 27 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_scissor_state.c
b/src/mesa/drivers/dri/i965/gen6_scissor_state.c
index 7b92b7c..6b01cd1 100644
--- a/src/mesa/drivers/dri/i965/gen6_scissor_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_scissor_state.c
@@ -30,6 +30,7 @@
#include "brw_defines.h"
#include "intel_batchbuffer.h"
#include "main/fbobject.h"
+#include "main/framebuffer.h"
static void
gen6_upload_scissor_state(struct brw_context *brw)
@@ -40,7 +41,8 @@ gen6_upload_scissor_state(struct brw_context *brw)
uint32_t scissor_state_offset;
scissor = brw_state_batch(brw, AUB_TRACE_SCISSOR_STATE,
-sizeof(*scissor), 32, &scissor_state_offset);
+sizeof(*scissor) * ctx->Const.MaxViewports, 32,
+ &scissor_state_offset);
/* _NEW_SCISSOR | _NEW_BUFFERS | _NEW_VIEWPORT */
@@ -51,33 +53,37 @@ gen6_upload_scissor_state(struct brw_context *brw)
* Note that the hardware's coordinates are inclusive, while Mesa's min is
* inclusive but max is exclusive.
*/
- if (ctx->DrawBuffer->_Xmin == ctx->DrawBuffer->_Xmax ||
- ctx->DrawBuffer->_Ymin == ctx->DrawBuffer->_Ymax) {
- /* If the scissor was out of bounds and got clamped to 0
- * width/height at the bounds, the subtraction of 1 from
- * maximums could produce a negative number and thus not clip
- * anything. Instead, just provide a min > max scissor inside
- * the bounds, which produces the expected no rendering.
- */
- scissor->xmin = 1;
- scissor->xmax = 0;
- scissor->ymin = 1;
- scissor->ymax = 0;
- } else if (render_to_fbo) {
- /* texmemory: Y=0=bottom */
- scissor->xmin = ctx->DrawBuffer->_Xmin;
- scissor->xmax = ctx->DrawBuffer->_Xmax - 1;
- scissor->ymin = ctx->DrawBuffer->_Ymin;
- scissor->ymax = ctx->DrawBuffer->_Ymax - 1;
- }
- else {
- /* memory: Y=0=top */
- scissor->xmin = ctx->DrawBuffer->_Xmin;
- scissor->xmax = ctx->DrawBuffer->_Xmax - 1;
- scissor->ymin = ctx->DrawBuffer->Height - ctx->DrawBuffer->_Ymax;
- scissor->ymax = ctx->DrawBuffer->Height - ctx->DrawBuffer->_Ymin - 1;
- }
+ for (unsigned i = 0; i < ctx->Const.MaxViewports; i++) {
+ int bbox[4];
+ _mesa_scissor_bounding_box(ctx, ctx->DrawBuffer, i, bbox);
+
+ if (bbox[0] == bbox[1] || bbox[2] == bbox[3]) {
+ /* If the scissor was out of bounds and got clamped to 0 width/height
+ * at the bounds, the subtraction of 1 from maximums could produce a
+ * negative number and thus not clip anything. Instead, just provide
+ * a min > max scissor inside the bounds, which produces the expected
+ * no rendering.
+ */
+ scissor[i].xmin = 1;
+ scissor[i].xmax = 0;
+ scissor[i].ymin = 1;
+ scissor[i].ymax = 0;
+ } else if (render_to_fbo) {
+ /* texmemory: Y=0=bottom */
+ scissor[i].xmin = bbox[0];
+ scissor[i].xmax = bbox[1] - 1;
+ scissor[i].ymin = bbox[2];
+ scissor[i].ymax = bbox[3] - 1;
+ }
+ else {
+ /* memory: Y=0=top */
+ scissor[i].xmin = bbox[0];
+ scissor[i].xmax = bbox[1] - 1;
+ scissor[i].ymin = ctx->DrawBuffer->Height - bbox[3];
+ scissor[i].ymax = ctx->DrawBuffer->Height - bbox[2] - 1;
+ }
+ }
BEGIN_BATCH(2);
OUT_BATCH(_3DSTATE_SCISSOR_STATE_POINTERS << 16 | (2 - 2));
OUT_BATCH(scissor_state_offset);
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 23/37] mesa: Add new scissor entry points for GL_ARB_viewport_array
From: Courtney Goeltzenleuchter
v2 (idr): Use set_scissor_no_notify (and manually notify the driver)
instead of calling _mesa_set_scissori. Refactory bodies of
_mesa_ScissorIndexed and _mesa_ScissorIndexedv into a shared function.
Perform parameter validation in the same order in all three functions.
Pull MaxViewports comparison fix (in _mesa_ScissorArrayv) from the next
patch to this patch.
Signed-off-by: Courtney Goeltzenleuchter
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/scissor.c | 93 +
src/mesa/main/scissor.h | 8 +
2 files changed, 101 insertions(+)
diff --git a/src/mesa/main/scissor.c b/src/mesa/main/scissor.c
index 9caac2e..14c8e8a 100644
--- a/src/mesa/main/scissor.c
+++ b/src/mesa/main/scissor.c
@@ -114,6 +114,99 @@ _mesa_set_scissor(struct gl_context *ctx, unsigned idx,
ctx->Driver.Scissor(ctx);
}
+/**
+ * Define count scissor boxes starting at index.
+ *
+ * \param index index of first scissor records to set
+ * \param count number of scissor records to set
+ * \param x, y pointer to array of struct gl_scissor_rects
+ *
+ * \sa glScissorArrayv().
+ *
+ * Verifies the parameters and call set_scissor_no_notify to do the work.
+ */
+void GLAPIENTRY
+_mesa_ScissorArrayv(GLuint first, GLsizei count, const GLint *v)
+{
+ int i;
+ struct gl_scissor_rect *p = (struct gl_scissor_rect *) v;
+ GET_CURRENT_CONTEXT(ctx);
+
+ if ((first + count) > ctx->Const.MaxViewports) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glScissorArrayv: first (%d) + count (%d) >= MaxViewports
(%d)",
+ first, count, ctx->Const.MaxViewports);
+ return;
+ }
+
+ /* Verify width & height */
+ for (i = 0; i < count; i++) {
+ if (p[i].Width < 0 || p[i].Height < 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glScissorArrayv: index (%d) width or height < 0 (%d,
%d)",
+ i, p[i].Width, p[i].Height);
+ }
+ }
+
+ for (i = 0; i < count; i++)
+ set_scissor_no_notify(ctx, i + first,
+p[i].X, p[i].Y, p[i].Width, p[i].Height);
+
+ if (ctx->Driver.Scissor)
+ ctx->Driver.Scissor(ctx);
+}
+
+/**
+ * Define the scissor box.
+ *
+ * \param index index of scissor records to set
+ * \param x, y coordinates of the scissor box lower-left corner.
+ * \param width width of the scissor box.
+ * \param height height of the scissor box.
+ *
+ * Verifies the parameters call set_scissor_no_notify to do the work.
+ */
+static void
+ScissorIndexed(GLuint index, GLint left, GLint bottom,
+ GLsizei width, GLsizei height, const char *function)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ if (MESA_VERBOSE & VERBOSE_API)
+ _mesa_debug(ctx, "%s(%d, %d, %d, %d, %d)\n",
+ function, index, left, bottom, width, height);
+
+ if (index >= ctx->Const.MaxViewports) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "%s: index (%d) >= MaxViewports (%d)",
+ function, index, ctx->Const.MaxViewports);
+ return;
+ }
+
+ if (width < 0 || height < 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "%s: index (%d) width or height < 0 (%d, %d)",
+ function, index, width, height);
+ }
+
+ set_scissor_no_notify(ctx, index, left, bottom, width, height);
+
+ if (ctx->Driver.Scissor)
+ ctx->Driver.Scissor(ctx);
+}
+
+void GLAPIENTRY
+_mesa_ScissorIndexed(GLuint index, GLint left, GLint bottom,
+ GLsizei width, GLsizei height)
+{
+ ScissorIndexed(index, left, bottom, width, height, "glScissorIndexd");
+}
+
+void GLAPIENTRY
+_mesa_ScissorIndexedv(GLuint index, const GLint *v)
+{
+ ScissorIndexed(index, v[0], v[1], v[2], v[3], "glScissorIndexdv");
+}
/**
* Initialize the context's scissor state.
diff --git a/src/mesa/main/scissor.h b/src/mesa/main/scissor.h
index 5726a00..5f9a994 100644
--- a/src/mesa/main/scissor.h
+++ b/src/mesa/main/scissor.h
@@ -34,6 +34,14 @@ struct gl_context;
extern void GLAPIENTRY
_mesa_Scissor( GLint x, GLint y, GLsizei width, GLsizei height );
+extern void GLAPIENTRY
+_mesa_ScissorArrayv(GLuint first, GLsizei count, const GLint * v);
+
+extern void GLAPIENTRY
+_mesa_ScissorIndexed(GLuint index, GLint left, GLint bottom, GLsizei width,
GLsizei height);
+
+extern void GLAPIENTRY
+_mesa_ScissorIndexedv(GLuint index, const GLint * v);
extern void
_mesa_set_scissor(struct gl_context *ctx, unsigned idx,
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 21/37] mesa: Add new get entrypoints for ARB_viewport_array
From: Courtney Goeltzenleuchter
v2 (idr): Fix several "comparison between signed and unsigned integer
expressions" warnings.
Signed-off-by: Courtney Goeltzenleuchter
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/get.c | 189
src/mesa/main/get.h | 6 ++
2 files changed, 195 insertions(+)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index c8accb6..9edf056 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -1730,6 +1730,31 @@ find_value_indexed(const char *func, GLenum pname,
GLuint index, union value *v)
v->value_int_4[3] = ctx->Color.ColorMask[index][ACOMP] ? 1 : 0;
return TYPE_INT_4;
+ case GL_SCISSOR_BOX:
+ if (index >= ctx->Const.MaxViewports)
+ goto invalid_value;
+ v->value_int_4[0] = ctx->Scissor.ScissorArray[index].X;
+ v->value_int_4[1] = ctx->Scissor.ScissorArray[index].Y;
+ v->value_int_4[2] = ctx->Scissor.ScissorArray[index].Width;
+ v->value_int_4[3] = ctx->Scissor.ScissorArray[index].Height;
+ return TYPE_INT_4;
+
+ case GL_VIEWPORT:
+ if (index >= ctx->Const.MaxViewports)
+ goto invalid_value;
+ v->value_float_4[0] = ctx->ViewportArray[index].X;
+ v->value_float_4[1] = ctx->ViewportArray[index].Y;
+ v->value_float_4[2] = ctx->ViewportArray[index].Width;
+ v->value_float_4[3] = ctx->ViewportArray[index].Height;
+ return TYPE_FLOAT_4;
+
+ case GL_DEPTH_RANGE:
+ if (index >= ctx->Const.MaxViewports)
+ goto invalid_value;
+ v->value_double_2[0] = ctx->ViewportArray[index].Near;
+ v->value_double_2[1] = ctx->ViewportArray[index].Far;
+ return TYPE_DOUBLEN_2;
+
case GL_TRANSFORM_FEEDBACK_BUFFER_START:
if (index >= ctx->Const.MaxTransformFeedbackBuffers)
goto invalid_value;
@@ -1938,6 +1963,26 @@ _mesa_GetIntegeri_v( GLenum pname, GLuint index, GLint
*params )
find_value_indexed("glGetIntegeri_v", pname, index, &v);
switch (type) {
+ case TYPE_FLOAT_4:
+ case TYPE_FLOATN_4:
+ params[3] = IROUND(v.value_float_4[3]);
+ case TYPE_FLOAT_3:
+ case TYPE_FLOATN_3:
+ params[2] = IROUND(v.value_float_4[2]);
+ case TYPE_FLOAT_2:
+ case TYPE_FLOATN_2:
+ params[1] = IROUND(v.value_float_4[1]);
+ case TYPE_FLOAT:
+ case TYPE_FLOATN:
+ params[0] = IROUND(v.value_float_4[0]);
+ break;
+
+ case TYPE_DOUBLEN_2:
+ params[1] = IROUND(v.value_double_2[1]);
+ case TYPE_DOUBLEN:
+ params[0] = IROUND(v.value_double_2[0]);
+ break;
+
case TYPE_INT:
params[0] = v.value_int;
break;
@@ -1981,6 +2026,150 @@ _mesa_GetInteger64i_v( GLenum pname, GLuint index,
GLint64 *params )
}
void GLAPIENTRY
+_mesa_GetFloati_v(GLenum pname, GLuint index, GLfloat *params)
+{
+ int i;
+ GLmatrix *m;
+ union value v;
+ enum value_type type =
+ find_value_indexed("glGetFloati_v", pname, index, &v);
+
+ switch (type) {
+ case TYPE_FLOAT_4:
+ case TYPE_FLOATN_4:
+ params[3] = v.value_float_4[3];
+ case TYPE_FLOAT_3:
+ case TYPE_FLOATN_3:
+ params[2] = v.value_float_4[2];
+ case TYPE_FLOAT_2:
+ case TYPE_FLOATN_2:
+ params[1] = v.value_float_4[1];
+ case TYPE_FLOAT:
+ case TYPE_FLOATN:
+ params[0] = v.value_float_4[0];
+ break;
+
+ case TYPE_DOUBLEN_2:
+ params[1] = (GLfloat) v.value_double_2[1];
+ case TYPE_DOUBLEN:
+ params[0] = (GLfloat) v.value_double_2[0];
+ break;
+
+ case TYPE_INT_4:
+ params[3] = (GLfloat) v.value_int_4[3];
+ case TYPE_INT_3:
+ params[2] = (GLfloat) v.value_int_4[2];
+ case TYPE_INT_2:
+ case TYPE_ENUM_2:
+ params[1] = (GLfloat) v.value_int_4[1];
+ case TYPE_INT:
+ case TYPE_ENUM:
+ params[0] = (GLfloat) v.value_int_4[0];
+ break;
+
+ case TYPE_INT_N:
+ for (i = 0; i < v.value_int_n.n; i++)
+params[i] = INT_TO_FLOAT(v.value_int_n.ints[i]);
+ break;
+
+ case TYPE_INT64:
+ params[0] = (GLfloat) v.value_int64;
+ break;
+
+ case TYPE_BOOLEAN:
+ params[0] = BOOLEAN_TO_FLOAT(v.value_bool);
+ break;
+
+ case TYPE_MATRIX:
+ m = *(GLmatrix **) &v;
+ for (i = 0; i < 16; i++)
+params[i] = m->m[i];
+ break;
+
+ case TYPE_MATRIX_T:
+ m = *(GLmatrix **) &v;
+ for (i = 0; i < 16; i++)
+params[i] = m->m[transpose[i]];
+ break;
+
+ default:
+ ;
+ }
+}
+
+void GLAPIENTRY
+_mesa_GetDoublei_v(GLenum pname, GLuint index, GLdouble *params)
+{
+ int i;
+ GLmatrix *m;
+ union value v;
+ enum value_type type =
+ find_value_indexed("glGetDoublei_v", pname, index, &v);
+
+ switch (type) {
+ case TYPE_FLOAT_4:
+ case TYPE_FLOATN_4:
+ params[3] = (GLdouble) v.value_float_4[3];
+ case TYPE_FLOAT_3:
+ case TYPE_FLOATN_3:
+ params[2] = (GLdouble) v.value_float_4[2];
+ case TYPE_FLOAT_2:
+ case TYPE_FLOATN_2:
+ params[1] = (GLdouble) v.value_float_4[1];
+
[Mesa-dev] [PATCH 17/37] mesa: Set all viewports from _mesa_Viewport and _mesa_DepthRange
From: Ian Romanick
In _mesa_Viewport and _mesa_DepthRange, make sure that
ctx->Driver.Viewport is only called once instead of once per viewport or
depth range.
v2: Make _mesa_DepthRange actually set all of the depth ranges (instead
of just index 0). Noticed by Ken.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/viewport.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
index cc031b0..ad16e87 100644
--- a/src/mesa/main/viewport.c
+++ b/src/mesa/main/viewport.c
@@ -74,6 +74,7 @@ set_viewport_no_notify(struct gl_context *ctx, unsigned idx,
GLint x, GLint y,
void GLAPIENTRY
_mesa_Viewport(GLint x, GLint y, GLsizei width, GLsizei height)
{
+ unsigned i;
GET_CURRENT_CONTEXT(ctx);
FLUSH_VERTICES(ctx, 0);
@@ -86,7 +87,19 @@ _mesa_Viewport(GLint x, GLint y, GLsizei width, GLsizei
height)
return;
}
- set_viewport_no_notify(ctx, 0, x, y, width, height);
+ /* The GL_ARB_viewport_array spec says:
+*
+* "Viewport sets the parameters for all viewports to the same values
+* and is equivalent (assuming no errors are generated) to:
+*
+* for (uint i = 0; i < MAX_VIEWPORTS; i++)
+* ViewportIndexedf(i, 1, (float)x, (float)y, (float)w, (float)h);"
+*
+* Set all of the viewports supported by the implementation, but only
+* signal the driver once at the end.
+*/
+ for (i = 0; i < ctx->Const.MaxViewports; i++)
+ set_viewport_no_notify(ctx, i, x, y, width, height);
if (ctx->Driver.Viewport) {
/* Many drivers will use this call to check for window size changes
@@ -170,6 +183,7 @@ _mesa_set_depth_range(struct gl_context *ctx, unsigned idx,
void GLAPIENTRY
_mesa_DepthRange(GLclampd nearval, GLclampd farval)
{
+ unsigned i;
GET_CURRENT_CONTEXT(ctx);
FLUSH_VERTICES(ctx, 0);
@@ -177,7 +191,19 @@ _mesa_DepthRange(GLclampd nearval, GLclampd farval)
if (MESA_VERBOSE&VERBOSE_API)
_mesa_debug(ctx, "glDepthRange %f %f\n", nearval, farval);
- set_depth_range_no_notify(ctx, 0, nearval, farval);
+ /* The GL_ARB_viewport_array spec says:
+*
+* "DepthRange sets the depth range for all viewports to the same
+* values and is equivalent (assuming no errors are generated) to:
+*
+* for (uint i = 0; i < MAX_VIEWPORTS; i++)
+* DepthRangeIndexed(i, n, f);"
+*
+* Set the depth range for all of the viewports supported by the
+* implementation, but only signal the driver once at the end.
+*/
+ for (i = 0; i < ctx->Const.MaxViewports; i++)
+ set_depth_range_no_notify(ctx, i, nearval, farval);
if (ctx->Driver.DepthRange) {
ctx->Driver.DepthRange(ctx);
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 28/37] mesa: Add ARB_viewport_array plumbing
From: Courtney Goeltzenleuchter
Define API connections to extension entry points added in previous
commits. Update entry points to use floating point arguments as
required by the extension.
Add get tokens for ARB_viewport_array state.
v2: Include review feedback.
v3 (idr): Fix 'make check'. Add missing Get infrastructure (some was
culled from other pathces).
Signed-off-by: Courtney Goeltzenleuchter
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mapi/glapi/gen/ARB_viewport_array.xml | 79 +++
src/mapi/glapi/gen/Makefile.am| 1 +
src/mapi/glapi/gen/gl_API.xml | 2 +-
src/mesa/main/get.c | 1 +
src/mesa/main/get_hash_params.py | 7 +++
src/mesa/main/tests/dispatch_sanity.cpp | 20
6 files changed, 99 insertions(+), 11 deletions(-)
create mode 100644 src/mapi/glapi/gen/ARB_viewport_array.xml
diff --git a/src/mapi/glapi/gen/ARB_viewport_array.xml
b/src/mapi/glapi/gen/ARB_viewport_array.xml
new file mode 100644
index 000..e1c6c2d
--- /dev/null
+++ b/src/mapi/glapi/gen/ARB_viewport_array.xml
@@ -0,0 +1,79 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
index d5c20b7..7354725 100644
--- a/src/mapi/glapi/gen/Makefile.am
+++ b/src/mapi/glapi/gen/Makefile.am
@@ -129,6 +129,7 @@ API_XML = \
ARB_texture_view.xml \
ARB_vertex_array_object.xml \
ARB_vertex_attrib_binding.xml \
+ ARB_viewport_array.xml \
AMD_draw_buffers_blend.xml \
AMD_performance_monitor.xml \
ARB_vertex_type_2_10_10_10_rev.xml \
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index ff65b48..193ee37 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -9926,7 +9926,7 @@
-
+http://www.w3.org/2001/XInclude"/>
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 9edf056..2b1538d 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -391,6 +391,7 @@ EXTRA_EXT(ARB_texture_gather);
EXTRA_EXT(ARB_shader_atomic_counters);
EXTRA_EXT(ARB_draw_indirect);
EXTRA_EXT(ARB_shader_image_load_store);
+EXTRA_EXT(ARB_viewport_array);
static const int
extra_ARB_color_buffer_float_or_glcore[] = {
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 3aa0548..b45e143 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -759,6 +759,13 @@ descriptor=[
[ "TEXTURE_BUFFER_OFFSET_ALIGNMENT",
"CONTEXT_INT(Const.TextureBufferOffsetAlignment),
extra_ARB_texture_buffer_range" ],
# GL_ARB_draw_indirect
[ "DRAW_INDIRECT_BUFFER_BINDING", "LOC_CUSTOM, TYPE_INT, 0,
extra_ARB_draw_indirect" ],
+
+# GL_ARB_viewport_array
+ [ "MAX_VIEWPORTS", "CONTEXT_INT(Const.MaxViewports),
extra_ARB_viewport_array" ],
+ [ "VIEWPORT_SUBPIXEL_BITS", "CONTEXT_INT(Const.ViewportSubpixelBits),
extra_ARB_viewport_array" ],
+ [ "VIEWPORT_BOUNDS_RANGE", "CONTEXT_FLOAT2(Const.ViewportBounds),
extra_ARB_viewport_array" ],
+ [ "LAYER_PROVOKING_VERTEX", "CONTEXT_ENUM(Light.ProvokingVertex),
extra_ARB_viewport_array" ],
+ [ "VIEWPORT_INDEX_PROVOKING_VERTEX", "CONTEXT_ENUM(Light.ProvokingVertex),
extra_ARB_viewport_array" ],
]}
]
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index b971956..78a218e 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -786,16 +786,16 @@ const struct function gl_core_functions_possible[] = {
// { "glVertexAttribL4dv", 43, -1 },// XXX: Add to xml
// { "glVertexAttribLPointer", 43, -1 },// XXX: Add to xml
// { "glGetVertexAttribLdv", 43, -1 }, // XXX: Add to xml
-// { "glViewportArrayv", 43, -1 }, // XXX: Add to xml
-// { "glViewportIndexedf", 43, -1 },// XXX: Add to xml
-// { "glViewportIndexedfv", 43, -1 }, // XXX: Add to xml
-// { "glScissorArrayv", 43, -1 }, // XXX: Add to xml
-// { "glScissorIndexed", 43, -1 }, // XXX: Add to xml
-// { "glScissorIndexedv", 43, -1 }, // XXX: Add to xml
-// { "glDepthRangeArrayv", 43, -1 },// XXX: Add to xml
-// { "glDepthRangeIndexed", 43, -1 }, // XXX: Add to xml
-// { "glGetFloati_v", 43, -1 },
[Mesa-dev] [PATCH 11/37] mesa: Refactor viewport setting even more
From: Ian Romanick
Create an internal function that just writes data into the viewport. In
future patches this will see more use because we only want to call
dd_function_table::Viewport once after setting all of the viewport
instead of once per viewport.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/viewport.c | 63 +---
1 file changed, 38 insertions(+), 25 deletions(-)
diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
index 2c81af7..ac891c8 100644
--- a/src/mesa/main/viewport.c
+++ b/src/mesa/main/viewport.c
@@ -34,6 +34,35 @@
#include "mtypes.h"
#include "viewport.h"
+static void
+set_viewport_no_notify(struct gl_context *ctx, unsigned idx, GLint x, GLint y,
+ GLsizei width, GLsizei height)
+{
+ /* clamp width and height to the implementation dependent range */
+ width = MIN2(width, (GLsizei) ctx->Const.MaxViewportWidth);
+ height = MIN2(height, (GLsizei) ctx->Const.MaxViewportHeight);
+
+ ctx->ViewportArray[idx].X = x;
+ ctx->ViewportArray[idx].Width = width;
+ ctx->ViewportArray[idx].Y = y;
+ ctx->ViewportArray[idx].Height = height;
+ ctx->NewState |= _NEW_VIEWPORT;
+
+#if 1
+ /* XXX remove this someday. Currently the DRI drivers rely on
+* the WindowMap matrix being up to date in the driver's Viewport
+* and DepthRange functions.
+*/
+ _math_matrix_viewport(&ctx->ViewportArray[idx]._WindowMap,
+ ctx->ViewportArray[idx].X,
+ ctx->ViewportArray[idx].Y,
+ ctx->ViewportArray[idx].Width,
+ ctx->ViewportArray[idx].Height,
+ ctx->ViewportArray[idx].Near,
+ ctx->ViewportArray[idx].Far,
+ ctx->DrawBuffer->_DepthMaxF);
+#endif
+}
/**
* Set the viewport.
@@ -57,7 +86,14 @@ _mesa_Viewport(GLint x, GLint y, GLsizei width, GLsizei
height)
return;
}
- _mesa_set_viewport(ctx, 0, x, y, width, height);
+ set_viewport_no_notify(ctx, 0, x, y, width, height);
+
+ if (ctx->Driver.Viewport) {
+ /* Many drivers will use this call to check for window size changes
+ * and reallocate the z/stencil/accum/etc buffers if needed.
+ */
+ ctx->Driver.Viewport(ctx);
+ }
}
@@ -75,30 +111,7 @@ void
_mesa_set_viewport(struct gl_context *ctx, unsigned idx, GLint x, GLint y,
GLsizei width, GLsizei height)
{
- /* clamp width and height to the implementation dependent range */
- width = MIN2(width, (GLsizei) ctx->Const.MaxViewportWidth);
- height = MIN2(height, (GLsizei) ctx->Const.MaxViewportHeight);
-
- ctx->ViewportArray[idx].X = x;
- ctx->ViewportArray[idx].Width = width;
- ctx->ViewportArray[idx].Y = y;
- ctx->ViewportArray[idx].Height = height;
- ctx->NewState |= _NEW_VIEWPORT;
-
-#if 1
- /* XXX remove this someday. Currently the DRI drivers rely on
-* the WindowMap matrix being up to date in the driver's Viewport
-* and DepthRange functions.
-*/
- _math_matrix_viewport(&ctx->ViewportArray[idx]._WindowMap,
- ctx->ViewportArray[idx].X,
- ctx->ViewportArray[idx].Y,
- ctx->ViewportArray[idx].Width,
- ctx->ViewportArray[idx].Height,
- ctx->ViewportArray[idx].Near,
- ctx->ViewportArray[idx].Far,
- ctx->DrawBuffer->_DepthMaxF);
-#endif
+ set_viewport_no_notify(ctx, idx, x, y, width, height);
if (ctx->Driver.Viewport) {
/* Many drivers will use this call to check for window size changes
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 27/37] glsl: Add gl_ViewportIndex built-in variable
From: Courtney Goeltzenleuchter
v2 (idr): Fix copy-and-paste bug... s/LAYER/VIEWPORT/
Signed-off-by: Courtney Goeltzenleuchter
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/glsl/builtin_variables.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index f630923..d6bc3c0 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -780,6 +780,8 @@ void
builtin_variable_generator::generate_gs_special_vars()
{
add_output(VARYING_SLOT_LAYER, int_t, "gl_Layer");
+ if (state->ARB_viewport_array_enable)
+ add_output(VARYING_SLOT_VIEWPORT, int_t, "gl_ViewportIndex");
/* Although gl_PrimitiveID appears in tessellation control and tessellation
* evaluation shaders, it has a different function there than it has in
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 25/37] mesa: Add varying slot for viewport index
From: Ian Romanick Signed-off-by: Ian Romanick Reviewed-by: Kenneth Graunke --- src/mesa/main/mtypes.h| 2 ++ src/mesa/program/prog_print.c | 10 ++ 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index cac0206..2582132 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -235,6 +235,7 @@ typedef enum VARYING_SLOT_CLIP_DIST1, VARYING_SLOT_PRIMITIVE_ID, /* Does not appear in VS */ VARYING_SLOT_LAYER, /* Appears as VS or GS output */ + VARYING_SLOT_VIEWPORT, /* Appears as VS or GS output */ VARYING_SLOT_FACE, /* FS only */ VARYING_SLOT_PNTC, /* FS only */ VARYING_SLOT_VAR0, /* First generic varying slot */ @@ -270,6 +271,7 @@ typedef enum #define VARYING_BIT_CLIP_DIST1 BITFIELD64_BIT(VARYING_SLOT_CLIP_DIST1) #define VARYING_BIT_PRIMITIVE_ID BITFIELD64_BIT(VARYING_SLOT_PRIMITIVE_ID) #define VARYING_BIT_LAYER BITFIELD64_BIT(VARYING_SLOT_LAYER) +#define VARYING_BIT_VIEWPORT BITFIELD64_BIT(VARYING_SLOT_VIEWPORT) #define VARYING_BIT_FACE BITFIELD64_BIT(VARYING_SLOT_FACE) #define VARYING_BIT_PNTC BITFIELD64_BIT(VARYING_SLOT_PNTC) #define VARYING_BIT_VAR(V) BITFIELD64_BIT(VARYING_SLOT_VAR0 + (V)) diff --git a/src/mesa/program/prog_print.c b/src/mesa/program/prog_print.c index 9391e99..02ba01e 100644 --- a/src/mesa/program/prog_print.c +++ b/src/mesa/program/prog_print.c @@ -144,8 +144,9 @@ arb_input_attrib_string(GLint index, GLenum progType) "fragment.(eighteen)", /* VARYING_SLOT_CLIP_DIST1 */ "fragment.(nineteen)", /* VARYING_SLOT_PRIMITIVE_ID */ "fragment.(twenty)", /* VARYING_SLOT_LAYER */ - "fragment.(twenty-one)", /* VARYING_SLOT_FACE */ - "fragment.(twenty-two)", /* VARYING_SLOT_PNTC */ + "fragment.(twenty-one)", /* VARYING_SLOT_VIEWPORT */ + "fragment.(twenty-two)", /* VARYING_SLOT_FACE */ + "fragment.(twenty-three)", /* VARYING_SLOT_PNTC */ "fragment.varying[0]", "fragment.varying[1]", "fragment.varying[2]", @@ -268,8 +269,9 @@ arb_output_attrib_string(GLint index, GLenum progType) "result.(eighteen)", /* VARYING_SLOT_CLIP_DIST1 */ "result.(nineteen)", /* VARYING_SLOT_PRIMITIVE_ID */ "result.(twenty)", /* VARYING_SLOT_LAYER */ - "result.(twenty-one)", /* VARYING_SLOT_FACE */ - "result.(twenty-two)", /* VARYING_SLOT_PNTC */ + "result.(twenty-one)", /* VARYING_SLOT_VIEWPORT */ + "result.(twenty-two)", /* VARYING_SLOT_FACE */ + "result.(twenty-three)", /* VARYING_SLOT_PNTC */ "result.varying[0]", "result.varying[1]", "result.varying[2]", -- 1.8.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/37] mesa: Add new constants related to GL_ARB_viewport_array
From: Ian Romanick
These limits will be queryable by GL_MAX_VIEWPORTS,
GL_VIEWPORT_SUBPIXEL_BITS, and GL_VIEWPORT_BOUNDS_RANGE. Drivers that
actually implement the extension must set values for these constants
that comply with the minimum-maximums from the spec.
Most of these changes were part of other patches. They were separated out
because it make reordering of later patches easier. Also, MaxViewports wasn't
set by that patch, and I completely overlooked it in review. It's now obvious
that it's set. :)
v2 (idr): Split these changes out from the original patches. Keep
MaxViewportWidth and MaxViewportHeight as GLuint.
Signed-off-by: Courtney Goeltzenleuchter
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/config.h | 3 +++
src/mesa/main/context.c | 6 ++
src/mesa/main/mtypes.h | 6 ++
3 files changed, 15 insertions(+)
diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
index ff9da77..aa2b37a 100644
--- a/src/mesa/main/config.h
+++ b/src/mesa/main/config.h
@@ -137,6 +137,9 @@
#define MAX_VIEWPORT_WIDTH 16384
#define MAX_VIEWPORT_HEIGHT 16384
+/** Maximun number of viewports supported with ARB_viewport_array */
+#define MAX_VIEWPORTS 16
+
/** Maxmimum size for CVA. May be overridden by the drivers. */
#define MAX_ARRAY_LOCK_SIZE 3000
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 0b8fb94..538322e 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -588,6 +588,12 @@ _mesa_init_constants(struct gl_context *ctx)
ctx->Const.MaxViewportWidth = MAX_VIEWPORT_WIDTH;
ctx->Const.MaxViewportHeight = MAX_VIEWPORT_HEIGHT;
+ /* Driver must override these values if ARB_viewport_array is supported. */
+ ctx->Const.MaxViewports = 1;
+ ctx->Const.ViewportSubpixelBits = 0;
+ ctx->Const.ViewportBounds.Min = 0;
+ ctx->Const.ViewportBounds.Max = 0;
+
/** GL_ARB_uniform_buffer_object */
ctx->Const.MaxCombinedUniformBlocks = 36;
ctx->Const.MaxUniformBufferBindings = 36;
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 93390ec..a939d9c 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3166,6 +3166,12 @@ struct gl_constants
GLfloat MaxSpotExponent; /**< GL_NV_light_max_exponent */
GLuint MaxViewportWidth, MaxViewportHeight;
+ GLuint MaxViewports; /**< GL_ARB_viewport_array */
+ GLuint ViewportSubpixelBits; /**< GL_ARB_viewport_array */
+ struct {
+ GLfloat Min;
+ GLfloat Max;
+ } ViewportBounds; /**< GL_ARB_viewport_array */
struct gl_program_constants Program[MESA_SHADER_STAGES];
GLuint MaxProgramMatrices;
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 31/37] i965: Set all the supported viewports for GEN7
From: Ian Romanick
Currently MaxViewports is still 1, so this won't affect any change.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_cc.c | 21 +
src/mesa/drivers/dri/i965/brw_defines.h | 1 +
src/mesa/drivers/dri/i965/gen7_viewport_state.c | 63 +
3 files changed, 48 insertions(+), 37 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_cc.c
b/src/mesa/drivers/dri/i965/brw_cc.c
index 7eb7ee3..8ae25c9 100644
--- a/src/mesa/drivers/dri/i965/brw_cc.c
+++ b/src/mesa/drivers/dri/i965/brw_cc.c
@@ -45,16 +45,21 @@ brw_upload_cc_vp(struct brw_context *brw)
struct brw_cc_viewport *ccv;
ccv = brw_state_batch(brw, AUB_TRACE_CC_VP_STATE,
-sizeof(*ccv), 32, &brw->cc.vp_offset);
+sizeof(*ccv) * ctx->Const.MaxViewports, 32,
+ &brw->cc.vp_offset);
/* _NEW_TRANSFORM */
- if (ctx->Transform.DepthClamp) {
- /* _NEW_VIEWPORT */
- ccv->min_depth = MIN2(ctx->ViewportArray[0].Near,
ctx->ViewportArray[0].Far);
- ccv->max_depth = MAX2(ctx->ViewportArray[0].Near,
ctx->ViewportArray[0].Far);
- } else {
- ccv->min_depth = 0.0;
- ccv->max_depth = 1.0;
+ for (unsigned i = 0; i < ctx->Const.MaxViewports; i++) {
+ if (ctx->Transform.DepthClamp) {
+ /* _NEW_VIEWPORT */
+ ccv[i].min_depth = MIN2(ctx->ViewportArray[i].Near,
+ ctx->ViewportArray[i].Far);
+ ccv[i].max_depth = MAX2(ctx->ViewportArray[i].Near,
+ ctx->ViewportArray[i].Far);
+ } else {
+ ccv[i].min_depth = 0.0;
+ ccv[i].max_depth = 1.0;
+ }
}
brw->state.dirty.cache |= CACHE_NEW_CC_VP;
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 656179e..a4896f1 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1421,6 +1421,7 @@ enum brw_message_target {
# define GEN6_CC_VIEWPORT_MODIFY (1 << 12)
# define GEN6_SF_VIEWPORT_MODIFY (1 << 11)
# define GEN6_CLIP_VIEWPORT_MODIFY (1 << 10)
+# define GEN7_NUM_VIEWPORTS16
#define _3DSTATE_VIEWPORT_STATE_POINTERS_CC0x7823 /* GEN7+ */
#define _3DSTATE_VIEWPORT_STATE_POINTERS_SF_CL 0x7821 /* GEN7+ */
diff --git a/src/mesa/drivers/dri/i965/gen7_viewport_state.c
b/src/mesa/drivers/dri/i965/gen7_viewport_state.c
index ed7d8c9..9e23505 100644
--- a/src/mesa/drivers/dri/i965/gen7_viewport_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_viewport_state.c
@@ -34,34 +34,14 @@ gen7_upload_sf_clip_viewport(struct brw_context *brw)
const GLfloat depth_scale = 1.0F / ctx->DrawBuffer->_DepthMaxF;
GLfloat y_scale, y_bias;
const bool render_to_fbo = _mesa_is_user_fbo(ctx->DrawBuffer);
- const GLfloat *v = ctx->ViewportArray[0]._WindowMap.m;
struct gen7_sf_clip_viewport *vp;
vp = brw_state_batch(brw, AUB_TRACE_SF_VP_STATE,
- sizeof(*vp), 64, &brw->sf.vp_offset);
+sizeof(*vp) * ctx->Const.MaxViewports, 64,
+&brw->sf.vp_offset);
/* Also assign to clip.vp_offset in case something uses it. */
brw->clip.vp_offset = brw->sf.vp_offset;
- /* According to the "Vertex X,Y Clamping and Quantization" section of the
-* Strips and Fans documentation, objects must not have a screen-space
-* extents of over 8192 pixels, or they may be mis-rasterized. The maximum
-* screen space coordinates of a small object may larger, but we have no
-* way to enforce the object size other than through clipping.
-*
-* If you're surprised that we set clip to -gbx to +gbx and it seems like
-* we'll end up with 16384 wide, note that for a 8192-wide render target,
-* we'll end up with a normal (-1, 1) clip volume that just covers the
-* drawable.
-*/
- const float maximum_guardband_extent = 8192;
- float gbx = maximum_guardband_extent / ctx->ViewportArray[0].Width;
- float gby = maximum_guardband_extent / ctx->ViewportArray[0].Height;
-
- vp->guardband.xmin = -gbx;
- vp->guardband.xmax = gbx;
- vp->guardband.ymin = -gby;
- vp->guardband.ymax = gby;
-
/* _NEW_BUFFERS */
if (render_to_fbo) {
y_scale = 1.0;
@@ -71,13 +51,38 @@ gen7_upload_sf_clip_viewport(struct brw_context *brw)
y_bias = ctx->DrawBuffer->Height;
}
- /* _NEW_VIEWPORT */
- vp->viewport.m00 = v[MAT_SX];
- vp->viewport.m11 = v[MAT_SY] * y_scale;
- vp->viewport.m22 = v[MAT_SZ] * depth_scale;
- vp->viewport.m30 = v[MAT_TX];
- vp->viewport.m31 = v[MAT_TY] * y_scale + y_bias;
- vp->viewport.m32 = v[MAT_TZ] * depth_scale;
+ for (unsigned i = 0; i < ctx->Const.MaxViewports; i++) {
+ const GLfloat *const v = ctx->ViewportArray[i]._WindowMap.m;
+
+ /* According to the "Vertex X,Y Clampi
[Mesa-dev] [PATCH 24/37] mesa: Add new viewport and depth-range entry points for GL_ARB_viewport_array
From: Courtney Goeltzenleuchter
v2 (idr): Use set_viewport_no_notify / set_depth_range_no_notify (and
manually notify the driver) instead of calling _mesa_set_viewporti /
_mesa_set_depthrangei. Refactor bodies of _mesa_ViewportIndexed and
_mesa_ViewportIndexedv into a shared function. Remove spurious CLAMP
calls in _mesa_DepthRangeArrayv and _mesa_DepthRangeIndexed.
v3 (idr): Add some missing return-statements after calls to _mesa_error.
v4 (idr): Only perform the ViewportBounds.Min / ViewportBounds.Max
clamping in set_viewport_no_notify if GL_ARB_viewport_array is enabled.
Otherwise the driver may not have set ViewportBounds, and the clamping
will do bad things.
Signed-off-by: Courtney Goeltzenleuchter
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/viewport.c | 164 +++
src/mesa/main/viewport.h | 14
2 files changed, 178 insertions(+)
diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
index 07ca920..6545bf6 100644
--- a/src/mesa/main/viewport.c
+++ b/src/mesa/main/viewport.c
@@ -43,6 +43,21 @@ set_viewport_no_notify(struct gl_context *ctx, unsigned idx,
width = MIN2(width, (GLfloat) ctx->Const.MaxViewportWidth);
height = MIN2(height, (GLfloat) ctx->Const.MaxViewportHeight);
+ /* The GL_ARB_viewport_array spec says:
+*
+* "The location of the viewport's bottom-left corner, given by (x,y),
+* are clamped to be within the implementation-dependent viewport
+* bounds range. The viewport bounds range [min, max] tuple may be
+* determined by calling GetFloatv with the symbolic constant
+* VIEWPORT_BOUNDS_RANGE (see section 6.1)."
+*/
+ if (ctx->Extensions.ARB_viewport_array) {
+ x = CLAMP(x,
+ctx->Const.ViewportBounds.Min, ctx->Const.ViewportBounds.Max);
+ y = CLAMP(y,
+ctx->Const.ViewportBounds.Min, ctx->Const.ViewportBounds.Max);
+ }
+
ctx->ViewportArray[idx].X = x;
ctx->ViewportArray[idx].Width = width;
ctx->ViewportArray[idx].Y = y;
@@ -65,6 +80,15 @@ set_viewport_no_notify(struct gl_context *ctx, unsigned idx,
#endif
}
+struct gl_viewport_inputs {
+ GLfloat X, Y;/**< position */
+ GLfloat Width, Height; /**< size */
+};
+
+struct gl_depthrange_inputs {
+ GLdouble Near, Far; /**< Depth buffer range */
+};
+
/**
* Set the viewport.
* \sa Called via glViewport() or display list execution.
@@ -135,6 +159,85 @@ _mesa_set_viewport(struct gl_context *ctx, unsigned idx,
GLfloat x, GLfloat y,
}
}
+void GLAPIENTRY
+_mesa_ViewportArrayv(GLuint first, GLsizei count, const GLfloat *v)
+{
+ int i;
+ const struct gl_viewport_inputs *const p = (struct gl_viewport_inputs *) v;
+ GET_CURRENT_CONTEXT(ctx);
+
+ if (MESA_VERBOSE & VERBOSE_API)
+ _mesa_debug(ctx, "glViewportArrayv %d %d\n", first, count);
+
+ if ((first + count) > ctx->Const.MaxViewports) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glViewportArrayv: first (%d) + count (%d) > MaxViewports "
+ "(%d)",
+ first, count, ctx->Const.MaxViewports);
+ return;
+ }
+
+ /* Verify width & height */
+ for (i = 0; i < count; i++) {
+ if (p[i].Width < 0 || p[i].Height < 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glViewportArrayv: index (%d) width or height < 0 "
+ "(%f, %f)",
+ i + first, p[i].Width, p[i].Height);
+ return;
+ }
+ }
+
+ for (i = 0; i < count; i++)
+ set_viewport_no_notify(ctx, i + first,
+ p[i].X, p[i].Y,
+ p[i].Width, p[i].Height);
+
+ if (ctx->Driver.Viewport)
+ ctx->Driver.Viewport(ctx);
+}
+
+static void
+ViewportIndexedf(GLuint index, GLfloat x, GLfloat y,
+ GLfloat w, GLfloat h, const char *function)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ if (MESA_VERBOSE & VERBOSE_API)
+ _mesa_debug(ctx, "%s(%d, %f, %f, %f, %f)\n",
+ function, index, x, y, w, h);
+
+ if (index >= ctx->Const.MaxViewports) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "%s: index (%d) >= MaxViewports (%d)",
+ function, index, ctx->Const.MaxViewports);
+ return;
+ }
+
+ /* Verify width & height */
+ if (w < 0 || h < 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "%s: index (%d) width or height < 0 (%f, %f)",
+ function, index, w, h);
+ return;
+ }
+
+ _mesa_set_viewport(ctx, index, x, y, w, h);
+}
+
+void GLAPIENTRY
+_mesa_ViewportIndexedf(GLuint index, GLfloat x, GLfloat y,
+ GLfloat w, GLfloat h)
+{
+ ViewportIndexedf(index, x, y, w, h, "glViewportIndexedf");
+}
+
+void GLAPIENTRY
+_mesa_ViewportIndexedfv(GLuint index, const GLfloat *v)
+{
+ ViewportIndexedf(index, v[0], v[1], v[2], v[3], "glViewportIndexedfv");
+}
+
static void
[Mesa-dev] [PATCH 14/37] mesa: Initialize all the viewports
From: Ian Romanick
v2: Use MAX_VIEWPORTS instead of ctx->Const.MaxViewports because the
driver may not set ctx->Const.MaxViewports yet.
v3: Handle all viewport entries in update_viewport_matrix and
_mesa_copy_context too. This was previously in an earlier patch.
Having the code in the earlier patch could cause _mesa_copy_context to
access a matrix that hadn't been constructed.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke [v2]
---
src/mesa/main/context.c | 29 -
src/mesa/main/state.c| 13 -
src/mesa/main/viewport.c | 33 +
3 files changed, 49 insertions(+), 26 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 91fcbd2..1cd0064 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1357,14 +1357,17 @@ _mesa_copy_context( const struct gl_context *src,
struct gl_context *dst,
}
if (mask & GL_VIEWPORT_BIT) {
/* Cannot use memcpy, because of pointers in GLmatrix _WindowMap */
- dst->ViewportArray[0].X = src->ViewportArray[0].X;
- dst->ViewportArray[0].Y = src->ViewportArray[0].Y;
- dst->ViewportArray[0].Width = src->ViewportArray[0].Width;
- dst->ViewportArray[0].Height = src->ViewportArray[0].Height;
- dst->ViewportArray[0].Near = src->ViewportArray[0].Near;
- dst->ViewportArray[0].Far = src->ViewportArray[0].Far;
- _math_matrix_copy(&dst->ViewportArray[0]._WindowMap,
-&src->ViewportArray[0]._WindowMap);
+ unsigned i;
+ for (i = 0; i < src->Const.MaxViewports; i++) {
+ dst->ViewportArray[i].X = src->ViewportArray[i].X;
+ dst->ViewportArray[i].Y = src->ViewportArray[i].Y;
+ dst->ViewportArray[i].Width = src->ViewportArray[i].Width;
+ dst->ViewportArray[i].Height = src->ViewportArray[i].Height;
+ dst->ViewportArray[i].Near = src->ViewportArray[i].Near;
+ dst->ViewportArray[i].Far = src->ViewportArray[i].Far;
+ _math_matrix_copy(&dst->ViewportArray[i]._WindowMap,
+ &src->ViewportArray[i]._WindowMap);
+ }
}
/* XXX FIXME: Call callbacks?
@@ -1433,11 +1436,19 @@ void
_mesa_check_init_viewport(struct gl_context *ctx, GLuint width, GLuint height)
{
if (!ctx->ViewportInitialized && width > 0 && height > 0) {
+ unsigned i;
+
/* Note: set flag here, before calling _mesa_set_viewport(), to prevent
* potential infinite recursion.
*/
ctx->ViewportInitialized = GL_TRUE;
- _mesa_set_viewport(ctx, 0, 0, 0, width, height);
+
+ /* Note: ctx->Const.MaxViewports may not have been set by the driver
+ * yet, so just initialize all of them.
+ */
+ for (i = 0; i < MAX_VIEWPORTS; i++) {
+ _mesa_set_viewport(ctx, i, 0, 0, width, height);
+ }
_mesa_set_scissor(ctx, 0, 0, 0, width, height);
}
}
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index acb2f20..87f6553 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -269,6 +269,7 @@ static void
update_viewport_matrix(struct gl_context *ctx)
{
const GLfloat depthMax = ctx->DrawBuffer->_DepthMaxF;
+ unsigned i;
ASSERT(depthMax > 0);
@@ -276,11 +277,13 @@ update_viewport_matrix(struct gl_context *ctx)
* and should be maintained elsewhere if at all.
* NOTE: RasterPos uses this.
*/
- _math_matrix_viewport(&ctx->ViewportArray[0]._WindowMap,
- ctx->ViewportArray[0].X, ctx->ViewportArray[0].Y,
- ctx->ViewportArray[0].Width,
ctx->ViewportArray[0].Height,
- ctx->ViewportArray[0].Near, ctx->ViewportArray[0].Far,
- depthMax);
+ for (i = 0; i < ctx->Const.MaxViewports; i++) {
+ _math_matrix_viewport(&ctx->ViewportArray[i]._WindowMap,
+ctx->ViewportArray[i].X, ctx->ViewportArray[i].Y,
+ctx->ViewportArray[i].Width,
ctx->ViewportArray[i].Height,
+ctx->ViewportArray[i].Near,
ctx->ViewportArray[i].Far,
+depthMax);
+ }
}
diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
index ac891c8..cc031b0 100644
--- a/src/mesa/main/viewport.c
+++ b/src/mesa/main/viewport.c
@@ -197,18 +197,24 @@ _mesa_DepthRangef(GLclampf nearval, GLclampf farval)
void _mesa_init_viewport(struct gl_context *ctx)
{
GLfloat depthMax = 65535.0F; /* sorf of arbitrary */
+ unsigned i;
- /* Viewport group */
- ctx->ViewportArray[0].X = 0;
- ctx->ViewportArray[0].Y = 0;
- ctx->ViewportArray[0].Width = 0;
- ctx->ViewportArray[0].Height = 0;
- ctx->ViewportArray[0].Near = 0.0;
- ctx->ViewportArray[0].Far = 1.0;
- _math_matrix_ctr(&ctx->ViewportArray[0]._WindowMap);
-
- _math_matrix_viewport(&ctx->ViewportArray[0]._WindowMap, 0, 0, 0, 0,
- 0.0F, 1.0F, depthMax);
+ /* Note: ctx->Const.MaxView
[Mesa-dev] [PATCH 37/37] docs: Note that GL_ARB_viewport_array is done on i965
From: Ian Romanick At least for GEN7+, anyway. Signed-off-by: Ian Romanick Reviewed-by: Kenneth Graunke --- docs/GL3.txt| 2 +- docs/relnotes/10.1.html | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 0672ec7..3bded7d 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -120,7 +120,7 @@ GL 4.1: GL_ARB_separate_shader_objects some infrastructure done GL_ARB_shader_precision not started GL_ARB_vertex_attrib_64bit not started - GL_ARB_viewport_arraynot started + GL_ARB_viewport_arrayDONE (i965) GL 4.2: diff --git a/docs/relnotes/10.1.html b/docs/relnotes/10.1.html index 1089c71..0c90b21 100644 --- a/docs/relnotes/10.1.html +++ b/docs/relnotes/10.1.html @@ -46,6 +46,7 @@ Note: some of the new features are only available with certain drivers. GL_ARB_draw_indirect on i965. GL_ARB_clear_buffer_object +GL_ARB_viewport_array on i965. GL_AMD_shader_trinary_minmax. -- 1.8.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 26/37] glsl: Add extension infrastructure for ARB_viewport_array
From: Ian Romanick
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/glsl/glcpp/glcpp-parse.y| 3 +++
src/glsl/glsl_parser_extras.cpp | 1 +
src/glsl/glsl_parser_extras.h | 2 ++
src/glsl/standalone_scaffolding.cpp | 1 +
4 files changed, 7 insertions(+)
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index 55c4981..bbe8a06 100644
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -1284,6 +1284,9 @@ glcpp_parser_create (const struct gl_extensions
*extensions, int api)
if (extensions->AMD_shader_trinary_minmax)
add_builtin_define(parser, "GL_AMD_shader_trinary_minmax", 1);
+
+ if (extensions->ARB_viewport_array)
+add_builtin_define(parser, "GL_ARB_viewport_array", 1);
}
}
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 21dc3ab..ddb3d2d 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -513,6 +513,7 @@ static const _mesa_glsl_extension
_mesa_glsl_supported_extensions[] = {
EXT(ARB_shader_atomic_counters, true, false,
ARB_shader_atomic_counters),
EXT(ARB_sample_shading, true, false, ARB_sample_shading),
EXT(AMD_shader_trinary_minmax, true, false, dummy_true),
+ EXT(ARB_viewport_array, true, false, ARB_viewport_array),
};
#undef EXT
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index 2444a96..6f60b73 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -352,6 +352,8 @@ struct _mesa_glsl_parse_state {
bool ARB_shader_atomic_counters_warn;
bool AMD_shader_trinary_minmax_enable;
bool AMD_shader_trinary_minmax_warn;
+ bool ARB_viewport_array_enable;
+ bool ARB_viewport_array_warn;
/*@}*/
/** Extensions supported by the OpenGL implementation. */
diff --git a/src/glsl/standalone_scaffolding.cpp
b/src/glsl/standalone_scaffolding.cpp
index 257d2e7..9179471 100644
--- a/src/glsl/standalone_scaffolding.cpp
+++ b/src/glsl/standalone_scaffolding.cpp
@@ -110,6 +110,7 @@ void initialize_context_to_defaults(struct gl_context *ctx,
gl_api api)
ctx->Extensions.ARB_texture_query_levels = true;
ctx->Extensions.ARB_texture_query_lod = true;
ctx->Extensions.ARB_uniform_buffer_object = true;
+ ctx->Extensions.ARB_viewport_array = true;
ctx->Extensions.OES_EGL_image_external = true;
ctx->Extensions.OES_standard_derivatives = true;
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 35/37] i965: Consider all viewports before enabling guardband clipping
From: Ian Romanick
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen6_clip_state.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_clip_state.c
b/src/mesa/drivers/dri/i965/gen6_clip_state.c
index 3499e37..ed7afd7 100644
--- a/src/mesa/drivers/dri/i965/gen6_clip_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_clip_state.c
@@ -96,11 +96,15 @@ upload_clip_state(struct brw_context *brw)
dw2 |= (ctx->Transform.ClipPlanesEnabled <<
GEN6_USER_CLIP_CLIP_DISTANCES_SHIFT);
- if (ctx->ViewportArray[0].X == 0 &&
- ctx->ViewportArray[0].Y == 0 &&
- ctx->ViewportArray[0].Width == (float) fb->Width &&
- ctx->ViewportArray[0].Height == (float) fb->Height) {
- dw2 |= GEN6_CLIP_GB_TEST;
+ dw2 |= GEN6_CLIP_GB_TEST;
+ for (unsigned i = 0; i < ctx->Const.MaxViewports; i++) {
+ if (ctx->ViewportArray[i].X != 0 ||
+ ctx->ViewportArray[i].Y != 0 ||
+ ctx->ViewportArray[i].Width != (float) fb->Width ||
+ ctx->ViewportArray[i].Height != (float) fb->Height) {
+ dw2 &= ~GEN6_CLIP_GB_TEST;
+ break;
+ }
}
/* BRW_NEW_RASTERIZER_DISCARD */
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 20/37] mesa: Change parameter to _mesa_set_viewport to float
From: Ian Romanick
This matches the expectations of GL_ARB_viewport_array and the storage
type where the values will land.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/viewport.c | 13 +++--
src/mesa/main/viewport.h | 4 ++--
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
index ad16e87..07ca920 100644
--- a/src/mesa/main/viewport.c
+++ b/src/mesa/main/viewport.c
@@ -35,12 +35,13 @@
#include "viewport.h"
static void
-set_viewport_no_notify(struct gl_context *ctx, unsigned idx, GLint x, GLint y,
- GLsizei width, GLsizei height)
+set_viewport_no_notify(struct gl_context *ctx, unsigned idx,
+ GLfloat x, GLfloat y,
+ GLfloat width, GLfloat height)
{
/* clamp width and height to the implementation dependent range */
- width = MIN2(width, (GLsizei) ctx->Const.MaxViewportWidth);
- height = MIN2(height, (GLsizei) ctx->Const.MaxViewportHeight);
+ width = MIN2(width, (GLfloat) ctx->Const.MaxViewportWidth);
+ height = MIN2(height, (GLfloat) ctx->Const.MaxViewportHeight);
ctx->ViewportArray[idx].X = x;
ctx->ViewportArray[idx].Width = width;
@@ -121,8 +122,8 @@ _mesa_Viewport(GLint x, GLint y, GLsizei width, GLsizei
height)
* \param height height of the viewport rectangle.
*/
void
-_mesa_set_viewport(struct gl_context *ctx, unsigned idx, GLint x, GLint y,
-GLsizei width, GLsizei height)
+_mesa_set_viewport(struct gl_context *ctx, unsigned idx, GLfloat x, GLfloat y,
+GLfloat width, GLfloat height)
{
set_viewport_no_notify(ctx, idx, x, y, width, height);
diff --git a/src/mesa/main/viewport.h b/src/mesa/main/viewport.h
index 44bca1b..6e4c738 100644
--- a/src/mesa/main/viewport.h
+++ b/src/mesa/main/viewport.h
@@ -36,8 +36,8 @@ _mesa_Viewport(GLint x, GLint y, GLsizei width, GLsizei
height);
extern void
-_mesa_set_viewport(struct gl_context *ctx, unsigned idx, GLint x, GLint y,
- GLsizei width, GLsizei height);
+_mesa_set_viewport(struct gl_context *ctx, unsigned idx, GLfloat x, GLfloat y,
+ GLfloat width, GLfloat height);
extern void GLAPIENTRY
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 32/37] mesa: Refactor bounding-box calculation out of _mesa_update_draw_buffer_bounds
From: Ian Romanick
Drivers that currently use _Xmin and friends to set their scissor
rectangle will need to use this code directly once they are updated for
GL_ARB_viewport_array.
v2: Use different bit-test idiom and fix mixed tabs and spaces. Both
were suggested by Ken.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/framebuffer.c | 85 +
src/mesa/main/framebuffer.h | 5 +++
2 files changed, 61 insertions(+), 29 deletions(-)
diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index f14f7a4..bd8f493 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -357,6 +357,56 @@ update_framebuffer_size(struct gl_context *ctx, struct
gl_framebuffer *fb)
/**
+ * Calculate the inclusive bounding box for the scissor of a specific viewport
+ *
+ * \param ctx GL context.
+ * \param buffer Framebuffer to be checked against
+ * \param idx Index of the desired viewport
+ * \param bboxBounding box for the scissored viewport. Stored as xmin,
+ *xmax, ymin, ymax.
+ *
+ * \warning This function assumes that the framebuffer dimensions are up to
+ * date (e.g., update_framebuffer_size has been recently called on \c buffer).
+ *
+ * \sa _mesa_clip_to_region
+ */
+void
+_mesa_scissor_bounding_box(const struct gl_context *ctx,
+ const struct gl_framebuffer *buffer,
+ unsigned idx, int *bbox)
+{
+ bbox[0] = 0;
+ bbox[2] = 0;
+ bbox[1] = buffer->Width;
+ bbox[3] = buffer->Height;
+
+ if (ctx->Scissor.EnableFlags & (1u << idx)) {
+ if (ctx->Scissor.ScissorArray[idx].X > bbox[0]) {
+ bbox[0] = ctx->Scissor.ScissorArray[idx].X;
+ }
+ if (ctx->Scissor.ScissorArray[idx].Y > bbox[2]) {
+ bbox[2] = ctx->Scissor.ScissorArray[idx].Y;
+ }
+ if (ctx->Scissor.ScissorArray[idx].X +
ctx->Scissor.ScissorArray[idx].Width < bbox[1]) {
+ bbox[1] = ctx->Scissor.ScissorArray[idx].X +
ctx->Scissor.ScissorArray[idx].Width;
+ }
+ if (ctx->Scissor.ScissorArray[idx].Y +
ctx->Scissor.ScissorArray[idx].Height < bbox[3]) {
+ bbox[3] = ctx->Scissor.ScissorArray[idx].Y +
ctx->Scissor.ScissorArray[idx].Height;
+ }
+ /* finally, check for empty region */
+ if (bbox[0] > bbox[1]) {
+ bbox[0] = bbox[1];
+ }
+ if (bbox[2] > bbox[3]) {
+ bbox[2] = bbox[3];
+ }
+ }
+
+ ASSERT(bbox[0] <= bbox[1]);
+ ASSERT(bbox[2] <= bbox[3]);
+}
+
+/**
* Update the context's current drawing buffer's Xmin, Xmax, Ymin, Ymax fields.
* These values are computed from the buffer's width and height and
* the scissor box, if it's enabled.
@@ -366,6 +416,7 @@ void
_mesa_update_draw_buffer_bounds(struct gl_context *ctx)
{
struct gl_framebuffer *buffer = ctx->DrawBuffer;
+ int bbox[4];
if (!buffer)
return;
@@ -375,36 +426,12 @@ _mesa_update_draw_buffer_bounds(struct gl_context *ctx)
update_framebuffer_size(ctx, buffer);
}
- buffer->_Xmin = 0;
- buffer->_Ymin = 0;
- buffer->_Xmax = buffer->Width;
- buffer->_Ymax = buffer->Height;
-
/* Default to the first scissor as that's always valid */
- if (ctx->Scissor.EnableFlags & 1) {
- if (ctx->Scissor.ScissorArray[0].X > buffer->_Xmin) {
-buffer->_Xmin = ctx->Scissor.ScissorArray[0].X;
- }
- if (ctx->Scissor.ScissorArray[0].Y > buffer->_Ymin) {
-buffer->_Ymin = ctx->Scissor.ScissorArray[0].Y;
- }
- if (ctx->Scissor.ScissorArray[0].X + ctx->Scissor.ScissorArray[0].Width
< buffer->_Xmax) {
-buffer->_Xmax = ctx->Scissor.ScissorArray[0].X +
ctx->Scissor.ScissorArray[0].Width;
- }
- if (ctx->Scissor.ScissorArray[0].Y + ctx->Scissor.ScissorArray[0].Height
< buffer->_Ymax) {
-buffer->_Ymax = ctx->Scissor.ScissorArray[0].Y +
ctx->Scissor.ScissorArray[0].Height;
- }
- /* finally, check for empty region */
- if (buffer->_Xmin > buffer->_Xmax) {
- buffer->_Xmin = buffer->_Xmax;
- }
- if (buffer->_Ymin > buffer->_Ymax) {
- buffer->_Ymin = buffer->_Ymax;
- }
- }
-
- ASSERT(buffer->_Xmin <= buffer->_Xmax);
- ASSERT(buffer->_Ymin <= buffer->_Ymax);
+ _mesa_scissor_bounding_box(ctx, buffer, 0, bbox);
+ buffer->_Xmin = bbox[0];
+ buffer->_Ymin = bbox[2];
+ buffer->_Xmax = bbox[1];
+ buffer->_Ymax = bbox[3];
}
diff --git a/src/mesa/main/framebuffer.h b/src/mesa/main/framebuffer.h
index 2645664..a427421 100644
--- a/src/mesa/main/framebuffer.h
+++ b/src/mesa/main/framebuffer.h
@@ -71,6 +71,11 @@ _mesa_resize_framebuffer(struct gl_context *ctx, struct
gl_framebuffer *fb,
extern void
_mesa_resizebuffers( struct gl_context *ctx );
+extern void
+_mesa_scissor_bounding_box(const struct gl_context *ctx,
+ const struct gl_framebuffer *buffer,
+ unsigned idx, int *bbox);
+
extern void
_mesa_update
[Mesa-dev] [PATCH 18/37] mesa: Set all scissor rects
From: Ian Romanick
In _mesa_Scissor, make sure that ctx->Driver.Scissor is only called once
instead of once per scissor rectangle.
v2: Use MAX_VIEWPORTS instead of ctx->Const.MaxViewports because the
driver may not set ctx->Const.MaxViewports yet.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/context.c | 2 +-
src/mesa/main/scissor.c | 30 +++---
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 1cd0064..8078129 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1448,8 +1448,8 @@ _mesa_check_init_viewport(struct gl_context *ctx, GLuint
width, GLuint height)
*/
for (i = 0; i < MAX_VIEWPORTS; i++) {
_mesa_set_viewport(ctx, i, 0, 0, width, height);
+ _mesa_set_scissor(ctx, i, 0, 0, width, height);
}
- _mesa_set_scissor(ctx, 0, 0, 0, width, height);
}
}
diff --git a/src/mesa/main/scissor.c b/src/mesa/main/scissor.c
index 9266f1e..9caac2e 100644
--- a/src/mesa/main/scissor.c
+++ b/src/mesa/main/scissor.c
@@ -60,6 +60,7 @@ set_scissor_no_notify(struct gl_context *ctx, unsigned idx,
void GLAPIENTRY
_mesa_Scissor( GLint x, GLint y, GLsizei width, GLsizei height )
{
+ unsigned i;
GET_CURRENT_CONTEXT(ctx);
if (MESA_VERBOSE & VERBOSE_API)
@@ -70,7 +71,23 @@ _mesa_Scissor( GLint x, GLint y, GLsizei width, GLsizei
height )
return;
}
- _mesa_set_scissor(ctx, 0, x, y, width, height);
+ /* The GL_ARB_viewport_array spec says:
+*
+* "Scissor sets the scissor rectangle for all viewports to the same
+* values and is equivalent (assuming no errors are generated) to:
+*
+* for (uint i = 0; i < MAX_VIEWPORTS; i++) {
+* ScissorIndexed(i, left, bottom, width, height);
+* }"
+*
+* Set the scissor rectangle for all of the viewports supported by the
+* implementation, but only signal the driver once at the end.
+*/
+ for (i = 0; i < ctx->Const.MaxViewports; i++)
+ set_scissor_no_notify(ctx, i, x, y, width, height);
+
+ if (ctx->Driver.Scissor)
+ ctx->Driver.Scissor(ctx);
}
@@ -105,7 +122,14 @@ _mesa_set_scissor(struct gl_context *ctx, unsigned idx,
void
_mesa_init_scissor(struct gl_context *ctx)
{
+ unsigned i;
+
/* Scissor group */
- ctx->Scissor.EnableFlags = GL_FALSE;
- set_scissor_no_notify(ctx, 0, 0, 0, 0, 0);
+ ctx->Scissor.EnableFlags = 0;
+
+ /* Note: ctx->Const.MaxViewports may not have been set by the driver yet,
+* so just initialize all of them.
+*/
+ for (i = 0; i < MAX_VIEWPORTS; i++)
+ set_scissor_no_notify(ctx, i, 0, 0, 0, 0);
}
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/37] mesa: Refactor depth range setting even more
From: Ian Romanick
Create an internal function that just writes data into the depth range.
In future patches this will see more use because we only want to call
dd_function_table::DepthRange once after setting all of the depth ranges
instead of once per depth range.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/viewport.c | 57
src/mesa/main/viewport.h | 3 +++
2 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
index d4b0393..2c81af7 100644
--- a/src/mesa/main/viewport.c
+++ b/src/mesa/main/viewport.c
@@ -108,6 +108,43 @@ _mesa_set_viewport(struct gl_context *ctx, unsigned idx,
GLint x, GLint y,
}
}
+static void
+set_depth_range_no_notify(struct gl_context *ctx, unsigned idx,
+ GLclampd nearval, GLclampd farval)
+{
+ if (ctx->ViewportArray[idx].Near == nearval &&
+ ctx->ViewportArray[idx].Far == farval)
+ return;
+
+ ctx->ViewportArray[idx].Near = CLAMP(nearval, 0.0, 1.0);
+ ctx->ViewportArray[idx].Far = CLAMP(farval, 0.0, 1.0);
+ ctx->NewState |= _NEW_VIEWPORT;
+
+#if 1
+ /* XXX remove this someday. Currently the DRI drivers rely on
+* the WindowMap matrix being up to date in the driver's Viewport
+* and DepthRange functions.
+*/
+ _math_matrix_viewport(&ctx->ViewportArray[idx]._WindowMap,
+ ctx->ViewportArray[idx].X,
+ ctx->ViewportArray[idx].Y,
+ ctx->ViewportArray[idx].Width,
+ ctx->ViewportArray[idx].Height,
+ ctx->ViewportArray[idx].Near,
+ ctx->ViewportArray[idx].Far,
+ ctx->DrawBuffer->_DepthMaxF);
+#endif
+}
+
+void
+_mesa_set_depth_range(struct gl_context *ctx, unsigned idx,
+ GLclampd nearval, GLclampd farval)
+{
+ set_depth_range_no_notify(ctx, idx, nearval, farval);
+
+ if (ctx->Driver.DepthRange)
+ ctx->Driver.DepthRange(ctx);
+}
/**
* Called by glDepthRange
@@ -127,25 +164,7 @@ _mesa_DepthRange(GLclampd nearval, GLclampd farval)
if (MESA_VERBOSE&VERBOSE_API)
_mesa_debug(ctx, "glDepthRange %f %f\n", nearval, farval);
- if (ctx->ViewportArray[0].Near == nearval &&
- ctx->ViewportArray[0].Far == farval)
- return;
-
- ctx->ViewportArray[0].Near = CLAMP(nearval, 0.0, 1.0);
- ctx->ViewportArray[0].Far = CLAMP(farval, 0.0, 1.0);
- ctx->NewState |= _NEW_VIEWPORT;
-
-#if 1
- /* XXX remove this someday. Currently the DRI drivers rely on
-* the WindowMap matrix being up to date in the driver's Viewport
-* and DepthRange functions.
-*/
- _math_matrix_viewport(&ctx->ViewportArray[0]._WindowMap,
- ctx->ViewportArray[0].X, ctx->ViewportArray[0].Y,
- ctx->ViewportArray[0].Width,
ctx->ViewportArray[0].Height,
- ctx->ViewportArray[0].Near, ctx->ViewportArray[0].Far,
- ctx->DrawBuffer->_DepthMaxF);
-#endif
+ set_depth_range_no_notify(ctx, 0, nearval, farval);
if (ctx->Driver.DepthRange) {
ctx->Driver.DepthRange(ctx);
diff --git a/src/mesa/main/viewport.h b/src/mesa/main/viewport.h
index b4eb521..44bca1b 100644
--- a/src/mesa/main/viewport.h
+++ b/src/mesa/main/viewport.h
@@ -46,6 +46,9 @@ _mesa_DepthRange(GLclampd nearval, GLclampd farval);
extern void GLAPIENTRY
_mesa_DepthRangef(GLclampf nearval, GLclampf farval);
+extern void
+_mesa_set_depth_range(struct gl_context *ctx, unsigned idx,
+ GLclampd nearval, GLclampd farval);
extern void
_mesa_init_viewport(struct gl_context *ctx);
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/37] mesa: Add an index parameter to _mesa_set_scissor
From: Ian Romanick
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/attrib.c | 2 +-
src/mesa/main/context.c | 2 +-
src/mesa/main/scissor.c | 6 +++---
src/mesa/main/scissor.h | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index 3a6bf05..f55433e 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1271,7 +1271,7 @@ _mesa_PopAttrib(void)
{
const struct gl_scissor_attrib *scissor;
scissor = (const struct gl_scissor_attrib *) attr->data;
- _mesa_set_scissor(ctx,
+ _mesa_set_scissor(ctx, 0,
scissor->ScissorArray[0].X,
scissor->ScissorArray[0].Y,
scissor->ScissorArray[0].Width,
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 5af0c02..91fcbd2 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1438,7 +1438,7 @@ _mesa_check_init_viewport(struct gl_context *ctx, GLuint
width, GLuint height)
*/
ctx->ViewportInitialized = GL_TRUE;
_mesa_set_viewport(ctx, 0, 0, 0, width, height);
- _mesa_set_scissor(ctx, 0, 0, width, height);
+ _mesa_set_scissor(ctx, 0, 0, 0, width, height);
}
}
diff --git a/src/mesa/main/scissor.c b/src/mesa/main/scissor.c
index cc4ce69..9266f1e 100644
--- a/src/mesa/main/scissor.c
+++ b/src/mesa/main/scissor.c
@@ -70,7 +70,7 @@ _mesa_Scissor( GLint x, GLint y, GLsizei width, GLsizei
height )
return;
}
- _mesa_set_scissor(ctx, x, y, width, height);
+ _mesa_set_scissor(ctx, 0, x, y, width, height);
}
@@ -88,10 +88,10 @@ _mesa_Scissor( GLint x, GLint y, GLsizei width, GLsizei
height )
* the dd_function_table::Scissor callback.
*/
void
-_mesa_set_scissor(struct gl_context *ctx,
+_mesa_set_scissor(struct gl_context *ctx, unsigned idx,
GLint x, GLint y, GLsizei width, GLsizei height)
{
- set_scissor_no_notify(ctx, 0, x, y, width, height);
+ set_scissor_no_notify(ctx, idx, x, y, width, height);
if (ctx->Driver.Scissor)
ctx->Driver.Scissor(ctx);
diff --git a/src/mesa/main/scissor.h b/src/mesa/main/scissor.h
index 0d7e201..5726a00 100644
--- a/src/mesa/main/scissor.h
+++ b/src/mesa/main/scissor.h
@@ -36,7 +36,7 @@ _mesa_Scissor( GLint x, GLint y, GLsizei width, GLsizei
height );
extern void
-_mesa_set_scissor(struct gl_context *ctx,
+_mesa_set_scissor(struct gl_context *ctx, unsigned idx,
GLint x, GLint y, GLsizei width, GLsizei height);
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 36/37] i965: Enable ARB_viewport_array
From: Courtney Goeltzenleuchter
v2 (idr): Only enable the extension on GEN7+ w/core profile because it
requires geometry shaders.
v3 (idr): Add some casting to fix setting of ViewportBounds.Min.
Negating an unsigned value, then casting to float doesn't do what you
might think it does.
Signed-off-by: Courtney Goeltzenleuchter
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.c | 11 +++
src/mesa/drivers/dri/i965/intel_extensions.c | 6 ++
2 files changed, 17 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 51918b9..7227c58 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -474,6 +474,17 @@ brw_initialize_context_constants(struct brw_context *brw)
}
ctx->ShaderCompilerOptions[MESA_SHADER_VERTEX].PreferDP4 = true;
+
+ /* ARB_viewport_array */
+ if (brw->gen >= 7 && ctx->API == API_OPENGL_CORE) {
+ ctx->Const.MaxViewports = GEN7_NUM_VIEWPORTS;
+ ctx->Const.ViewportSubpixelBits = 0;
+
+ /* Cast to float before negating becuase MaxViewportWidth is unsigned.
+ */
+ ctx->Const.ViewportBounds.Min = -(float)ctx->Const.MaxViewportWidth;
+ ctx->Const.ViewportBounds.Max = ctx->Const.MaxViewportWidth;
+ }
}
/**
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index f3dc823..ab73434 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -294,6 +294,12 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Extensions.ARB_transform_feedback_instanced = true;
ctx->Extensions.ARB_draw_indirect = true;
}
+
+ /* Only enable this in core profile because other parts of Mesa behave
+ * slightly differently when the extension is enabled.
+ */
+ if (ctx->API == API_OPENGL_CORE)
+ ctx->Extensions.ARB_viewport_array = true;
}
if (brw->gen == 5 || can_write_oacontrol(brw))
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 30/37] i965: Emit writes to viewport index
From: Ian Romanick
This variable is handled in a fashion identical to gl_Layer.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 4
src/mesa/drivers/dri/i965/brw_vs.c | 6 +++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 3b8cef6..f6dc3a8 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -2772,6 +2772,10 @@ vec4_visitor::emit_psiz_and_flags(struct brw_reg reg)
emit(MOV(retype(brw_writemask(reg, WRITEMASK_Y), BRW_REGISTER_TYPE_D),
src_reg(output_reg[VARYING_SLOT_LAYER])));
}
+ if (prog_data->vue_map.slots_valid & VARYING_BIT_VIEWPORT) {
+ emit(MOV(retype(brw_writemask(reg, WRITEMASK_Z), BRW_REGISTER_TYPE_D),
+ src_reg(output_reg[VARYING_SLOT_VIEWPORT])));
+ }
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
b/src/mesa/drivers/dri/i965/brw_vs.c
index d09e455..ba0193e 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -60,10 +60,10 @@ brw_compute_vue_map(struct brw_context *brw, struct
brw_vue_map *vue_map,
vue_map->slots_valid = slots_valid;
int i;
- /* gl_Layer doesn't get its own varying slot--it's stored in the virst VUE
-* slot (VARYING_SLOT_PSIZ).
+ /* gl_Layer and gl_ViewportIndex don't get their own varying slots -- they
+* are stored in the virst VUE slot (VARYING_SLOT_PSIZ).
*/
- slots_valid &= ~VARYING_BIT_LAYER;
+ slots_valid &= ~(VARYING_BIT_LAYER | VARYING_BIT_VIEWPORT);
/* Make sure that the values we store in vue_map->varying_to_slot and
* vue_map->slot_to_varying won't overflow the signed chars that are used
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 34/37] i965: Consider only the scissor rectangle for viewport 0 for clears
From: Ian Romanick
noop_scissor (correctly) only examines the scissor rectangle for
viewport 0. Therefore, it should only be called when that scissor
rectangle is enabled.
Signed-off-by: Ian Romanick
---
src/mesa/drivers/dri/i965/brw_clear.c | 2 +-
src/mesa/drivers/dri/radeon/radeon_common.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
b/src/mesa/drivers/dri/i965/brw_clear.c
index 72950cb..659d339 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -121,7 +121,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
* a previous clear had happened at a different clear value and resolve it
* first.
*/
- if (ctx->Scissor.EnableFlags && !noop_scissor(ctx, fb)) {
+ if ((ctx->Scissor.EnableFlags & 1) && !noop_scissor(ctx, fb)) {
perf_debug("Failed to fast clear depth due to scissor being enabled. "
"Possible 5%% performance win if avoided.\n");
return false;
diff --git a/src/mesa/drivers/dri/radeon/radeon_common.c
b/src/mesa/drivers/dri/radeon/radeon_common.c
index e900bc5..d8839d1 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common.c
+++ b/src/mesa/drivers/dri/radeon/radeon_common.c
@@ -400,8 +400,7 @@ void radeon_viewport(struct gl_context *ctx)
{
radeonContextPtr radeon = RADEON_CONTEXT(ctx);
__DRIcontext *driContext = radeon->dri.context;
- void (*old_viewport)(struct gl_context *ctx, GLint x, GLint y,
-GLsizei w, GLsizei h);
+ void (*old_viewport)(struct gl_context *ctx);
if (_mesa_is_winsys_fbo(ctx->DrawBuffer)) {
if (radeon->is_front_buffer_rendering) {
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 16/37] mesa: Restore all the viewports in _mesa_PopAttrib
From: Ian Romanick
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke
---
src/mesa/main/attrib.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index db659ad..7b7cf0e 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1357,10 +1357,15 @@ _mesa_PopAttrib(void)
break;
case GL_VIEWPORT_BIT:
{
+ unsigned i;
const struct gl_viewport_attrib *vp;
vp = (const struct gl_viewport_attrib *) attr->data;
- _mesa_Viewport(vp->X, vp->Y, vp->Width, vp->Height);
- _mesa_DepthRange(vp->Near, vp->Far);
+
+ for (i = 0; i < ctx->Const.MaxViewports; i++) {
+ _mesa_set_viewport(ctx, i, vp[i].X, vp[i].Y, vp[i].Width,
+ vp[i].Height);
+ _mesa_set_depth_range(ctx, i, vp[i].Near, vp[i].Far);
+ }
}
break;
case GL_MULTISAMPLE_BIT_ARB:
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Only update renderbuffers on initial intelMakeCurrent
We call intel_prepare_render() in intelMakeCurrent() to make sure we have
renderbuffers before calling _mesa_make_current(). The only reason we
do this is so that we can have valid defaults for width and height.
If we already have buffers for the drawable we're making current, we
don't need to do this.
In itself, this is a small optimization, but it also avoids a round trip
that could block on the display server in a unexpected place.
https://bugs.freedesktop.org/show_bug.cgi?id=72540
https://bugs.freedesktop.org/show_bug.cgi?id=72612
Signed-off-by: Kristian Høgsberg
Review-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_context.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 51918b9..173f95a 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -906,6 +906,7 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
if (driContextPriv) {
struct gl_context *ctx = &brw->ctx;
struct gl_framebuffer *fb, *readFb;
+ struct intel_renderbuffer *rb = NULL;
if (driDrawPriv == NULL && driReadPriv == NULL) {
fb = _mesa_get_incomplete_framebuffer();
@@ -913,6 +914,7 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
} else {
fb = driDrawPriv->driverPrivate;
readFb = driReadPriv->driverPrivate;
+ rb = intel_get_renderbuffer(fb, BUFFER_BACK_LEFT);
driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1;
driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1;
}
@@ -924,7 +926,12 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
intel_gles3_srgb_workaround(brw, fb);
intel_gles3_srgb_workaround(brw, readFb);
- intel_prepare_render(brw);
+ if (rb && !rb->mt) {
+ /* If we don't have buffers for the drawable yet, force a call to
+ * getbuffers here so we can have a default drawable size. */
+ intel_prepare_render(brw);
+ }
+
_mesa_make_current(ctx, fb, readFb);
} else {
_mesa_make_current(NULL, NULL, NULL);
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 34/37] i965: Consider only the scissor rectangle for viewport 0 for clears
On 01/17/2014 05:03 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> noop_scissor (correctly) only examines the scissor rectangle for
> viewport 0. Therefore, it should only be called when that scissor
> rectangle is enabled.
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/drivers/dri/i965/brw_clear.c | 2 +-
> src/mesa/drivers/dri/radeon/radeon_common.c | 3 +--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
> b/src/mesa/drivers/dri/i965/brw_clear.c
> index 72950cb..659d339 100644
> --- a/src/mesa/drivers/dri/i965/brw_clear.c
> +++ b/src/mesa/drivers/dri/i965/brw_clear.c
> @@ -121,7 +121,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
> * a previous clear had happened at a different clear value and resolve it
> * first.
> */
> - if (ctx->Scissor.EnableFlags && !noop_scissor(ctx, fb)) {
> + if ((ctx->Scissor.EnableFlags & 1) && !noop_scissor(ctx, fb)) {
>perf_debug("Failed to fast clear depth due to scissor being enabled. "
> "Possible 5%% performance win if avoided.\n");
>return false;
This hunk is:
Reviewed-by: Kenneth Graunke
But:
> diff --git a/src/mesa/drivers/dri/radeon/radeon_common.c
> b/src/mesa/drivers/dri/radeon/radeon_common.c
> index e900bc5..d8839d1 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_common.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_common.c
> @@ -400,8 +400,7 @@ void radeon_viewport(struct gl_context *ctx)
> {
> radeonContextPtr radeon = RADEON_CONTEXT(ctx);
> __DRIcontext *driContext = radeon->dri.context;
> - void (*old_viewport)(struct gl_context *ctx, GLint x, GLint y,
> - GLsizei w, GLsizei h);
> + void (*old_viewport)(struct gl_context *ctx);
>
> if (_mesa_is_winsys_fbo(ctx->DrawBuffer)) {
> if (radeon->is_front_buffer_rendering) {
>
This hunk clearly goes somewhere else.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Only update renderbuffers on initial intelMakeCurrent
On Fri, Jan 17, 2014 at 5:21 PM, Kristian Høgsberg wrote: > We call intel_prepare_render() in intelMakeCurrent() to make sure we have > renderbuffers before calling _mesa_make_current(). The only reason we > do this is so that we can have valid defaults for width and height. > If we already have buffers for the drawable we're making current, we > don't need to do this. > > In itself, this is a small optimization, but it also avoids a round trip > that could block on the display server in a unexpected place. > > https://bugs.freedesktop.org/show_bug.cgi?id=72540 > https://bugs.freedesktop.org/show_bug.cgi?id=72612 > > Signed-off-by: Kristian Høgsberg > Review-by: Chad Versace Reviewed. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73755] New: [softpipe] piglit fbo-missing-attachment-blit es2 from regression
https://bugs.freedesktop.org/show_bug.cgi?id=73755 Priority: medium Bug ID: 73755 Keywords: regression CC: bri...@vmware.com, mar...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: [softpipe] piglit fbo-missing-attachment-blit es2 from regression Severity: normal Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa mesa: 1c5e2965a0de296240dd8f5af12482164416b7f1 (master) $ ./bin/fbo-missing-attachment-blit es2 from -auto Testing blit from buffer with missing attachment to complete buffer... Segmentation fault (core dumped) Program terminated with signal 11, Segmentation fault. #0 0x7fbbe37acf85 in sp_find_cached_tile (tc=0x15f9040, addr=...) at sp_tile_cache.c:499 499 assert(pt->resource); (gdb) bt #0 0x7fbbe37acf85 in sp_find_cached_tile (tc=0x15f9040, addr=...) at sp_tile_cache.c:499 #1 0x7fbbe378ff5a in sp_get_cached_tile (tc=0x15f9040, x=8, y=8) at sp_tile_cache.h:152 #2 0x7fbbe3797c31 in single_output_color (qs=0x1617610, quads=0x16ca5e0, nr=4) at sp_quad_blend.c:1180 #3 0x7fbbe379807e in choose_blend_quad (qs=0x1617610, quads=0x16ca5e0, nr=4) at sp_quad_blend.c:1280 #4 0x7fbbe378fcca in shade_quads (qs=0x1619c40, quads=0x16ca5e0, nr=4) at sp_quad_fs.c:146 #5 0x7fbbe378dc73 in depth_test_quads_fallback (qs=0x1619c70, quads=0x16ca5e0, nr=4) at sp_quad_depth_test.c:829 #6 0x7fbbe378f929 in choose_depth_test (qs=0x1619c70, quads=0x16ca5e0, nr=4) at sp_quad_depth_test.c:952 #7 0x7fbbe3798f8a in flush_spans (setup=0x16c80e0) at sp_setup.c:250 #8 0x7fbbe379a39a in subtriangle (setup=0x16c80e0, eleft=0x16c8138, eright=0x16c8120, lines=16) at sp_setup.c:754 #9 0x7fbbe379a68c in sp_setup_tri (setup=0x16c80e0, v0=0x177db10, v1=0x177db20, v2=0x177db30) at sp_setup.c:844 #10 0x7fbbe378a879 in sp_vbuf_draw_arrays (vbr=0x16c8040, start=0, nr=4) at sp_prim_vbuf.c:451 #11 0x7fbbe36769a1 in draw_pt_emit_linear (emit=0x1622a20, vert_info=0x7fff1096af60, prim_info=0x7fff1096b090) at draw/draw_pt_emit.c:258 #12 0x7fbbe3679596 in emit (emit=0x1622a20, vert_info=0x7fff1096af60, prim_info=0x7fff1096b090) at draw/draw_pt_fetch_shade_pipeline.c:183 #13 0x7fbbe3679b70 in fetch_pipeline_generic (middle=0x16228e0, fetch_info=0x0, in_prim_info=0x7fff1096b090) at draw/draw_pt_fetch_shade_pipeline.c:336 #14 0x7fbbe3679cc6 in fetch_pipeline_linear_run (middle=0x16228e0, start=0, count=4, prim_flags=0) at draw/draw_pt_fetch_shade_pipeline.c:397 #15 0x7fbbe3682478 in vsplit_segment_simple_linear (vsplit=0x16c2420, flags=0, istart=0, icount=4) at draw/draw_pt_vsplit_tmp.h:240 #16 0x7fbbe368276f in vsplit_run_linear (frontend=0x16c2420, start=0, count=4) at draw/draw_split_tmp.h:60 #17 0x7fbbe36750e5 in draw_pt_arrays (draw=0x16b7790, prim=5, start=0, count=4) at draw/draw_pt.c:149 #18 0x7fbbe3675ece in draw_vbo (draw=0x16b7790, info=0x7fff1096b1f0) at draw/draw_pt.c:562 #19 0x7fbbe37892fc in softpipe_draw_vbo (pipe=0x161ed00, info=0x7fff1096b340) at sp_draw_arrays.c:131 #20 0x7fbbe365acaa in cso_draw_vbo (cso=0x17213b0, info=0x7fff1096b340) at cso_cache/cso_context.c:1400 #21 0x7fbbe3535025 in st_draw_vbo (ctx=0x7fbbe16eb010, prims=0x7fff1096b410, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3, tfb_vertcount=0x0, indirect=0x0) at state_tracker/st_draw.c:290 #22 0x7fbbe34ec99d in vbo_draw_arrays (ctx=0x7fbbe16eb010, mode=5, start=0, count=4, numInstances=1, baseInstance=0) at vbo/vbo_exec_array.c:661 #23 0x7fbbe34ed3e8 in vbo_exec_DrawArrays (mode=5, start=0, count=4) at vbo/vbo_exec_array.c:813 #24 0x7fbbe7ac5c42 in stub_glDrawArrays (mode=5, first=0, count=4) at piglit/tests/util/generated_dispatch.c:6223 #25 0x7fbbe7ab49d7 in piglit_draw_rect_from_arrays (verts=0x7fff1096b510, tex=0x0) at piglit/tests/util/piglit-util-gl-common.c:632 #26 0x7fbbe7ab4e13 in piglit_draw_rect_z (z=0.5, x=-0.5, y=-0.5, w=1, h=1) at piglit/tests/util/piglit-util-gl-common.c:769 #27 0x00401638 in do_blit_test (use_es2=true, from_missing_to_complete=true) at piglit/tests/spec/arb_es2_compatibility/fbo-missing-attachment-blit.c:147 #28 0x004018fc in piglit_init (argc=3, argv=0x7fff1096b7d8) at piglit/tests/spec/arb_es2_compatibility/fbo-missing-attachment-blit.c:214 #29 0x7fbbe7ab78fa in run_test (gl_fw=0x7fbbe7da5340 , argc=3, argv=0x7fff1096b7d8) at piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:140 #30 0x7fbbe7ab56c9 in piglit_gl_test_run (argc=3, argv=0x7fff1096b7d8, config=0x7fff1096b6a0) at piglit/tests/util/piglit-framework-gl.c:191 #31 0x0040133e in main (argc=3, argv=0x7fff1096b7d8) at piglit/tests/spec/arb_es2_compatibili
[Mesa-dev] [Bug 73757] New: [swrast] SIGSEGV swrast/s_renderbuffer.c:559
https://bugs.freedesktop.org/show_bug.cgi?id=73757 Priority: medium Bug ID: 73757 Assignee: mesa-dev@lists.freedesktop.org Summary: [swrast] SIGSEGV swrast/s_renderbuffer.c:559 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa mesa: 1c5e2965a0de296240dd8f5af12482164416b7f1 (master) Run piglit fbo-drawbuffers-none glColorMaskIndexed on swrast. $ ./bin/fbo-drawbuffers-none glColorMaskIndexed -auto Testing glColorMaskIndexed. Probe color at (0,0) Expected: 1.00 1.00 0.20 1.00 Observed: 0.20 0.20 0.20 0.20 from color attachment 0, config (COLOR_ATTACHMENT3, COLOR_ATTACHMENT2, COLOR_ATTACHMENT1, COLOR_ATTACHMENT0) Probe color at (0,0) Expected: 0.20 0.20 1.00 1.00 Observed: 0.20 0.20 0.20 0.20 from color attachment 1, config (COLOR_ATTACHMENT3, COLOR_ATTACHMENT2, COLOR_ATTACHMENT1, COLOR_ATTACHMENT0) Probe color at (0,0) Expected: 0.20 1.00 0.00 0.20 Observed: 0.20 0.00 0.20 0.20 from color attachment 2, config (COLOR_ATTACHMENT3, COLOR_ATTACHMENT2, COLOR_ATTACHMENT1, COLOR_ATTACHMENT0) Segmentation fault (core dumped) Program terminated with signal 11, Segmentation fault. #0 0x7f45d2d61118 in map_attachment (ctx=0x7f45d7382010, fb=0x1fb3d00, buffer=4294967295) at swrast/s_renderbuffer.c:559 559 struct gl_texture_object *texObj = fb->Attachment[buffer].Texture; (gdb) bt #0 0x7f45d2d61118 in map_attachment (ctx=0x7f45d7382010, fb=0x1fb3d00, buffer=4294967295) at swrast/s_renderbuffer.c:559 #1 0x7f45d2d6155c in _swrast_map_renderbuffers (ctx=0x7f45d7382010) at swrast/s_renderbuffer.c:662 #2 0x7f45d2d5146e in _swrast_span_render_start (ctx=0x7f45d7382010) at swrast/s_context.c:877 #3 0x7f45d2d514ce in _swrast_render_start (ctx=0x7f45d7382010) at swrast/s_context.c:895 #4 0x7f45d2da0cbd in _swsetup_RenderStart (ctx=0x7f45d7382010) at swrast_setup/ss_context.c:202 #5 0x7f45d2d29725 in run_render (ctx=0x7f45d7382010, stage=0x1dd4b70) at tnl/t_vb_render.c:276 #6 0x7f45d2d15b5b in _tnl_run_pipeline (ctx=0x7f45d7382010) at tnl/t_pipeline.c:163 #7 0x7f45d2d1766d in _tnl_draw_prims (ctx=0x7f45d7382010, arrays=0x1dc1bb0, prim=0x7fffe431efa0, nr_prims=1, ib=0x0, min_index=0, max_index=3) at tnl/t_draw.c:526 #8 0x7f45d2d172bf in _tnl_vbo_draw_prims (ctx=0x7f45d7382010, prim=0x7fffe431efa0, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3, tfb_vertcount=0x0, indirect=0x0) at tnl/t_draw.c:426 #9 0x7f45d2cec5c4 in vbo_draw_arrays (ctx=0x7f45d7382010, mode=5, start=0, count=4, numInstances=1, baseInstance=0) at vbo/vbo_exec_array.c:661 #10 0x7f45d2ced00f in vbo_exec_DrawArrays (mode=5, start=0, count=4) at vbo/vbo_exec_array.c:813 #11 0x7f45d6f069d7 in piglit_draw_rect_from_arrays (verts=0x7fffe431f070, tex=0x0) at piglit/tests/util/piglit-util-gl-common.c:632 #12 0x7f45d6f06d4f in piglit_draw_rect (x=-1, y=-1, w=2, h=2) at piglit/tests/util/piglit-util-gl-common.c:741 #13 0x00401c3f in test_glColorMaskIndexed (drawbufs=0x402510 ) at piglit/tests/spec/arb_framebuffer_object/fbo-drawbuffers-none.c:294 #14 0x00402204 in piglit_init (argc=2, argv=0x7fffe431f2c8) at piglit/tests/spec/arb_framebuffer_object/fbo-drawbuffers-none.c:431 #15 0x7f45d6f098fa in run_test (gl_fw=0x7f45d71f7340 , argc=2, argv=0x7fffe431f2c8) at piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:140 #16 0x7f45d6f076c9 in piglit_gl_test_run (argc=2, argv=0x7fffe431f2c8, config=0x7fffe431f190) at piglit/tests/util/piglit-framework-gl.c:191 #17 0x00401630 in main (argc=2, argv=0x7fffe431f2c8) at piglit/tests/spec/arb_framebuffer_object/fbo-drawbuffers-none.c:50 (gdb) frame 0 #0 0x7f45d2d61118 in map_attachment (ctx=0x7f45d7382010, fb=0x1fb3d00, buffer=4294967295) at swrast/s_renderbuffer.c:559 559 struct gl_texture_object *texObj = fb->Attachment[buffer].Texture; (gdb) print /x buffer $1 = 0x -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/9] glsl: Add array specifier to ast code
> >
> > diff --git a/src/glsl/glsl_parser_extras.cpp
> > b/src/glsl/glsl_parser_extras.cpp
> > index 21dc3ab..92076b5 100644
> > --- a/src/glsl/glsl_parser_extras.cpp
> > +++ b/src/glsl/glsl_parser_extras.cpp
> > @@ -484,6 +484,7 @@ struct _mesa_glsl_extension {
> > static const _mesa_glsl_extension _mesa_glsl_supported_extensions[] = {
> > /* API availability */
> > /* name GL ES supported flag */
> > + EXT(ARB_arrays_of_arrays, true, false,
> > ARB_arrays_of_arrays),
> > EXT(ARB_conservative_depth, true, false,
> > ARB_conservative_depth),
> > EXT(ARB_draw_buffers, true, false, dummy_true),
> > EXT(ARB_draw_instanced, true, false,
> > ARB_draw_instanced),
> > @@ -769,7 +770,7 @@ _mesa_ast_set_aggregate_type(const ast_type_specifier
> > *type,
> >link);
> >
> > bool is_array = decl_list->type->specifier->is_array;
> > -ast_expression *array_size =
> > decl_list->type->specifier->array_size;
> > +ast_array_specifier *array_specifier =
> > decl_list->type->specifier->array_specifier;
> >
> > /* Recognize variable declarations with the bracketed size
> > attached
> > * to the type rather than the variable name as arrays. E.g.,
> > @@ -777,19 +778,18 @@ _mesa_ast_set_aggregate_type(const ast_type_specifier
> > *type,
> > * float a[2];
> > * float[2] b;
> > *
> > - * are both arrays, but 's array_size is decl->array_size,
> > while
> > - * 's array_size is decl_list->type->specifier->array_size.
> > + * are both arrays, but 's array_specifier is
> > decl->array_specifier, while
> > + * 's array_specifier is
> > decl_list->type->specifier->array_specifier.
> > */
> > if (!is_array) {
> > - /* FINISHME: Update when ARB_array_of_arrays is supported.
> > */
>
> There's another identical FINISHME in this function that I don't see
> in this patch.
>
> > is_array = decl->is_array;
> > - array_size = decl->array_size;
> > + array_specifier = decl->array_specifier;
> > }
>
> I don't think this is going to work for
>
>float[2] a[3]
>
> will it? is_array will be true, but the whole array_specifier won't be
> complete.
>
The arrays of arrays support is added in patch 7. These changes are just
to get things working with new array specifier. I should have left the
TODO removal until patch 7.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] st/vdpau: check surface params before creating resources
Signed-off-by: Ilia Mirkin
---
This seems like a function that should exist in gallium/util, but I didn't
find it. I guess the mesa/st does these checks far enough away from actual
resource creation.
src/gallium/state_trackers/vdpau/bitmap.c| 4
src/gallium/state_trackers/vdpau/output.c| 7 +++
src/gallium/state_trackers/vdpau/vdpau_private.h | 8
3 files changed, 19 insertions(+)
diff --git a/src/gallium/state_trackers/vdpau/bitmap.c
b/src/gallium/state_trackers/vdpau/bitmap.c
index 6110fc7..d316134 100644
--- a/src/gallium/state_trackers/vdpau/bitmap.c
+++ b/src/gallium/state_trackers/vdpau/bitmap.c
@@ -80,6 +80,10 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
res_tmpl.usage = frequently_accessed ? PIPE_USAGE_DYNAMIC :
PIPE_USAGE_STATIC;
pipe_mutex_lock(dev->mutex);
+
+ if (!CheckSurfaceParams(pipe->screen, &res_tmpl))
+ goto err_unlock;
+
res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
if (!res) {
ret = VDP_STATUS_RESOURCES;
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index 58edd37..50036ae 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -83,6 +83,10 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
res_tmpl.usage = PIPE_USAGE_STATIC;
pipe_mutex_lock(dev->mutex);
+
+ if (!CheckSurfaceParams(pipe->screen, &res_tmpl))
+ goto err_unlock;
+
res = pipe->screen->resource_create(pipe->screen, &res_tmpl);
if (!res)
goto err_unlock;
@@ -319,6 +323,9 @@ vlVdpOutputSurfacePutBitsIndexed(VdpOutputSurface surface,
pipe_mutex_lock(vlsurface->device->mutex);
vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL);
+ if (!CheckSurfaceParams(context->screen, &res_tmpl))
+ goto error_resource;
+
res = context->screen->resource_create(context->screen, &res_tmpl);
if (!res)
goto error_resource;
diff --git a/src/gallium/state_trackers/vdpau/vdpau_private.h
b/src/gallium/state_trackers/vdpau/vdpau_private.h
index 60196ac..6c2c019 100644
--- a/src/gallium/state_trackers/vdpau/vdpau_private.h
+++ b/src/gallium/state_trackers/vdpau/vdpau_private.h
@@ -332,6 +332,14 @@ RectToPipeBox(const VdpRect *rect, struct pipe_resource
*res)
return box;
}
+static inline bool
+CheckSurfaceParams(struct pipe_screen *screen,
+ const struct pipe_resource *templ)
+{
+ return screen->is_format_supported(
+ screen, templ->format, templ->target, templ->nr_samples, templ->bind);
+}
+
typedef struct
{
struct vl_screen *vscreen;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
