[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 <idr at freedesktop.org> 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