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 <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?
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
