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
