Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Ian Romanick]

On 06/27/2017 11:16 AM, Roland Scheidegger wrote:
> Am 27.06.2017 um 20:10 schrieb Ian Romanick:
>> On 06/27/2017 11:00 AM, Ilia Mirkin wrote:
>>> On Tue, Jun 27, 2017 at 1:11 PM, Ian Romanick  wrote:
 On 06/27/2017 02:59 AM, Timothy Arceri wrote:
> Just curious. Can this extension be added to NV04 and NV10? As those are
> the only drivers that don't currently support it.
>
> I have cards I could test those with, but don't have an NV20.

 I just sent out an updated series that I tested on NV20.  Thanks for
 reminding me. :)

 I *think* NV10 can do this, but the implementation would be... painful.
 NV10 (and on) supports texture borders... that extra one pixel of pixels
 on each side that's outside the usual [0,1]x[0,1] sampling range.  I
 believe this extension could be supported by creating every texture with
 a border and filling the border with the GL border color.
>>>
>>> That's right, they support the border inside the texture. I think that
>>> was killed in mesa though, and I have no interest in reinstating it :)
>>
>> We wouldn't have to.  It would just be internal to the way the driver
>> stores the texture on the hardware... kind of like how core Mesa doesn't
>> know anything about tiling formats, etc.  Either way, I'd want to be
>> 100% sure it would work before messing with it.  Someone with reverse
>> engineering skills would have to see if the blob does it that way first.
> 
> I don't think that would be practical either way, unless the border
> pixels are stored separately somewhere - surely you don't want to
> relayout the texture if you switch wrap mode?

I think you'd just always store it with the border, and you'd have to
update those texels each time border color changes... which would also
be lame. :(

> Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Roland Scheidegger]

Am 27.06.2017 um 20:10 schrieb Ian Romanick:
> On 06/27/2017 11:00 AM, Ilia Mirkin wrote:
>> On Tue, Jun 27, 2017 at 1:11 PM, Ian Romanick  wrote:
>>> On 06/27/2017 02:59 AM, Timothy Arceri wrote:
 Just curious. Can this extension be added to NV04 and NV10? As those are
 the only drivers that don't currently support it.

 I have cards I could test those with, but don't have an NV20.
>>>
>>> I just sent out an updated series that I tested on NV20.  Thanks for
>>> reminding me. :)
>>>
>>> I *think* NV10 can do this, but the implementation would be... painful.
>>> NV10 (and on) supports texture borders... that extra one pixel of pixels
>>> on each side that's outside the usual [0,1]x[0,1] sampling range.  I
>>> believe this extension could be supported by creating every texture with
>>> a border and filling the border with the GL border color.
>>
>> That's right, they support the border inside the texture. I think that
>> was killed in mesa though, and I have no interest in reinstating it :)
> 
> We wouldn't have to.  It would just be internal to the way the driver
> stores the texture on the hardware... kind of like how core Mesa doesn't
> know anything about tiling formats, etc.  Either way, I'd want to be
> 100% sure it would work before messing with it.  Someone with reverse
> engineering skills would have to see if the blob does it that way first.
> 

I don't think that would be practical either way, unless the border
pixels are stored separately somewhere - surely you don't want to
relayout the texture if you switch wrap mode?

Roland

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Ilia Mirkin]

On Tue, Jun 27, 2017 at 2:10 PM, Ian Romanick  wrote:
> On 06/27/2017 11:00 AM, Ilia Mirkin wrote:
>> On Tue, Jun 27, 2017 at 1:11 PM, Ian Romanick  wrote:
>>> On 06/27/2017 02:59 AM, Timothy Arceri wrote:
 Just curious. Can this extension be added to NV04 and NV10? As those are
 the only drivers that don't currently support it.

 I have cards I could test those with, but don't have an NV20.
>>>
>>> I just sent out an updated series that I tested on NV20.  Thanks for
>>> reminding me. :)
>>>
>>> I *think* NV10 can do this, but the implementation would be... painful.
>>> NV10 (and on) supports texture borders... that extra one pixel of pixels
>>> on each side that's outside the usual [0,1]x[0,1] sampling range.  I
>>> believe this extension could be supported by creating every texture with
>>> a border and filling the border with the GL border color.
>>
>> That's right, they support the border inside the texture. I think that
>> was killed in mesa though, and I have no interest in reinstating it :)
>
> We wouldn't have to.  It would just be internal to the way the driver
> stores the texture on the hardware... kind of like how core Mesa doesn't
> know anything about tiling formats, etc.  Either way, I'd want to be
> 100% sure it would work before messing with it.  Someone with reverse
> engineering skills would have to see if the blob does it that way first.

Ah right. I meant the border=1 support was gone from mesa in
glTexImage, I believe.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Ian Romanick]

On 06/27/2017 11:00 AM, Ilia Mirkin wrote:
> On Tue, Jun 27, 2017 at 1:11 PM, Ian Romanick  wrote:
>> On 06/27/2017 02:59 AM, Timothy Arceri wrote:
>>> Just curious. Can this extension be added to NV04 and NV10? As those are
>>> the only drivers that don't currently support it.
>>>
>>> I have cards I could test those with, but don't have an NV20.
>>
>> I just sent out an updated series that I tested on NV20.  Thanks for
>> reminding me. :)
>>
>> I *think* NV10 can do this, but the implementation would be... painful.
>> NV10 (and on) supports texture borders... that extra one pixel of pixels
>> on each side that's outside the usual [0,1]x[0,1] sampling range.  I
>> believe this extension could be supported by creating every texture with
>> a border and filling the border with the GL border color.
> 
> That's right, they support the border inside the texture. I think that
> was killed in mesa though, and I have no interest in reinstating it :)

We wouldn't have to.  It would just be internal to the way the driver
stores the texture on the hardware... kind of like how core Mesa doesn't
know anything about tiling formats, etc.  Either way, I'd want to be
100% sure it would work before messing with it.  Someone with reverse
engineering skills would have to see if the blob does it that way first.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Ilia Mirkin]

On Tue, Jun 27, 2017 at 1:11 PM, Ian Romanick  wrote:
> On 06/27/2017 02:59 AM, Timothy Arceri wrote:
>> Just curious. Can this extension be added to NV04 and NV10? As those are
>> the only drivers that don't currently support it.
>>
>> I have cards I could test those with, but don't have an NV20.
>
> I just sent out an updated series that I tested on NV20.  Thanks for
> reminding me. :)
>
> I *think* NV10 can do this, but the implementation would be... painful.
> NV10 (and on) supports texture borders... that extra one pixel of pixels
> on each side that's outside the usual [0,1]x[0,1] sampling range.  I
> believe this extension could be supported by creating every texture with
> a border and filling the border with the GL border color.

That's right, they support the border inside the texture. I think that
was killed in mesa though, and I have no interest in reinstating it :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Ian Romanick]

On 06/27/2017 02:59 AM, Timothy Arceri wrote:
> Just curious. Can this extension be added to NV04 and NV10? As those are
> the only drivers that don't currently support it.
> 
> I have cards I could test those with, but don't have an NV20.

I just sent out an updated series that I tested on NV20.  Thanks for
reminding me. :)

I *think* NV10 can do this, but the implementation would be... painful.
NV10 (and on) supports texture borders... that extra one pixel of pixels
on each side that's outside the usual [0,1]x[0,1] sampling range.  I
believe this extension could be supported by creating every texture with
a border and filling the border with the GL border color.

> On 09/09/16 10:56, Ilia Mirkin wrote:
> 
>> Signed-off-by: Ilia Mirkin 
>> ---
>>
>> This was tested on a NV25-on-NV34 situation. Should be tested on real
>> hardware
>> since my test environment relies on accurate emulation in the hw.
>>
>>   src/mesa/drivers/dri/nouveau/nv20_context.c   |  1 +
>>   src/mesa/drivers/dri/nouveau/nv20_state_tex.c | 29
>> ++-
>>   2 files changed, 29 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/nouveau/nv20_context.c
>> b/src/mesa/drivers/dri/nouveau/nv20_context.c
>> index ec638c0..6940b4d 100644
>> --- a/src/mesa/drivers/dri/nouveau/nv20_context.c
>> +++ b/src/mesa/drivers/dri/nouveau/nv20_context.c
>> @@ -456,6 +456,7 @@ nv20_context_create(struct nouveau_screen *screen,
>> gl_api api,
>>   if (!nouveau_context_init(ctx, api, screen, visual, share_ctx))
>>   goto fail;
>>   +ctx->Extensions.ARB_texture_border_clamp = true;
>>   ctx->Extensions.ARB_texture_env_crossbar = true;
>>   ctx->Extensions.ARB_texture_env_combine = true;
>>   ctx->Extensions.ARB_texture_env_dot3 = true;
>> diff --git a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>> b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>> index b0a4c9f..ef1799a 100644
>> --- a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>> +++ b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>> @@ -165,7 +165,8 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
>>   struct nouveau_surface *s;
>>   struct gl_texture_image *ti;
>>   const struct gl_sampler_object *sa;
>> -uint32_t tx_format, tx_filter, tx_wrap, tx_enable;
>> +uint8_t r, g, b, a;
>> +uint32_t tx_format, tx_filter, tx_wrap, tx_bcolor, tx_enable;
>> PUSH_RESET(push, BUFCTX_TEX(i));
>>   @@ -201,6 +202,29 @@ nv20_emit_tex_obj(struct gl_context *ctx, int
>> emit)
>>   | nvgl_filter_mode(sa->MinFilter) << 16
>>   | 2 << 12;
>>   +r = FLOAT_TO_UBYTE(sa->BorderColor.f[0]);
>> +g = FLOAT_TO_UBYTE(sa->BorderColor.f[1]);
>> +b = FLOAT_TO_UBYTE(sa->BorderColor.f[2]);
>> +a = FLOAT_TO_UBYTE(sa->BorderColor.f[3]);
>> +switch (ti->_BaseFormat) {
>> +case GL_LUMINANCE:
>> +a = 0xff;
>> +/* fallthrough */
>> +case GL_LUMINANCE_ALPHA:
>> +g = b = r;
>> +break;
>> +case GL_RGB:
>> +a = 0xff;
>> +break;
>> +case GL_INTENSITY:
>> +g = b = a = r;
>> +break;
>> +case GL_ALPHA:
>> +r = g = b = 0;
>> +break;
>> +}
>> +tx_bcolor = b << 0 | g << 8 | r << 16 | a << 24;
>> +
>>   tx_enable = NV20_3D_TEX_ENABLE_ENABLE
>>   | log2i(sa->MaxAnisotropy) << 4;
>>   @@ -249,6 +273,9 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
>>   BEGIN_NV04(push, NV20_3D(TEX_FILTER(i)), 1);
>>   PUSH_DATA (push, tx_filter);
>>   +BEGIN_NV04(push, NV20_3D(TEX_BORDER_COLOR(i)), 1);
>> +PUSH_DATA (push, tx_bcolor);
>> +
>>   BEGIN_NV04(push, NV20_3D(TEX_ENABLE(i)), 1);
>>   PUSH_DATA (push, tx_enable);
>>   
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Roland Scheidegger]

Am 27.06.2017 um 15:11 schrieb Ilia Mirkin:
> On Tue, Jun 27, 2017 at 9:07 AM, Roland Scheidegger  
> wrote:
>> Am 27.06.2017 um 15:01 schrieb Roland Scheidegger:
>>> These chips can't do border color? I wonder how they got away with that
>>> with d3d since afaik it isn't optional.
>> Err, I should have known better, EVERYTHING is optional with d3d9
>> (albeit it doesn't mean apps were actually prepared for hw not
>> supporting some of the more fundamental caps) "D3DPTADDRESSCAPS_BORDER:
>> Device supports setting coordinates outside the range [0.0, 1.0] to the
>> border color, as specified by the D3DSAMP_BORDERCOLOR texture-stage
>> state." So I suppose that's how they got away with it...
> 
> And don't forget the power of swrast fallbacks. None of these chips
> support 3D textures, for example.
> 
I think traditionally drivers didn't do swrast fallbacks for d3d, only
GL - because really a lot is optional (volume textures certainly are).
Though I suppose if the hw just gives you black on border color, it
might have been possible the driver says it's supported and does a
fallback only on non-black border (because IME most apps indeed do use a
black border when they use border color).
But anyway, I suppose supporting/emulating that isn't really practical.

Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Roland Scheidegger]

These chips can't do border color? I wonder how they got away with that
with d3d since afaik it isn't optional.
So what happens if you use these border wrap modes? You just get black
border?
I suppose another question is if you couldn't announce support for it
nevertheless. Without a border color, you can't do GL_CLAMP correctly
neither obviously (albeit that's a mode a few chips have problems with).
Though unless there's a really good reason to it's probably really not a
good idea...

Roland

Am 27.06.2017 um 13:53 schrieb Ilia Mirkin:
> This functionality is only available on NV20, NV25, and NV28 (i.e. all
> the NV2x boards). These are all AGP-only (discounting the NV2A inside
> Xbox), and I don't have any AGP systems. The way I tested it, through
> an emulation layer inside the NV3x hardware which lets it present the
> NV25's 3d class, is fine for initial development, but I don't know how
> accurate that emulation is to know if this would actually work on real
> hardware.
> 
> On Tue, Jun 27, 2017 at 5:59 AM, Timothy Arceri  wrote:
>> Just curious. Can this extension be added to NV04 and NV10? As those are the
>> only drivers that don't currently support it.
>>
>> I have cards I could test those with, but don't have an NV20.
>>
>>
>>
>> On 09/09/16 10:56, Ilia Mirkin wrote:
>>
>>> Signed-off-by: Ilia Mirkin 
>>> ---
>>>
>>> This was tested on a NV25-on-NV34 situation. Should be tested on real
>>> hardware
>>> since my test environment relies on accurate emulation in the hw.
>>>
>>>   src/mesa/drivers/dri/nouveau/nv20_context.c   |  1 +
>>>   src/mesa/drivers/dri/nouveau/nv20_state_tex.c | 29
>>> ++-
>>>   2 files changed, 29 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/nouveau/nv20_context.c
>>> b/src/mesa/drivers/dri/nouveau/nv20_context.c
>>> index ec638c0..6940b4d 100644
>>> --- a/src/mesa/drivers/dri/nouveau/nv20_context.c
>>> +++ b/src/mesa/drivers/dri/nouveau/nv20_context.c
>>> @@ -456,6 +456,7 @@ nv20_context_create(struct nouveau_screen *screen,
>>> gl_api api,
>>> if (!nouveau_context_init(ctx, api, screen, visual, share_ctx))
>>> goto fail;
>>>   + ctx->Extensions.ARB_texture_border_clamp = true;
>>> ctx->Extensions.ARB_texture_env_crossbar = true;
>>> ctx->Extensions.ARB_texture_env_combine = true;
>>> ctx->Extensions.ARB_texture_env_dot3 = true;
>>> diff --git a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>>> b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>>> index b0a4c9f..ef1799a 100644
>>> --- a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>>> +++ b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>>> @@ -165,7 +165,8 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
>>> struct nouveau_surface *s;
>>> struct gl_texture_image *ti;
>>> const struct gl_sampler_object *sa;
>>> -   uint32_t tx_format, tx_filter, tx_wrap, tx_enable;
>>> +   uint8_t r, g, b, a;
>>> +   uint32_t tx_format, tx_filter, tx_wrap, tx_bcolor, tx_enable;
>>> PUSH_RESET(push, BUFCTX_TEX(i));
>>>   @@ -201,6 +202,29 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
>>> | nvgl_filter_mode(sa->MinFilter) << 16
>>> | 2 << 12;
>>>   + r = FLOAT_TO_UBYTE(sa->BorderColor.f[0]);
>>> +   g = FLOAT_TO_UBYTE(sa->BorderColor.f[1]);
>>> +   b = FLOAT_TO_UBYTE(sa->BorderColor.f[2]);
>>> +   a = FLOAT_TO_UBYTE(sa->BorderColor.f[3]);
>>> +   switch (ti->_BaseFormat) {
>>> +   case GL_LUMINANCE:
>>> +   a = 0xff;
>>> +   /* fallthrough */
>>> +   case GL_LUMINANCE_ALPHA:
>>> +   g = b = r;
>>> +   break;
>>> +   case GL_RGB:
>>> +   a = 0xff;
>>> +   break;
>>> +   case GL_INTENSITY:
>>> +   g = b = a = r;
>>> +   break;
>>> +   case GL_ALPHA:
>>> +   r = g = b = 0;
>>> +   break;
>>> +   }
>>> +   tx_bcolor = b << 0 | g << 8 | r << 16 | a << 24;
>>> +
>>> tx_enable = NV20_3D_TEX_ENABLE_ENABLE
>>> | log2i(sa->MaxAnisotropy) << 4;
>>>   @@ -249,6 +273,9 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
>>> BEGIN_NV04(push, NV20_3D(TEX_FILTER(i)), 1);
>>> PUSH_DATA (push, tx_filter);
>>>   + BEGIN_NV04(push, NV20_3D(TEX_BORDER_COLOR(i)), 1);
>>> +   PUSH_DATA (push, tx_bcolor);
>>> +
>>> BEGIN_NV04(push, NV20_3D(TEX_ENABLE(i)), 1);
>>> PUSH_DATA (push, tx_enable);
>>>
>>
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0=yHkGaQ69ilDpuXpy1CLI3FvfSzKbL6yQpAZ__QyYIn8=KG6RxFqkzTZFIb4VNTscBHSP1sdVa3hZiGbU4_AKT1A=
>  
> 

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Ilia Mirkin]

On Tue, Jun 27, 2017 at 9:07 AM, Roland Scheidegger  wrote:
> Am 27.06.2017 um 15:01 schrieb Roland Scheidegger:
>> These chips can't do border color? I wonder how they got away with that
>> with d3d since afaik it isn't optional.
> Err, I should have known better, EVERYTHING is optional with d3d9
> (albeit it doesn't mean apps were actually prepared for hw not
> supporting some of the more fundamental caps) "D3DPTADDRESSCAPS_BORDER:
> Device supports setting coordinates outside the range [0.0, 1.0] to the
> border color, as specified by the D3DSAMP_BORDERCOLOR texture-stage
> state." So I suppose that's how they got away with it...

And don't forget the power of swrast fallbacks. None of these chips
support 3D textures, for example.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Roland Scheidegger]

Am 27.06.2017 um 15:01 schrieb Roland Scheidegger:
> These chips can't do border color? I wonder how they got away with that
> with d3d since afaik it isn't optional.
Err, I should have known better, EVERYTHING is optional with d3d9
(albeit it doesn't mean apps were actually prepared for hw not
supporting some of the more fundamental caps) "D3DPTADDRESSCAPS_BORDER:
Device supports setting coordinates outside the range [0.0, 1.0] to the
border color, as specified by the D3DSAMP_BORDERCOLOR texture-stage
state." So I suppose that's how they got away with it...

Roland



> So what happens if you use these border wrap modes? You just get black
> border?
> I suppose another question is if you couldn't announce support for it
> nevertheless. Without a border color, you can't do GL_CLAMP correctly
> neither obviously (albeit that's a mode a few chips have problems with).
> Though unless there's a really good reason to it's probably really not a
> good idea...
> 
> Roland
> 
> Am 27.06.2017 um 13:53 schrieb Ilia Mirkin:
>> This functionality is only available on NV20, NV25, and NV28 (i.e. all
>> the NV2x boards). These are all AGP-only (discounting the NV2A inside
>> Xbox), and I don't have any AGP systems. The way I tested it, through
>> an emulation layer inside the NV3x hardware which lets it present the
>> NV25's 3d class, is fine for initial development, but I don't know how
>> accurate that emulation is to know if this would actually work on real
>> hardware.
>>
>> On Tue, Jun 27, 2017 at 5:59 AM, Timothy Arceri  
>> wrote:
>>> Just curious. Can this extension be added to NV04 and NV10? As those are the
>>> only drivers that don't currently support it.
>>>
>>> I have cards I could test those with, but don't have an NV20.
>>>
>>>
>>>
>>> On 09/09/16 10:56, Ilia Mirkin wrote:
>>>
 Signed-off-by: Ilia Mirkin 
 ---

 This was tested on a NV25-on-NV34 situation. Should be tested on real
 hardware
 since my test environment relies on accurate emulation in the hw.

   src/mesa/drivers/dri/nouveau/nv20_context.c   |  1 +
   src/mesa/drivers/dri/nouveau/nv20_state_tex.c | 29
 ++-
   2 files changed, 29 insertions(+), 1 deletion(-)

 diff --git a/src/mesa/drivers/dri/nouveau/nv20_context.c
 b/src/mesa/drivers/dri/nouveau/nv20_context.c
 index ec638c0..6940b4d 100644
 --- a/src/mesa/drivers/dri/nouveau/nv20_context.c
 +++ b/src/mesa/drivers/dri/nouveau/nv20_context.c
 @@ -456,6 +456,7 @@ nv20_context_create(struct nouveau_screen *screen,
 gl_api api,
 if (!nouveau_context_init(ctx, api, screen, visual, share_ctx))
 goto fail;
   + ctx->Extensions.ARB_texture_border_clamp = true;
 ctx->Extensions.ARB_texture_env_crossbar = true;
 ctx->Extensions.ARB_texture_env_combine = true;
 ctx->Extensions.ARB_texture_env_dot3 = true;
 diff --git a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
 b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
 index b0a4c9f..ef1799a 100644
 --- a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
 +++ b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
 @@ -165,7 +165,8 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
 struct nouveau_surface *s;
 struct gl_texture_image *ti;
 const struct gl_sampler_object *sa;
 -   uint32_t tx_format, tx_filter, tx_wrap, tx_enable;
 +   uint8_t r, g, b, a;
 +   uint32_t tx_format, tx_filter, tx_wrap, tx_bcolor, tx_enable;
 PUSH_RESET(push, BUFCTX_TEX(i));
   @@ -201,6 +202,29 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
 | nvgl_filter_mode(sa->MinFilter) << 16
 | 2 << 12;
   + r = FLOAT_TO_UBYTE(sa->BorderColor.f[0]);
 +   g = FLOAT_TO_UBYTE(sa->BorderColor.f[1]);
 +   b = FLOAT_TO_UBYTE(sa->BorderColor.f[2]);
 +   a = FLOAT_TO_UBYTE(sa->BorderColor.f[3]);
 +   switch (ti->_BaseFormat) {
 +   case GL_LUMINANCE:
 +   a = 0xff;
 +   /* fallthrough */
 +   case GL_LUMINANCE_ALPHA:
 +   g = b = r;
 +   break;
 +   case GL_RGB:
 +   a = 0xff;
 +   break;
 +   case GL_INTENSITY:
 +   g = b = a = r;
 +   break;
 +   case GL_ALPHA:
 +   r = g = b = 0;
 +   break;
 +   }
 +   tx_bcolor = b << 0 | g << 8 | r << 16 | a << 24;
 +
 tx_enable = NV20_3D_TEX_ENABLE_ENABLE
 | log2i(sa->MaxAnisotropy) << 4;
   @@ -249,6 +273,9 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
 BEGIN_NV04(push, NV20_3D(TEX_FILTER(i)), 1);
 PUSH_DATA (push, tx_filter);
   + BEGIN_NV04(push, 

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Ilia Mirkin]

This functionality is only available on NV20, NV25, and NV28 (i.e. all
the NV2x boards). These are all AGP-only (discounting the NV2A inside
Xbox), and I don't have any AGP systems. The way I tested it, through
an emulation layer inside the NV3x hardware which lets it present the
NV25's 3d class, is fine for initial development, but I don't know how
accurate that emulation is to know if this would actually work on real
hardware.

On Tue, Jun 27, 2017 at 5:59 AM, Timothy Arceri  wrote:
> Just curious. Can this extension be added to NV04 and NV10? As those are the
> only drivers that don't currently support it.
>
> I have cards I could test those with, but don't have an NV20.
>
>
>
> On 09/09/16 10:56, Ilia Mirkin wrote:
>
>> Signed-off-by: Ilia Mirkin 
>> ---
>>
>> This was tested on a NV25-on-NV34 situation. Should be tested on real
>> hardware
>> since my test environment relies on accurate emulation in the hw.
>>
>>   src/mesa/drivers/dri/nouveau/nv20_context.c   |  1 +
>>   src/mesa/drivers/dri/nouveau/nv20_state_tex.c | 29
>> ++-
>>   2 files changed, 29 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/nouveau/nv20_context.c
>> b/src/mesa/drivers/dri/nouveau/nv20_context.c
>> index ec638c0..6940b4d 100644
>> --- a/src/mesa/drivers/dri/nouveau/nv20_context.c
>> +++ b/src/mesa/drivers/dri/nouveau/nv20_context.c
>> @@ -456,6 +456,7 @@ nv20_context_create(struct nouveau_screen *screen,
>> gl_api api,
>> if (!nouveau_context_init(ctx, api, screen, visual, share_ctx))
>> goto fail;
>>   + ctx->Extensions.ARB_texture_border_clamp = true;
>> ctx->Extensions.ARB_texture_env_crossbar = true;
>> ctx->Extensions.ARB_texture_env_combine = true;
>> ctx->Extensions.ARB_texture_env_dot3 = true;
>> diff --git a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>> b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>> index b0a4c9f..ef1799a 100644
>> --- a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>> +++ b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
>> @@ -165,7 +165,8 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
>> struct nouveau_surface *s;
>> struct gl_texture_image *ti;
>> const struct gl_sampler_object *sa;
>> -   uint32_t tx_format, tx_filter, tx_wrap, tx_enable;
>> +   uint8_t r, g, b, a;
>> +   uint32_t tx_format, tx_filter, tx_wrap, tx_bcolor, tx_enable;
>> PUSH_RESET(push, BUFCTX_TEX(i));
>>   @@ -201,6 +202,29 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
>> | nvgl_filter_mode(sa->MinFilter) << 16
>> | 2 << 12;
>>   + r = FLOAT_TO_UBYTE(sa->BorderColor.f[0]);
>> +   g = FLOAT_TO_UBYTE(sa->BorderColor.f[1]);
>> +   b = FLOAT_TO_UBYTE(sa->BorderColor.f[2]);
>> +   a = FLOAT_TO_UBYTE(sa->BorderColor.f[3]);
>> +   switch (ti->_BaseFormat) {
>> +   case GL_LUMINANCE:
>> +   a = 0xff;
>> +   /* fallthrough */
>> +   case GL_LUMINANCE_ALPHA:
>> +   g = b = r;
>> +   break;
>> +   case GL_RGB:
>> +   a = 0xff;
>> +   break;
>> +   case GL_INTENSITY:
>> +   g = b = a = r;
>> +   break;
>> +   case GL_ALPHA:
>> +   r = g = b = 0;
>> +   break;
>> +   }
>> +   tx_bcolor = b << 0 | g << 8 | r << 16 | a << 24;
>> +
>> tx_enable = NV20_3D_TEX_ENABLE_ENABLE
>> | log2i(sa->MaxAnisotropy) << 4;
>>   @@ -249,6 +273,9 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
>> BEGIN_NV04(push, NV20_3D(TEX_FILTER(i)), 1);
>> PUSH_DATA (push, tx_filter);
>>   + BEGIN_NV04(push, NV20_3D(TEX_BORDER_COLOR(i)), 1);
>> +   PUSH_DATA (push, tx_bcolor);
>> +
>> BEGIN_NV04(push, NV20_3D(TEX_ENABLE(i)), 1);
>> PUSH_DATA (push, tx_enable);
>>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Timothy Arceri]

Just curious. Can this extension be added to NV04 and NV10? As those are 
the only drivers that don't currently support it.


I have cards I could test those with, but don't have an NV20.


On 09/09/16 10:56, Ilia Mirkin wrote:


Signed-off-by: Ilia Mirkin 
---

This was tested on a NV25-on-NV34 situation. Should be tested on real hardware
since my test environment relies on accurate emulation in the hw.

  src/mesa/drivers/dri/nouveau/nv20_context.c   |  1 +
  src/mesa/drivers/dri/nouveau/nv20_state_tex.c | 29 ++-
  2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/nouveau/nv20_context.c 
b/src/mesa/drivers/dri/nouveau/nv20_context.c
index ec638c0..6940b4d 100644
--- a/src/mesa/drivers/dri/nouveau/nv20_context.c
+++ b/src/mesa/drivers/dri/nouveau/nv20_context.c
@@ -456,6 +456,7 @@ nv20_context_create(struct nouveau_screen *screen, gl_api 
api,
if (!nouveau_context_init(ctx, api, screen, visual, share_ctx))
goto fail;
  
+	ctx->Extensions.ARB_texture_border_clamp = true;

ctx->Extensions.ARB_texture_env_crossbar = true;
ctx->Extensions.ARB_texture_env_combine = true;
ctx->Extensions.ARB_texture_env_dot3 = true;
diff --git a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c 
b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
index b0a4c9f..ef1799a 100644
--- a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
+++ b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
@@ -165,7 +165,8 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
struct nouveau_surface *s;
struct gl_texture_image *ti;
const struct gl_sampler_object *sa;
-   uint32_t tx_format, tx_filter, tx_wrap, tx_enable;
+   uint8_t r, g, b, a;
+   uint32_t tx_format, tx_filter, tx_wrap, tx_bcolor, tx_enable;
  
  	PUSH_RESET(push, BUFCTX_TEX(i));
  
@@ -201,6 +202,29 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)

| nvgl_filter_mode(sa->MinFilter) << 16
| 2 << 12;
  
+	r = FLOAT_TO_UBYTE(sa->BorderColor.f[0]);

+   g = FLOAT_TO_UBYTE(sa->BorderColor.f[1]);
+   b = FLOAT_TO_UBYTE(sa->BorderColor.f[2]);
+   a = FLOAT_TO_UBYTE(sa->BorderColor.f[3]);
+   switch (ti->_BaseFormat) {
+   case GL_LUMINANCE:
+   a = 0xff;
+   /* fallthrough */
+   case GL_LUMINANCE_ALPHA:
+   g = b = r;
+   break;
+   case GL_RGB:
+   a = 0xff;
+   break;
+   case GL_INTENSITY:
+   g = b = a = r;
+   break;
+   case GL_ALPHA:
+   r = g = b = 0;
+   break;
+   }
+   tx_bcolor = b << 0 | g << 8 | r << 16 | a << 24;
+
tx_enable = NV20_3D_TEX_ENABLE_ENABLE
| log2i(sa->MaxAnisotropy) << 4;
  
@@ -249,6 +273,9 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)

BEGIN_NV04(push, NV20_3D(TEX_FILTER(i)), 1);
PUSH_DATA (push, tx_filter);
  
+	BEGIN_NV04(push, NV20_3D(TEX_BORDER_COLOR(i)), 1);

+   PUSH_DATA (push, tx_bcolor);
+
BEGIN_NV04(push, NV20_3D(TEX_ENABLE(i)), 1);
PUSH_DATA (push, tx_enable);
  


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support

[Francisco Jerez]

Ilia Mirkin  writes:

> Signed-off-by: Ilia Mirkin 
> ---
>
> This was tested on a NV25-on-NV34 situation. Should be tested on real hardware
> since my test environment relies on accurate emulation in the hw.
>
Looks okay to me, as long as you get some testing coverage on real
hardware patch is:

Acked-by: Francisco Jerez 

>  src/mesa/drivers/dri/nouveau/nv20_context.c   |  1 +
>  src/mesa/drivers/dri/nouveau/nv20_state_tex.c | 29 
> ++-
>  2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/nouveau/nv20_context.c 
> b/src/mesa/drivers/dri/nouveau/nv20_context.c
> index ec638c0..6940b4d 100644
> --- a/src/mesa/drivers/dri/nouveau/nv20_context.c
> +++ b/src/mesa/drivers/dri/nouveau/nv20_context.c
> @@ -456,6 +456,7 @@ nv20_context_create(struct nouveau_screen *screen, gl_api 
> api,
>   if (!nouveau_context_init(ctx, api, screen, visual, share_ctx))
>   goto fail;
>  
> + ctx->Extensions.ARB_texture_border_clamp = true;
>   ctx->Extensions.ARB_texture_env_crossbar = true;
>   ctx->Extensions.ARB_texture_env_combine = true;
>   ctx->Extensions.ARB_texture_env_dot3 = true;
> diff --git a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c 
> b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
> index b0a4c9f..ef1799a 100644
> --- a/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
> +++ b/src/mesa/drivers/dri/nouveau/nv20_state_tex.c
> @@ -165,7 +165,8 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
>   struct nouveau_surface *s;
>   struct gl_texture_image *ti;
>   const struct gl_sampler_object *sa;
> - uint32_t tx_format, tx_filter, tx_wrap, tx_enable;
> + uint8_t r, g, b, a;
> + uint32_t tx_format, tx_filter, tx_wrap, tx_bcolor, tx_enable;
>  
>   PUSH_RESET(push, BUFCTX_TEX(i));
>  
> @@ -201,6 +202,29 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
>   | nvgl_filter_mode(sa->MinFilter) << 16
>   | 2 << 12;
>  
> + r = FLOAT_TO_UBYTE(sa->BorderColor.f[0]);
> + g = FLOAT_TO_UBYTE(sa->BorderColor.f[1]);
> + b = FLOAT_TO_UBYTE(sa->BorderColor.f[2]);
> + a = FLOAT_TO_UBYTE(sa->BorderColor.f[3]);
> + switch (ti->_BaseFormat) {
> + case GL_LUMINANCE:
> + a = 0xff;
> + /* fallthrough */
> + case GL_LUMINANCE_ALPHA:
> + g = b = r;
> + break;
> + case GL_RGB:
> + a = 0xff;
> + break;
> + case GL_INTENSITY:
> + g = b = a = r;
> + break;
> + case GL_ALPHA:
> + r = g = b = 0;
> + break;
> + }
> + tx_bcolor = b << 0 | g << 8 | r << 16 | a << 24;
> +
>   tx_enable = NV20_3D_TEX_ENABLE_ENABLE
>   | log2i(sa->MaxAnisotropy) << 4;
>  
> @@ -249,6 +273,9 @@ nv20_emit_tex_obj(struct gl_context *ctx, int emit)
>   BEGIN_NV04(push, NV20_3D(TEX_FILTER(i)), 1);
>   PUSH_DATA (push, tx_filter);
>  
> + BEGIN_NV04(push, NV20_3D(TEX_BORDER_COLOR(i)), 1);
> + PUSH_DATA (push, tx_bcolor);
> +
>   BEGIN_NV04(push, NV20_3D(TEX_ENABLE(i)), 1);
>   PUSH_DATA (push, tx_enable);
>  
> -- 
> 2.7.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev