Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support
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
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
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
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
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
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
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
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&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0&m=yHkGaQ69ilDpuXpy1CLI3FvfSzKbL6yQpAZ__QyYIn8&s=KG6RxFqkzTZFIb4VNTscBHSP1sdVa3hZiGbU4_AKT1A&e= > > ___ mesa-dev mail
Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support
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
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, NV20_3D(TEX_BORDER_COLOR(i)), 1); + PUSH_DATA (push, tx_b
Re: [Mesa-dev] [RFT PATCH 2/2] nv20: enable ARB_texture_border_clamp support
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
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
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