From: Andreas S. <A.S...@gm...> - 2003-05-29 23:38:02
Attachments:
nv_rectangle.patch
|
I copied together (from r200 driver) a patch which enables GL_NV_texture_rectangle on radeon. The yuvrect.c test from mesa seems to work, but texrect.c doesnt. strange. Other issues: 1) radeonEmitBlit uses an already shifted color_fmt, which is defined in radeon_reg.h, r200EmitBlit uses an unshifted color_fmt which is defined in r200_reg.h. -> should we shift back and forth in the radeon-driver to match the r200-driver? 2) I just included radeonEmitBlit and radeonEmitWait in radeon_ioctl.c, the r200-driver has a separate file r200_cmdbuf.c for them. 3) which drmMinor is needed to support the new cmd-packets? 4) no AGP-texturing Any hints? greetings, Andreas |
From: Andreas S. <A.S...@gm...> - 2003-05-31 11:42:43
|
I think I missed some lines in file radeon_texstate.c function import_tex_obj_state() =2E.. cmd[TEX_PP_TXSIZE] =3D texobj->pp_txsize; /* NPOT only! */ cmd[TEX_PP_TXPITCH] =3D texobj->pp_txpitch; /* NPOT only! */ =2E.. unfortunately it isnt possible to just copy from r200 ;) since the registers are on different places (relative to RADEON_PP_TXFORMAT_0) when you substitute R200_PP_TXSIZE_0 -> RADEON_PP_TEX_SIZE_0 . I cant find an equivalent for R200_PP_TXPITCH_0 in the radeon registers, maybe its between RADEON_PP_TEX_SIZE_0 and RADEON_PP_TEX_SIZE_1 ? Or is handling of NPOT textures completely different on radeon? best regards, Andreas Am 2003.05.30 00:56:42 +0200 schrieb(en) Andreas Stenglein: > I copied together (from r200 driver) > a patch which enables GL_NV_texture_rectangle > on radeon. >=20 > The yuvrect.c test from mesa seems to work, > but texrect.c doesnt. strange. >=20 > Other issues: > 1) radeonEmitBlit uses an already shifted > color_fmt, which is defined in radeon_reg.h, > r200EmitBlit uses an unshifted color_fmt > which is defined in r200_reg.h. > -> should we shift back and forth in the > radeon-driver to match the r200-driver? >=20 > 2) I just included radeonEmitBlit and radeonEmitWait > in radeon_ioctl.c, the r200-driver has a separate file > r200_cmdbuf.c for them. >=20 > 3) which drmMinor is needed to support the > new cmd-packets? >=20 > 4) no AGP-texturing >=20 > Any hints? >=20 > greetings, > Andreas |
From: Andreas S. <A.S...@gm...> - 2003-06-07 18:18:19
Attachments:
rectangle5.diff
|
@keithw: here is another version. yuvrect.c seems to work texrect.c still doesnt work any hints? greetings, Andreas |
From: Keith W. <ke...@tu...> - 2003-06-09 16:04:19
|
Andreas Stenglein wrote: > @keithw: here is another version. > > yuvrect.c seems to work > texrect.c still doesnt work > Andreas, Applied this today & had a brief look. I needed to bump the version number in shared/drm/radeon.h to 1.9.0 before the extensions were enabled. Maybe this got missed from the diff? What problems are you having with texrect.c? I get: texrect: radeon_ioctl.c:414: radeonEmitBlit: Assertion `(src_offset & 1023) == 0' failed. Is this the same as you're seeing? Keith |
From: Andreas S. <A.S...@gm...> - 2003-06-09 19:10:39
|
hello, Am 2003.06.09 18:05:35 +0200 schrieb(en) Keith Whitwell: >=20 > Andreas, >=20 > Applied this today & had a brief look. >=20 > I needed to bump the version number in shared/drm/radeon.h to 1.9.0=20 > before the extensions were enabled. Maybe this got missed from the=20 > diff? I didn't want to bump the version before the packets for cubemap-texturing are in place... so I just added a check for >=3D 1.9.0 OR getenv( "RADEON_RECTANGLE_FORCE_ENABLE") >=20 > What problems are you having with texrect.c? I get: >=20 > texrect: radeon_ioctl.c:414: radeonEmitBlit: Assertion `(src_offset=20 > & 1023) =3D=3D 0' failed. >=20 > Is this the same as you're seeing? No, I dont get the assertion. It "just doesnt work as expected": I get white textures with grey/black points/lines. If I disable/comment out the radeonEmitBlit(), it looks the same, so maybe the blit doesnt work? On the other hand the assertion you get shouldn't occur, so it looks like I missed something. The strange part is, that yuvrect (at least seems to) work(s) well. yuvrect even worked without the additional txsize/txpitch packet. And yuvrect works when RADEON_AGPTEXTURING_FORCE_DISABLE=3D1. >=20 > Keith >=20 thanks for having a look at the patch greetings, Andreas PS: here's the begin of some output I get when running texrect, with RADEON_DEBUG=3Dioctl (unfortunately it sometimes hangs the Xserver until I kill texrect) as@buche:~/PRJ/MESA-CVS/build/tests> ./texrect 2 texture units=20 supported, using 2. 2048 x 2048 max texture rectangle size Texture 0: ../images/girl.rgb (194 x 188) Texture 1: ../images/reflect.rgb (128 x 128) radeonClear: all=3D1 cx=3D0 cy=3D0 cw=3D300 ch=3D300 radeonEmitState - lost context radeonFlush radeonFlushCmdBufLocked from radeonFlush radeonClear( 385855 ) radeonUploadTexImages( 0x805df78, 0x8142210 ) sz=3D156672 lvls=3D0-0 radeonAllocDmaRegion 64896 radeonRefillCurrentDmaRegion radeonEmitBlit src 340/4182000 0,0 dst: 340/3300000 0,0 sz: 194x78 radeonReleaseDmaRegion from radeonUploadRectSubImage radeonAllocDmaRegion 64896 radeonRefillCurrentDmaRegion radeonReleaseDmaRegion from radeonRefillCurrentDmaRegion radeonReleaseDmaRegion -- DISCARD BUF 8 radeonEmitBlit src 340/4192000 0,0 dst: 340/3300000 0,78 sz: 194x78 radeonReleaseDmaRegion from radeonUploadRectSubImage radeonAllocDmaRegion 26624 radeonRefillCurrentDmaRegion radeonReleaseDmaRegion from radeonRefillCurrentDmaRegion radeonReleaseDmaRegion -- DISCARD BUF 9 radeonEmitBlit src 340/41a2000 0,0 dst: 340/3300000 0,156 sz: 194x32 radeonReleaseDmaRegion from radeonUploadRectSubImage radeonFlush radeonEmitState - lost context radeonFlushCmdBufLocked from radeonFlush radeonUploadTexImages( 0x805df78, 0x81423f0 ) sz=3D65536 lvls=3D0-0 radeonAllocDmaRegion 65536 radeonRefillCurrentDmaRegion radeonReleaseDmaRegion from radeonRefillCurrentDmaRegion radeonReleaseDmaRegion -- DISCARD BUF 10 radeonEmitBlit src 200/41b2000 0,0 dst: 200/3327000 0,0 sz: 128x128 radeonReleaseDmaRegion from radeonUploadRectSubImage radeonRefillCurrentDmaRegion radeonReleaseDmaRegion from radeonRefillCurrentDmaRegion radeonReleaseDmaRegion -- DISCARD BUF 11 radeonAllocEltsOpenEnded 6 radeonEmitState - lost context radeonReleaseDmaRegion from flush_prims radeonFlushElts =2E..... |
From: Keith W. <ke...@tu...> - 2003-06-09 21:18:11
|
Andreas Stenglein wrote: > hello, > > Am 2003.06.09 18:05:35 +0200 schrieb(en) Keith Whitwell: > >> >> Andreas, >> >> Applied this today & had a brief look. >> >> I needed to bump the version number in shared/drm/radeon.h to 1.9.0 >> before the extensions were enabled. Maybe this got missed from the diff? > > I didn't want to bump the version before the packets for > cubemap-texturing are in place... so I just added a check > for >= 1.9.0 OR getenv( "RADEON_RECTANGLE_FORCE_ENABLE") > >> >> What problems are you having with texrect.c? I get: >> >> texrect: radeon_ioctl.c:414: radeonEmitBlit: Assertion `(src_offset & >> 1023) == 0' failed. >> >> Is this the same as you're seeing? > > No, I dont get the assertion. It "just doesnt work as expected": > I get white textures with grey/black points/lines. > If I disable/comment out the radeonEmitBlit(), it looks > the same, so maybe the blit doesnt work? > On the other hand the assertion you get shouldn't occur, so > it looks like I missed something. > > The strange part is, that yuvrect (at least seems to) work(s) well. > yuvrect even worked without the additional txsize/txpitch packet. > And yuvrect works when RADEON_AGPTEXTURING_FORCE_DISABLE=1. > >> >> Keith >> > thanks for having a look at the patch > > greetings, > Andreas > > PS: here's the begin of some output I get > when running texrect, with RADEON_DEBUG=ioctl > (unfortunately it sometimes hangs the Xserver until > I kill texrect) I've been playing a bit more -- it's kind of odd what works & doesn't... I haven't really got a handle on it yet... Keith |
From: Andreas S. <A.S...@gm...> - 2003-06-09 21:37:55
|
Am 2003.06.09 23:19:16 +0200 schrieb(en) Keith Whitwell: > [...] >=20 > I've been playing a bit more -- it's kind of odd what works &=20 > doesn't... I haven't really got a handle on it yet... >=20 > Keith I modified yuvrect so that it uploads an rgb-image, ("rgbrect") result (as expected): doesnt work. btw: its #dri-devel meeting time best regards, Andreas |
From: Keith W. <ke...@tu...> - 2003-06-09 23:19:37
Attachments:
radeon-yuv-env.diff
|
Keith Whitwell wrote: > Andreas Stenglein wrote: > >> hello, >> >> Am 2003.06.09 18:05:35 +0200 schrieb(en) Keith Whitwell: >> >>> >>> Andreas, >>> >>> Applied this today & had a brief look. >>> >>> I needed to bump the version number in shared/drm/radeon.h to 1.9.0 >>> before the extensions were enabled. Maybe this got missed from the >>> diff? >> >> >> I didn't want to bump the version before the packets for >> cubemap-texturing are in place... so I just added a check >> for >= 1.9.0 OR getenv( "RADEON_RECTANGLE_FORCE_ENABLE") >> >>> >>> What problems are you having with texrect.c? I get: >>> >>> texrect: radeon_ioctl.c:414: radeonEmitBlit: Assertion `(src_offset & >>> 1023) == 0' failed. >>> >>> Is this the same as you're seeing? >> >> >> No, I dont get the assertion. It "just doesnt work as expected": >> I get white textures with grey/black points/lines. >> If I disable/comment out the radeonEmitBlit(), it looks >> the same, so maybe the blit doesnt work? >> On the other hand the assertion you get shouldn't occur, so >> it looks like I missed something. >> >> The strange part is, that yuvrect (at least seems to) work(s) well. >> yuvrect even worked without the additional txsize/txpitch packet. >> And yuvrect works when RADEON_AGPTEXTURING_FORCE_DISABLE=1. >> >>> >>> Keith >>> >> thanks for having a look at the patch >> >> greetings, >> Andreas >> >> PS: here's the begin of some output I get >> when running texrect, with RADEON_DEBUG=ioctl >> (unfortunately it sometimes hangs the Xserver until >> I kill texrect) > > > I've been playing a bit more -- it's kind of odd what works & > doesn't... I haven't really got a handle on it yet... OK, at least I know why the yuv code appeared to sortof work: it was hitting a fallback path and reverting to software rendering. Basically some code is missing for yuv support in radeonUpdateTextureEnv(). The attached patch includes the missing code. Now at least everything doesn't work. I still seem to get upload blits landing in the backbuffer on occasion. Keith Keith |
From: Keith W. <ke...@tu...> - 2003-06-09 23:42:39
Attachments:
radeon_sanity_npot.diff
|
Andreas Stenglein wrote: > @keithw: here is another version. > > yuvrect.c seems to work > texrect.c still doesnt work > > any hints? I find the radeon_sanity.c output very helpful when things just arent working. Here's a patch to bring it uptodate with your changes. If you run it, you'll see that the hardware just isn't being told anything about these textures, so its no suprise that it doesn't display them properly. Keith |
From: Keith W. <ke...@tu...> - 2003-06-09 23:51:42
|
Keith Whitwell wrote: > Andreas Stenglein wrote: > >> @keithw: here is another version. >> >> yuvrect.c seems to work >> texrect.c still doesnt work >> >> any hints? > > > I find the radeon_sanity.c output very helpful when things just arent > working. Here's a patch to bring it uptodate with your changes. If you > run it, you'll see that the hardware just isn't being told anything > about these textures, so its no suprise that it doesn't display them > properly. OK, the reason for this is just a typo in import_tex_obj_state(): line 1286 should read: RADEON_DB_STATECHANGE( rmesa, &rmesa->hw.txr[unit] ); Keith |
From: Keith W. <ke...@tu...> - 2003-06-10 10:13:12
|
Keith Whitwell wrote: > Andreas Stenglein wrote: > >> @keithw: here is another version. >> >> yuvrect.c seems to work >> texrect.c still doesnt work >> >> any hints? > OK, the final piece of the puzzle fell into place. Without the radeon docs you might hav had trouble find this -- basically, the radeon still expects texture rectangle texcoords to be in 0..1 range, rather than 0..width,0..height like the r200. I haven't got the code running for this yet, but modifying the app to supply the texcoords the hardware expects gives a good image. Keith |
From: Andreas S. <A.S...@gm...> - 2003-06-10 11:22:29
|
Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell: > Keith Whitwell wrote: >> Andreas Stenglein wrote: >>=20 >>> @keithw: here is another version. >>>=20 >>> yuvrect.c seems to work >>> texrect.c still doesnt work >>>=20 >>> any hints? >>=20 >=20 > OK, the final piece of the puzzle fell into place. Without the=20 > radeon docs you might hav had trouble find this -- basically, the=20 > radeon still expects texture rectangle texcoords to be in 0..1=20 > range, rather than 0..width,0..height like the r200. >=20 > I haven't got the code running for this yet, but modifying the app=20 > to supply the texcoords the hardware expects gives a good image. >=20 > Keith >=20 yes, its unbelievable... it works with texcoords 0...1 ;) 1) Do you have an idea how to make it work with the right texcoords? 2) Since the default bordermode GL_REPEAT doesnt work/isnt allowed with npot textures, should there something be done about that? 3) in radeon_ioctl.c, function radeonEmitVbufPrim() the first cmd is cleared before filled with the cmd_type: cmd[0].i =3D 0; cmd[0].header.cmd_type =3D RADEON_CMD_PACKET3_CLIP; .... should this be done in radeonEmitBlit() also or is that not necessary? 4) I missed a line in radeon_context.c: driCalculateMaxTextureLevels( rmesa->texture_heaps, rmesa->nr_heaps, & ctx->Const, 4, 11, /* max 2D texture size is=20 2048x2048 */ 0, /* 3D textures unsupported. */ 0, /* cube textures unsupported. */ =3D=3D=3D> 11, /* max texture rectangle size is=20 2048x2048 */ 12, GL_FALSE ); regards, Andreas |
From: Keith W. <ke...@tu...> - 2003-06-10 11:14:40
|
Andreas Stenglein wrote: > Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell: > >> Keith Whitwell wrote: >> >>> Andreas Stenglein wrote: >>> >>>> @keithw: here is another version. >>>> >>>> yuvrect.c seems to work >>>> texrect.c still doesnt work >>>> >>>> any hints? >>> >>> >> >> OK, the final piece of the puzzle fell into place. Without the radeon >> docs you might hav had trouble find this -- basically, the radeon >> still expects texture rectangle texcoords to be in 0..1 range, rather >> than 0..width,0..height like the r200. >> >> I haven't got the code running for this yet, but modifying the app to >> supply the texcoords the hardware expects gives a good image. >> >> Keith >> > yes, its unbelievable... it works with texcoords 0...1 ;) > > 1) Do you have an idea how to make it work with the right texcoords? I was thinking that this would be a fairly easy option: a) Disable TCL for all rectangular texture operations b) Insert a new stage to the swtcl pipeline, based on Mesa/src/tnl/t_vb_texmat.c, to perform a 1/w, 1/h scale to all texrect coordinates. I can send you some unfinished code for this, if you want. > 2) Since the default bordermode GL_REPEAT doesnt work/isnt allowed > with npot textures, should there something be done about that? Probably... > 3) in radeon_ioctl.c, function radeonEmitVbufPrim() > the first cmd is cleared before filled with the cmd_type: > cmd[0].i = 0; > cmd[0].header.cmd_type = RADEON_CMD_PACKET3_CLIP; > .... > should this be done in radeonEmitBlit() also or > is that not necessary? Quite possibly it should. > > 4) I missed a line in radeon_context.c: > driCalculateMaxTextureLevels( rmesa->texture_heaps, > rmesa->nr_heaps, > & ctx->Const, > 4, > 11, /* max 2D texture size is 2048x2048 */ > 0, /* 3D textures unsupported. */ > 0, /* cube textures unsupported. */ > ===> 11, /* max texture rectangle size is 2048x2048 */ > 12, > GL_FALSE ); > Looks good, too. Keith |
From: Brian P. <br...@tu...> - 2003-06-10 11:45:10
|
Keith Whitwell wrote: > Andreas Stenglein wrote: > >> Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell: >> >>> Keith Whitwell wrote: >>> >>>> Andreas Stenglein wrote: >>>> >>>>> @keithw: here is another version. >>>>> >>>>> yuvrect.c seems to work >>>>> texrect.c still doesnt work >>>>> >>>>> any hints? >>>> >>>> >>>> >>> >>> OK, the final piece of the puzzle fell into place. Without the >>> radeon docs you might hav had trouble find this -- basically, the >>> radeon still expects texture rectangle texcoords to be in 0..1 range, >>> rather than 0..width,0..height like the r200. >>> >>> I haven't got the code running for this yet, but modifying the app to >>> supply the texcoords the hardware expects gives a good image. >>> >>> Keith >>> >> yes, its unbelievable... it works with texcoords 0...1 ;) >> >> 1) Do you have an idea how to make it work with the right texcoords? > > > I was thinking that this would be a fairly easy option: > > a) Disable TCL for all rectangular texture operations > b) Insert a new stage to the swtcl pipeline, based on > Mesa/src/tnl/t_vb_texmat.c, to perform a 1/w, 1/h scale to all texrect > coordinates. c) premultiply the texture matrix by a scaling matrix? -Brian |
From: Keith W. <ke...@tu...> - 2003-06-10 12:53:23
|
Brian Paul wrote: > Keith Whitwell wrote: > >> Andreas Stenglein wrote: >> >>> Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell: >>> >>>> Keith Whitwell wrote: >>>> >>>>> Andreas Stenglein wrote: >>>>> >>>>>> @keithw: here is another version. >>>>>> >>>>>> yuvrect.c seems to work >>>>>> texrect.c still doesnt work >>>>>> >>>>>> any hints? >>>>> >>>>> >>>>> >>>>> >>>> >>>> OK, the final piece of the puzzle fell into place. Without the >>>> radeon docs you might hav had trouble find this -- basically, the >>>> radeon still expects texture rectangle texcoords to be in 0..1 >>>> range, rather than 0..width,0..height like the r200. >>>> >>>> I haven't got the code running for this yet, but modifying the app >>>> to supply the texcoords the hardware expects gives a good image. >>>> >>>> Keith >>>> >>> yes, its unbelievable... it works with texcoords 0...1 ;) >>> >>> 1) Do you have an idea how to make it work with the right texcoords? >> >> >> >> I was thinking that this would be a fairly easy option: >> >> a) Disable TCL for all rectangular texture operations >> b) Insert a new stage to the swtcl pipeline, based on >> Mesa/src/tnl/t_vb_texmat.c, to perform a 1/w, 1/h scale to all texrect >> coordinates. > > > c) premultiply the texture matrix by a scaling matrix? I wanted to keep things seperate -- but it does sound nice. It would need some new infrastructure - if it were to work with tcl fallbacks, then t_vb_texmat.c would have to use a premultiplied one also. Further, swrast expects "normal" 0..dimension texcoords, so it would have to be turned off during rasterization fallbacks. It seems like it would require hooks into core mesa, just to deal with this one piece of hardware that works this way. Adding a new renderstage keeps it in the driver. I could add a new renderstage *and* premultiply only the hw texture matrix (keeping hwtcl), but that's even more work. Keith |
From: Keith W. <ke...@tu...> - 2003-06-10 15:40:19
Attachments:
rectangle-kw-1.diff
|
Keith Whitwell wrote: > Brian Paul wrote: > >> Keith Whitwell wrote: >> >>> Andreas Stenglein wrote: >>> >>>> Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell: >>>> >>>>> Keith Whitwell wrote: >>>>> >>>>>> Andreas Stenglein wrote: >>>>>> >>>>>>> @keithw: here is another version. >>>>>>> >>>>>>> yuvrect.c seems to work >>>>>>> texrect.c still doesnt work >>>>>>> >>>>>>> any hints? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> OK, the final piece of the puzzle fell into place. Without the >>>>> radeon docs you might hav had trouble find this -- basically, the >>>>> radeon still expects texture rectangle texcoords to be in 0..1 >>>>> range, rather than 0..width,0..height like the r200. >>>>> >>>>> I haven't got the code running for this yet, but modifying the app >>>>> to supply the texcoords the hardware expects gives a good image. >>>>> >>>>> Keith >>>>> >>>> yes, its unbelievable... it works with texcoords 0...1 ;) >>>> >>>> 1) Do you have an idea how to make it work with the right texcoords? >>> >>> >>> >>> >>> I was thinking that this would be a fairly easy option: >>> >>> a) Disable TCL for all rectangular texture operations >>> b) Insert a new stage to the swtcl pipeline, based on >>> Mesa/src/tnl/t_vb_texmat.c, to perform a 1/w, 1/h scale to all >>> texrect coordinates. >> >> >> >> c) premultiply the texture matrix by a scaling matrix? > > > I wanted to keep things seperate -- but it does sound nice. It would > need some new infrastructure - if it were to work with tcl fallbacks, > then t_vb_texmat.c would have to use a premultiplied one also. Further, > swrast expects "normal" 0..dimension texcoords, so it would have to be > turned off during rasterization fallbacks. > > It seems like it would require hooks into core mesa, just to deal with > this one piece of hardware that works this way. Adding a new > renderstage keeps it in the driver. > > I could add a new renderstage *and* premultiply only the hw texture > matrix (keeping hwtcl), but that's even more work. Here's a patch that mainly works. I've still seen the odd case of the texture apparently getting uploaded to the backbuffer. Keith |
From: Andreas S. <A.S...@gm...> - 2003-06-13 13:12:26
Attachments:
mplayer_nvtexrect_patch2.txt
|
while trying to activate the 3rd TMU on radeon I discovered that "txr" states get emitted even in the yuvsqare (and multiarb) demo (which use only standard textures): (RADEON_DEBUG=3Dstate and yuvsqare demo:) =2E... radeonBindTexture( 0x8132dc8 ) unit=3D0 radeonEmitState radeonEmitState - lost context emit TEX/tex-0/9 emit CTX/context/14 skip state TXR/txr-2 skip state TXR/txr-1 skip state TEX/tex-2 skip state TEX/tex-1 emit ZBS/zbias/3 emit MSC/misc/2 emit VPT/viewport/7 emit TXR/txr-0/3 emit MSK/mask/4 emit LIN/line/5 emit SET/setup/5 =2E... I dont know if its bad, but I think it shouldnt happen. I changed the CHECK in radeon_state_init.c for txr and now it doesnt happen anymore, at least in yuvsquare. radeon_state_init.c:CHECK( txr0, ctx->Texture.Unit[0]._ReallyEnabled=20 & TEXTURE_RECT_BIT) radeon_state_init.c:CHECK( txr1, ctx->Texture.Unit[1]._ReallyEnabled=20 & TEXTURE_RECT_BIT) btw. heres also a patch for mplayer vo_gl.c which uses=20 GL_NV_texture_rectangle. I sent a (sligtly) older version to mplayer-dev-eng, but=20 unfortunately it got caught by some filter/ wasnt released by the mailinglist=20 moderator. best regards, Andreas Am 2003.06.10 17:40:05 +0200 schrieb(en) Keith Whitwell: [.......] >=20 > Here's a patch that mainly works. I've still seen the odd case of=20 > the texture apparently getting uploaded to the backbuffer. >=20 > Keith [...] > RCS file:=20 > /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_state_init.c,v > retrieving revision 1.10 > diff -u -r1.10 radeon_state_init.c > --- radeon_state_init.c 30 Apr 2003 01:50:54 > -0000 1.10 > +++ radeon_state_init.c 10 Jun 2003 15:37:50 -0000 > @@ -134,6 +134,9 @@ > TCL_CHECK( tcl_ucp5, (ctx->Transform.ClipPlanesEnabled & 0x20) ) > TCL_CHECK( tcl_eyespace_or_fog, ctx->_NeedEyeCoords || > ctx->Fog.Enabled ) >=20 > +CHECK( txr0, ctx->Texture.Unit[0]._ReallyEnabled ) > +CHECK( txr1, ctx->Texture.Unit[1]._ReallyEnabled ) > + >=20 >=20 > /* Initialize the context's hardware state. > @@ -246,6 +249,8 @@ > ALLOC_STATE( lit[5], tcl_lit5, LIT_STATE_SIZE, "LIT/light-5", 1 > ); > ALLOC_STATE( lit[6], tcl_lit6, LIT_STATE_SIZE, "LIT/light-6", 1 > ); > ALLOC_STATE( lit[7], tcl_lit7, LIT_STATE_SIZE, "LIT/light-7", 1 > ); > + ALLOC_STATE( txr[0], txr0, TXR_STATE_SIZE, "TXR/txr-0", 0 ); > + ALLOC_STATE( txr[1], txr1, TXR_STATE_SIZE, "TXR/txr-1", 0 ); >=20 >=20 > /* Fill in the packet headers: > @@ -268,6 +273,8 @@ > rmesa->hw.tcl.cmd[TCL_CMD_0] =3D > cmdpkt(RADEON_EMIT_SE_TCL_OUTPUT_VTX_FMT); > rmesa->hw.mtl.cmd[MTL_CMD_0] =3D > cmdpkt(RADEON_EMIT_SE_TCL_MATERIAL_EMMISSIVE_RED); > + rmesa->hw.txr[0].cmd[TXR_CMD_0] =3D > cmdpkt(RADEON_EMIT_PP_TEX_SIZE_0); > + rmesa->hw.txr[1].cmd[TXR_CMD_0] =3D > cmdpkt(RADEON_EMIT_PP_TEX_SIZE_1); > rmesa->hw.grd.cmd[GRD_CMD_0] =3D > cmdscl( RADEON_SS_VERT_GUARD_CLIP_ADJ_ADDR, 1, 4 ); > rmesa->hw.fog.cmd[FOG_CMD_0] =3D [...] |
From: Keith W. <ke...@tu...> - 2003-06-13 15:00:42
|
Andreas Stenglein wrote: > while trying to activate the 3rd TMU on radeon > I discovered that "txr" states get emitted even > in the yuvsqare (and multiarb) demo > (which use only standard textures): > (RADEON_DEBUG=state and yuvsqare demo:) > .... > radeonBindTexture( 0x8132dc8 ) unit=0 > radeonEmitState > radeonEmitState - lost context > emit TEX/tex-0/9 > emit CTX/context/14 > skip state TXR/txr-2 > skip state TXR/txr-1 > skip state TEX/tex-2 > skip state TEX/tex-1 > emit ZBS/zbias/3 > emit MSC/misc/2 > emit VPT/viewport/7 > emit TXR/txr-0/3 > emit MSK/mask/4 > emit LIN/line/5 > emit SET/setup/5 > .... > I dont know if its bad, but I think it shouldnt happen. > > I changed the CHECK in radeon_state_init.c for txr and > now it doesnt happen anymore, at least in yuvsquare. > radeon_state_init.c:CHECK( txr0, ctx->Texture.Unit[0]._ReallyEnabled & > TEXTURE_RECT_BIT) > radeon_state_init.c:CHECK( txr1, ctx->Texture.Unit[1]._ReallyEnabled & > TEXTURE_RECT_BIT) > > > btw. heres also a patch for mplayer vo_gl.c which uses > GL_NV_texture_rectangle. > I sent a (sligtly) older version to mplayer-dev-eng, but unfortunately it > got caught by some filter/ wasnt released by the mailinglist moderator. > Interesting. The two other extensions I'd consider useful for this are MESA_ycbcr_texture (yuv textures) and the agp allocator/agp client texturing present in the r200 driver. Does mplayer produce data in a format useable as a ycbcr texture? Keith |
From: Andreas S. <A.S...@gm...> - 2003-06-13 15:41:32
|
Am 2003.06.13 17:00:20 +0200 schrieb(en) Keith Whitwell: > Andreas Stenglein wrote: [...] >>=20 >> btw. heres also a patch for mplayer vo_gl.c which uses=20 >> GL_NV_texture_rectangle. >> I sent a (sligtly) older version to mplayer-dev-eng, but=20 >> unfortunately it >> got caught by some filter/ wasnt released by the mailinglist=20 >> moderator. >>=20 >=20 > Interesting. The two other extensions I'd consider useful for this=20 > are MESA_ycbcr_texture (yuv textures) and the agp allocator/agp=20 > client texturing present in the r200 driver. Does mplayer produce=20 > data in a format useable as a ycbcr texture? >=20 > Keith >=20 Yes, this would nice. I think the output format of most codecs is YV12, so a YV12 -> YUY2 (packed) converter would be needed. And if the extension is available, mplayer should get told that it can pass YV12 and YUY2 output directly to the vo_gl driver. greetings, Andreas (PS: I'm away over the weekend) |
From: Ian R. <id...@us...> - 2003-06-26 03:45:47
|
Keith Whitwell wrote: > Here's a patch that mainly works. I've still seen the odd case of the > texture apparently getting uploaded to the backbuffer. ...but *only* if you have a kernel module installed that understands rectangle state. As it is, the code in radeon_state_init.c allows texture rectangle state to be emitted even if the DRM cannot handle the RADEON_PP_TEX_SIZE_? packets. The result is an immediate "drmCommandWrite: -22" for any GL program. :( I copied over the test from radeon_context.c to the two places in radeon_state_init.c that set-up the state atoms, but that's not a very pretty sollution. I only noticed this because when I try to insmod the new radeon.o, it fails on an undefined symbol "mmu_cr4_features". The wierd part is that /boot/System.map-2.4.21-rc2-ac2 shows it as being in global BSS ("c02ccd0c B mmu_cr4_features"), *but* /proc/ksyms doesn't show it. I don't get it. |
From: Keith W. <ke...@tu...> - 2003-06-26 08:34:40
|
Ian Romanick wrote: > Keith Whitwell wrote: > >> Here's a patch that mainly works. I've still seen the odd case of the >> texture apparently getting uploaded to the backbuffer. > > > ...but *only* if you have a kernel module installed that understands > rectangle state. As it is, the code in radeon_state_init.c allows > texture rectangle state to be emitted even if the DRM cannot handle the > RADEON_PP_TEX_SIZE_? packets. The result is an immediate > "drmCommandWrite: -22" for any GL program. :( I copied over the test > from radeon_context.c to the two places in radeon_state_init.c that > set-up the state atoms, but that's not a very pretty sollution. OK, my bad -- I'll fix this up. Keith > |
From: Ian R. <id...@us...> - 2003-06-26 15:47:14
Attachments:
ksyms.patch
|
Ian Romanick wrote: > I only noticed this because when I try to insmod the new radeon.o, it > fails on an undefined symbol "mmu_cr4_features". The wierd part is that > /boot/System.map-2.4.21-rc2-ac2 shows it as being in global BSS > ("c02ccd0c B mmu_cr4_features"), *but* /proc/ksyms doesn't show it. I > don't get it. I upgraded to 2.4.21-ac3, but I kept getting the same problem. To work around it, I had to apply the following patch. Alan, any chance of getting this in -ac4? :) |
From: Andreas S. <A.S...@gm...> - 2003-06-10 11:56:51
|
Am 2003.06.10 13:14:28 +0200 schrieb(en) Keith Whitwell: > [...] >=20 > I was thinking that this would be a fairly easy option: >=20 > a) Disable TCL for all rectangular texture operations > b) Insert a new stage to the swtcl pipeline, based on=20 > Mesa/src/tnl/t_vb_texmat.c, to perform a 1/w, 1/h scale to all=20 > texrect coordinates. >=20 > I can send you some unfinished code for this, if you want. >=20 > [..] Maybe I could try, but unfortunately not before tomorrow. best regards, Andreas |
From: Michel <mi...@da...> - 2003-06-12 21:00:52
|
On Tue, 2003-06-10 at 13:14, Keith Whitwell wrote: > Andreas Stenglein wrote: > > > > 3) in radeon_ioctl.c, function radeonEmitVbufPrim() > > the first cmd is cleared before filled with the cmd_type: > > cmd[0].i = 0; > > cmd[0].header.cmd_type = RADEON_CMD_PACKET3_CLIP; > > .... > > should this be done in radeonEmitBlit() also or > > is that not necessary? > > Quite possibly it should. Definitely a good idea, or the other header fields may have random contents. Actually, why not clear the header in AllocCmdBuf() instead of in the callers? While it may be cleared unnecessarily sometimes like that, the potential for random behaviour might be the worse option. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: <le...@nt...> - 2003-06-12 21:26:56
|
On Thu, Jun 12, 2003 at 11:00:18PM +0200, Michel D?nzer wrote: > On Tue, 2003-06-10 at 13:14, Keith Whitwell wrote: > > Andreas Stenglein wrote: > > > > > > 3) in radeon_ioctl.c, function radeonEmitVbufPrim() > > > the first cmd is cleared before filled with the cmd_type: > > > cmd[0].i = 0; > > > cmd[0].header.cmd_type = RADEON_CMD_PACKET3_CLIP; > > > .... > > > should this be done in radeonEmitBlit() also or > > > is that not necessary? > > > > Quite possibly it should. > > Definitely a good idea, or the other header fields may have random > contents. I thought I'd added that once to make the verbose debug output slightly easier to read? I'm pretty sure the way the variable's checked in the kernel it doesn't matter. > Actually, why not clear the header in AllocCmdBuf() instead of > in the callers? While it may be cleared unnecessarily sometimes like > that, the potential for random behaviour might be the worse option. Zeroing all the Alloc'd buffer will just slow it down a bit (but probably make some more verbose output slightly easier to read - does anyone ever use the verbose output though? If it matters, it'd be easy enough to fix it in the verbose output anyway) -- Michael. |