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 <i...@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?

Roland

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

Reply via email to