Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
On 12 Apr 2003, Eric Anholt wrote: On Sat, 2003-04-12 at 10:17, Leif Delgass wrote: I think setting rmesa-sarea-nbox = 0 when there are 3 or fewer cliprects and the cliprects dirty flag isn't set should be correct. The idea is that, since r128 has three auxiliary hardware scissors (3 cliprects can be emitted per re-used vertex buffer), there is no need to update the scissor registers unless the cliprects have changed or there are more than 3 cliprects. Actually, I'm not sure why the test isn't nbox 4. Similarly the check for nbox = R128_NR_SAREA_CLIPRECTS should be a right? That sounds right, yes. Wouldn't it make much more sense for the kernel to be basing its uploading of cliprects off of sarea_priv-dirty R128_UPLOAD_CLIPRECTS? If I understand it right, then we wouldn't need tricks like count=0 (not 100% sure on this one) and nbox=0 setting. As it is, nothing uses sarea_priv-dirty R128_UPLOAD_CLIPRECTS. Yeah, it's all done client side right now. The real problem may be elsewhere. One possibility is that on context switches with the X server, the ring may not be flushed of drawing commands using old clipping information. Another thing that might help is updating the window position and scissor information immediately from r128GetLock, rather than setting new_state flags. This is one of the changes I made in the mach64 driver relative to r128, based on the code in the radeon driver. Mach64 used to have the same sort of clipping and overlapping window problems as r128. I'll have to go back through my changes and see if I can reconstruct what I did. It would also improve window moving if we implement XAA blits for back-buffer (and depth buffer?) moves as in the Radeon driver (I did this for mach64 also). For now it's still an improvement because it does clip things correctly, but by uploading cliprects every time. I'll try to compare more carefully against what radeon/mach64 do with clipping and get it fixed right. I'm working on this now. I think one of the problems is the delayed updating of new drawable info. The new_state flag isn't examined between acquiring the lock and calling r128FlushVerticesLocked, so new drawable info coming after acquiring the lock doesn't get used until after the vertex buffer is sent, causing stale scissor and window position info to be used. Basically, I'm making the code look a bit more like radeon and mach64. I don't think XAA blits would solve the problem I was seeing, if you were trying to say that. Once in a while after moving the window the gears would continue spinning at the same offset in the screen as before, just with the window in a different place. I'll take a look at that, though. It wouldn't fix drawing outside of the window, but it would prevent an offset back buffer being swapped to the front or being drawn over and then swapped. That makes the moves look jerky. I think what you're seeing is probably a result of the window offset not being picked up early enough, as I mentioned above. I just tested a patch that reworks the state handling for window position, cliprects and scissor and I've been able to eliminate the show through with overlapping windows while still using sarea-nbox = 0 for fewer than 4 cliprects. I'll post a patch you can try soon. Another question: the advantage of Allocate/FreeOffscreenArea()s in the TransitionTo2/3d is to leave more room for pixmaps in the 2d-only case, right? Right, I think we should add this as well. It's especially helpful for these older cards with less memory. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Ian, this commit includes references to rmesa-hw.cube[], which isn't in radeon_context.h yet. I don't see any reason not to commit the entire cube map patch, but leave the extension disabled. I haven't had time to investigate the problems yet, but most of the code looks to be identical to r200. At any rate, I haven't encountered any regressions as a result of having the patch applied. With the extension enabled, the cubemap demo seems to kind of work, but it seems to only use the yellow cube face. Is that what you were seeing? On Wed, 19 Feb 2003, Ian Romanick wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ Changes by: idr@sc8-pr-cvs1.03/02/19 09:00:33 Log message: Cut dead code calculations from uploadSubImage. Added support to uploadSubImage for face 1 (required for eventual cube_map support). Modified files: xc/xc/lib/GL/mesa/src/drv/radeon/: Tag: texmem-0-0-1 radeon_texmem.c Revision ChangesPath 1.11.14.8 +26 -21xc/xc/lib/GL/mesa/src/drv/radeon/radeon_texmem.c --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-patches mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-patches -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Leif Delgass wrote: Ian, this commit includes references to rmesa-hw.cube[], which isn't in radeon_context.h yet. I don't see any reason not to commit the entire cube map patch, but leave the extension disabled. I haven't had time to investigate the problems yet, but most of the code looks to be identical to r200. At any rate, I haven't encountered any regressions as a result of having the patch applied. D'oh! The problem is that part of the (full) patch modifies kernel code. I don't want to get into a situation where we have funky non-working kernel code floating around. I should either back out the broken stuff that I put in or commit the rest of the user-side cube_map support. Ugh. With the extension enabled, the cubemap demo seems to kind of work, but it seems to only use the yellow cube face. Is that what you were seeing? Yeah, that's exactly what I see. Any thoughts? --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
On Wed, 19 Feb 2003, Ian Romanick wrote: Leif Delgass wrote: Ian, this commit includes references to rmesa-hw.cube[], which isn't in radeon_context.h yet. I don't see any reason not to commit the entire cube map patch, but leave the extension disabled. I haven't had time to investigate the problems yet, but most of the code looks to be identical to r200. At any rate, I haven't encountered any regressions as a result of having the patch applied. D'oh! The problem is that part of the (full) patch modifies kernel code. I don't want to get into a situation where we have funky non-working kernel code floating around. I should either back out the broken stuff that I put in or commit the rest of the user-side cube_map support. Ugh. With the extension enabled, the cubemap demo seems to kind of work, but it seems to only use the yellow cube face. Is that what you were seeing? Yeah, that's exactly what I see. Any thoughts? I don't have docs, so I can't verify that we're not missing any relevant bits. The r200 has pp_texformat_x, which has a bit for the texcoord use: non-projective, cubic, volume, etc. I don't see anything like that for R100. I tried modifying the texgen matrices to swap the third and fourth columns, but it didn't seem to have an effect. The upload code looks like it's the same as r200, but I haven't tried to verify that it's working right. Do you know which face the yellow one is? -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Keith Whitwell wrote: Ian Romanick wrote: Did you ever monkey around with their 16-sample texture filter (the anisotropic mode)? I played with that a bit, but every time I selected that mode it would crash the graphics chip. :( No, never tried it. Do you have to somehow dedicate both texture units to the task? If you do, it sure doesn't make any mention of it in the documentation, but that doesn't seem to mean anything. :) The only restrictions that it mentions is that transparency must be disabled and filteralpha must be enabled. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Ian Romanick wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/lib/GL/mesa/src/drv/mga/ Changes by: idr@sc8-pr-cvs1. 03/01/27 15:47:14 Log message: Major re-write of the texture upload code. Added support to G400 for 2048x2048 textures and use of all 12 mipmap levels. Cool -- I never got the 'g400' style texture addressing to work properly... Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Keith Whitwell wrote: Ian Romanick wrote: CVSROOT:/cvsroot/dri Module name:xc Repository:xc/xc/lib/GL/mesa/src/drv/mga/ Changes by:idr@sc8-pr-cvs1.03/01/27 15:47:14 Log message: Major re-write of the texture upload code. Added support to G400 for 2048x2048 textures and use of all 12 mipmap levels. Cool -- I never got the 'g400' style texture addressing to work properly... Keith It's a little weird, that's for sure. There's a big comment in mgacontext.h that explains what I did and how it could possibly be improved in the future. Basically it works like this. On the G200 there were 5 pointer that were used to point to the individual mipmaps. On G400, those same 5 pointers are still there, but by setting a bit in one of the pointers the next pointer will be used as an offset to the rest of the mipmaps. I just always set that magic bit in the first pointer and the next pointer tells the hardware where all the rest of the mipmaps are. Did you ever monkey around with their 16-sample texture filter (the anisotropic mode)? I played with that a bit, but every time I selected that mode it would crash the graphics chip. :( --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Ian Romanick wrote: Keith Whitwell wrote: Ian Romanick wrote: CVSROOT:/cvsroot/dri Module name:xc Repository:xc/xc/lib/GL/mesa/src/drv/mga/ Changes by:idr@sc8-pr-cvs1.03/01/27 15:47:14 Log message: Major re-write of the texture upload code. Added support to G400 for 2048x2048 textures and use of all 12 mipmap levels. Cool -- I never got the 'g400' style texture addressing to work properly... Keith It's a little weird, that's for sure. There's a big comment in mgacontext.h that explains what I did and how it could possibly be improved in the future. Basically it works like this. On the G200 there were 5 pointer that were used to point to the individual mipmaps. On G400, those same 5 pointers are still there, but by setting a bit in one of the pointers the next pointer will be used as an offset to the rest of the mipmaps. I just always set that magic bit in the first pointer and the next pointer tells the hardware where all the rest of the mipmaps are. Did you ever monkey around with their 16-sample texture filter (the anisotropic mode)? I played with that a bit, but every time I selected that mode it would crash the graphics chip. :( No, never tried it. Do you have to somehow dedicate both texture units to the task? Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Alan Hourihane wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/lib/GL/mesa/src/drv/r128/ Changes by: alanh@sc8-pr-cvs1. 02/12/05 16:22:45 Log message: texture units are 0 and 1, not 1 and 2. Textures are still a bit funky yet Nice. The problem I saw but haven't fixed yet was that eventually the texture offset would point to somewhere in the front buffer - so you'd start to see bits of window borders, etc in the texture maps... This is all brand new code - the merge-to-trunk isn't happening til it's fixed... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Actually 1 and 2 are correct for unit 0 and 1, since they are bitflags. However, this switch/case isn't needed at all here since the flags are updated elsewhere. The default was hit with a value of zero because t-base.bound isn't actually set until after this (in update_tex_common in r128_texstate.c -- the same place where the upload flags are set). I committed a fix for this as well as a missing check for new texture state in r128RunPipeline (r128_tris.c). Since is needed because of the removal of R128_NEW_TEXTURE from the rmesa-new_state flags. There are still texture problems though, particularly with multitexture. Try multiarb. On Thu, 5 Dec 2002, Alan Hourihane wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/lib/GL/mesa/src/drv/r128/ Changes by: alanh@sc8-pr-cvs1. 02/12/05 16:22:45 Log message: texture units are 0 and 1, not 1 and 2. Textures are still a bit funky yet Modified files: xc/xc/lib/GL/mesa/src/drv/r128/:Tag: texmem-0-0-1 r128_texmem.c r128_tris.c Revision ChangesPath 1.3.36.4 +3 -3 xc/xc/lib/GL/mesa/src/drv/r128/r128_texmem.c 1.20.10.3 +3 -0 xc/xc/lib/GL/mesa/src/drv/r128/r128_tris.c --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-patches mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-patches -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
On Thu, Nov 28, 2002 at 12:57:52PM +, Keith Whitwell wrote:
Ian Romanick wrote:
CVSROOT:/cvsroot/dri
Module name:xc
Repository: xc/xc/lib/GL/mesa/src/drv/r128/
Changes by: idr@sc8-pr-cvs1.02/11/27 12:47:44
Log message:
Initial pass at adding texmem support to Rage128 driver. These
changes have not yet been tested as I don't have access to Rage128
hardware. I will post to dri-devel to beg for help.
I fixed one trivial problem with turning on extensions (is that *strictly* a
texmem change, Ian?)
Now I've got this:
Program received signal SIGSEGV, Segmentation fault.
0x4047258c in driInitTextureObjects (ctx=0x8056b18, swapped=0x8054e00,
targets=3) at texmem.c:802
802 move_to_tail( swapped, (driTextureObject *) texObj-DriverData );
(gdb) print swapped
$1 = (driTextureObject *) 0x8054e00
(gdb) print *swapped
$2 = {next = 0x8054e00, prev = 0x8054e00, heap = 0x0, tObj = 0x0,
memBlock = 0x0, bound = 0, totalSize = 0, dirty_images = {0, 0, 0, 0, 0, 0}}
(gdb) print texObj-DriverData
$3 = (void *) 0x0
I seem to recall having a similar issue when I added texmem support to the
MGA driver. There was some subtle difference in the handling of the
DriverData pointer between the pre-radeon drivers and the post-radeon
drivers. This is at the top of my queue today...
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Ian Romanick wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/r128/
Changes by: idr@sc8-pr-cvs1. 02/11/27 12:47:44
Log message:
Initial pass at adding texmem support to Rage128 driver. These
changes have not yet been tested as I don't have access to Rage128
hardware. I will post to dri-devel to beg for help.
I fixed one trivial problem with turning on extensions (is that *strictly* a
texmem change, Ian?)
Now I've got this:
Program received signal SIGSEGV, Segmentation fault.
0x4047258c in driInitTextureObjects (ctx=0x8056b18, swapped=0x8054e00,
targets=3) at texmem.c:802
802 move_to_tail( swapped, (driTextureObject *) texObj-DriverData );
(gdb) print swapped
$1 = (driTextureObject *) 0x8054e00
(gdb) print *swapped
$2 = {next = 0x8054e00, prev = 0x8054e00, heap = 0x0, tObj = 0x0,
memBlock = 0x0, bound = 0, totalSize = 0, dirty_images = {0, 0, 0, 0, 0, 0}}
(gdb) print texObj-DriverData
$3 = (void *) 0x0
It seems to be during initialization:
(gdb) bt
#0 0x4047258c in driInitTextureObjects (ctx=0x8056b18, swapped=0x8054e00,
targets=3) at texmem.c:802
#1 0x4047ae70 in r128DDInitTextureFuncs (ctx=0x8056b18) at r128_tex.c:608
#2 0x404729b1 in r128CreateContext (dpy=0x80527f0, glVisual=0xb880,
driContextPriv=0x8054ca8, sharedContextPrivate=0x0) at r128_context.c:215
#3 0x40347fcc in driCreateContext (dpy=0x80527f0, vis=0x8053c28,
sharedPrivate=0x0, pctx=0x80562e4) at dri_util.c:849
#4 0x4010839a in CreateContext (dpy=0x80527f0, vis=0x8053c28, shareList=0x0,
allowDirect=1, contextID=0) at glxcmds.c:175
#5 0x4010849d in glXCreateContext (dpy=0x80527f0, vis=0x8053c28,
shareList=0x0, allowDirect=1) at glxcmds.c:212
#6 0x4002e72a in __glutCreateWindow () from /home/XF4/lib/libglut.so.3
#7 0x4002e9d6 in glutCreateWindow () from /home/XF4/lib/libglut.so.3
#8 0x0804b397 in main ()
#9 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
I'll have a look find out more.
Keith
---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Keith Whitwell wrote:
Ian Romanick wrote:
CVSROOT:/cvsroot/dri
Module name:xc
Repository:xc/xc/lib/GL/mesa/src/drv/r128/
Changes by:idr@sc8-pr-cvs1.02/11/27 12:47:44
Log message:
Initial pass at adding texmem support to Rage128 driver. These
changes have not yet been tested as I don't have access to Rage128
hardware. I will post to dri-devel to beg for help.
I fixed one trivial problem with turning on extensions (is that
*strictly* a texmem change, Ian?)
Now I've got this:
Program received signal SIGSEGV, Segmentation fault.
0x4047258c in driInitTextureObjects (ctx=0x8056b18, swapped=0x8054e00,
targets=3) at texmem.c:802
802 move_to_tail( swapped, (driTextureObject *)
texObj-DriverData );
(gdb) print swapped
$1 = (driTextureObject *) 0x8054e00
(gdb) print *swapped
$2 = {next = 0x8054e00, prev = 0x8054e00, heap = 0x0, tObj = 0x0,
memBlock = 0x0, bound = 0, totalSize = 0, dirty_images = {0, 0, 0, 0,
0, 0}}
(gdb) print texObj-DriverData
$3 = (void *) 0x0
Well, there's nothing in r128BindTexture that tries to allocate
tObj-DriverData, so I'm either going to just put a guard in front of each of
those move_to_tail's, or perhaps not call the init function at all, since it
looks like a noop overall.
Keith
---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
Keith Whitwell wrote: Ian Romanick wrote: CVSROOT:/cvsroot/dri Module name:xc Repository:xc/xc/lib/GL/mesa/src/drv/r128/ Changes by:idr@sc8-pr-cvs1.02/11/27 12:47:44 Log message: Initial pass at adding texmem support to Rage128 driver. These changes have not yet been tested as I don't have access to Rage128 hardware. I will post to dri-devel to beg for help. I fixed one trivial problem with turning on extensions (is that *strictly* a texmem change, Ian?) Now I've got this: Program received signal SIGSEGV, Segmentation fault. 0x4047258c in driInitTextureObjects (ctx=0x8056b18, swapped=0x8054e00, targets=3) at texmem.c:802 802 move_to_tail( swapped, (driTextureObject *) texObj-DriverData ); Ian, OK, fixing that, there's more of the same stuff later. It seems there's an assumption that tObj-DriverData is always non-null, but that isn't actually the case. I'm not sure which way you want to fix this. Keith --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
