Re: R200 Projective texturing and texgen
On Sun, 2004-10-10 at 10:13, Andreas Stenglein wrote: Am 2004.10.10 11:14:11 +0200 schrieb(en) Eric Anholt: http://pdx.freedesktop.org/~anholt/dri/r200-projtex-6.diff #4 had broken nontcl quite significantly. I'm thinking I just stomped some of my changes with another editor window at some point. Things seem decent again with the link above, but tcl doom is still in bad shape. Eric, could you have a look at https://freedesktop.org/bugzilla/show_bug.cgi?id=1461 there is some code for swtcl to detect transition from 3 component coord STR - STQ which might happen in the rare case if TMUx was used for a cubemap and then for projective texturing and the coord components of the other TMUs didnt change, too. At the moment projective texturing in non-tcl mode can't work because the q-coord doesn't get emitted ever, its always the r-coord. (Maybe the global projtex variable from r200_context.h should get inized somewhere) My patch should be basically equivalent to that one, I think, except that I'm still emitting 4 texcoords instead of 3. While 3 would be a small savings, I wonder if that small savings matters compared to having to handle more state switching (switching RE_CNTL for moving from TCL to non-) to do it that way. However, I haven't tested that one, primarily because it was attached inline rather than as a downloadable attachment. The question would be if it actually made projtex work correctly (so that there were no extra corners), versus just getting the scale right. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Undefined symbols in recent DRM
El Domingo, 10 de Octubre del 2004 12:08 AM, Adam Jackson escribi: On Saturday 09 October 2004 12:02, Felix Khling wrote: On Sat, 9 Oct 2004 09:09:52 -0400 Adam Jackson [EMAIL PROTECTED] wrote: On Friday 08 October 2004 17:22, David wrote: Hi. Common and savage snapshots from 20041008 are giving me this at the XFree86 startup: You cannot use modules compiled for Xorg 6.8 on XFree86 anything. I thought they were still binary compatible. If they are not then we would have to offer a download of a precompiled Xorg server for snapshot users. They are forwards compatible but not backwards compatible. 4.4 modules will work on 6.8, but 6.8 modules won't work on 4.4. So yes, we need to build an Xorg server snapshot. - ajax I don't want to reinstall my whole box every year, so I must find a way to test current snapshots on XFree86 or give up with testing. The new snapshots instructions (Xorg binary, etc...) are giving me this: Symbol FontCacheChangeSettings from module /usr/X11R6/lib/modules/extensions/libextmod.a is unresolved! Symbol FontCacheGetStatistics from module /usr/X11R6/lib/modules/extensions/libextmod.a is unresolved! Symbol FontCacheGetSettings from module /usr/X11R6/lib/modules/extensions/libextmod.a is unresolved! Symbol FontCacheCloseCache from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheSearchEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheGetEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheInsertEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheGetEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheOpenCache from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheSearchEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheGetBitmap from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheSearchEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP_PM from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP_PM from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Fatal server error: Some required symbols were unresolved Maybe you can provide us some binary modules with the Xorg snapshot (libextmod and libxtt). Thanks --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1461] missing textures in some games on r200
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://freedesktop.org/bugzilla/show_bug.cgi?id=1461 --- Additional Comments From [EMAIL PROTECTED] 2004-10-10 13:13 --- This patch doesn't applies clean . melchior:/usr/src/dri/Mesa# patch -p1 -i ../andreas.patch --dry-run patching file src/mesa/drivers/dri/r200/r200_context.h Hunk #1 succeeded at 676 (offset -1 lines). patching file src/mesa/drivers/dri/r200/r200_swtcl.c Hunk #2 FAILED at 151. Hunk #3 FAILED at 169. 2 out of 3 hunks FAILED -- saving rejects to file src/mesa/drivers/dri/r200/r200_swtcl.c.rej patching file src/mesa/drivers/dri/r200/r200_texstate.c Hunk #1 succeeded at 293 (offset 27 lines). melchior:/usr/src/dri/Mesa# Suggestions? Bye Marcello -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1461] missing textures in some games on r200
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://freedesktop.org/bugzilla/show_bug.cgi?id=1461 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|dri-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2004-10-10 13:36 --- Created an attachment (id=1082) -- (https://freedesktop.org/bugzilla/attachment.cgi?id=1082action=view) r200-projtex-6.diff Pasting the patch inline caused it to break due to whitespace. I'm attaching my current patch of work-in-progress texcoord/projtex code, which I think should do just as well for this issue. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 Projective texturing and texgen
Am Sonntag, 10. Oktober 2004 21:56 schrieb Eric Anholt: On Sun, 2004-10-10 at 10:13, Andreas Stenglein wrote: Am 2004.10.10 11:14:11 +0200 schrieb(en) Eric Anholt: http://pdx.freedesktop.org/~anholt/dri/r200-projtex-6.diff #4 had broken nontcl quite significantly. I'm thinking I just stomped some of my changes with another editor window at some point. Things seem decent again with the link above, but tcl doom is still in bad shape. Eric, could you have a look at https://freedesktop.org/bugzilla/show_bug.cgi?id=1461 there is some code for swtcl to detect transition from 3 component coord STR - STQ which might happen in the rare case if TMUx was used for a cubemap and then for projective texturing and the coord components of the other TMUs didnt change, too. At the moment projective texturing in non-tcl mode can't work because the q-coord doesn't get emitted ever, its always the r-coord. (Maybe the global projtex variable from r200_context.h should get inized somewhere) My patch should be basically equivalent to that one, I think, except that I'm still emitting 4 texcoords instead of 3. While 3 would be a small savings, I wonder if that small savings matters compared to having to handle more state switching (switching RE_CNTL for moving from TCL to non-) to do it that way. However, I haven't tested that one, primarily because it was attached inline rather than as a downloadable attachment. The question would be if it actually made projtex work correctly (so that there were no extra corners), versus just getting the scale right. Roland have some work on this, too. https://freedesktop.org/bugzilla/show_bug.cgi?id=1461 Patch https://freedesktop.org/bugzilla/attachment.cgi?id=981 Could you all do 'synchronised' work? Regards, Dieter -- Dieter Nützel @home: Dieter.Nuetzel () hamburg ! de --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 Projective texturing and texgen
Am Sonntag, 10. Oktober 2004 11:14 schrieb Eric Anholt: On Sun, 2004-10-10 at 00:26, Dave Airlie wrote: projtex with TCL works correctly. projtex with no TCL is closer. texgenmix row 2 col 2 and 3 work. texgenmix row 3 col 1 doesn't work any more (cols 2/3 still don't work). fixes stex3d (look at the outer edge before/after) doom3 has no more flickering. (No more TCL fallbacks) texcyl reflect mode still broken. vtxfmt is disabled because I never got things working with it. I've just ran this with doom3, the lighting is well off on it though, you can normally see very little in doom3 anyways but it is really off with your patch applied.. http://pdx.freedesktop.org/~anholt/dri/r200-projtex-6.diff #4 had broken nontcl quite significantly. I'm thinking I just stomped some of my changes with another editor window at some point. Things seem decent again with the link above, but tcl doom is still in bad shape. GREAT progress. DOOM3 is working with TCL, little to dark, but...;-) Celestia 'Earth'-'ISS' have light in the windows, now. But some flickering on the sun paddels left. Quake3 quake3.x86 and quake3-smp-x86 do NOT exit clean anylonger. Not with Quit menu or typing in the console. UT2003 Some broken textures on the walls and floors (Temple of Anubis). 'shock rifle' is OK 'Exit' dito. progs/demos fcntl: Invalid argument fcntl: Invalid argument Backtrace: [ 1] ./Core.so [0x40a0978a] [ 2] [0xe420] Signal: SIGSEGV [segmentation fault] Aborting. [1]Speicherschutzverletzung ut2003_demo UT2004 Working. I've seen no corrupted textures. 'shock rifle' is OK 'Exit' dito. progs/demos ut2004demo [1] 18163 progs/demos Signal: SIGSEGV [segmentation fault] Aborting. Crash information will be saved to your logfile. [1]Exitcode 1ut2004demo Developer Backtrace: Log: [ 1] ./ut2004-bin [0x869e38c] Log: [ 2] [0xe420] Log: Unreal Call Stack: USDLClient::Destroy - UObject::ConditionalDestroy - DispatchDestroy - DispatchDestroys - UObject::PurgeGarbage - UObject::StaticExit - appPreExit Exit: Exiting. Log: FileManager: Reading 0 GByte 0 MByte 0 KByte 0 Bytes from HD took 0.00 seconds (0.00 reading, 0.00 seeking). Log: FileManager: 0.00 seconds spent with misc. duties Uninitialized: Name subsystem shut down Uninitialized: Allocation checking disabled Uninitialized: Log file closed, Sun Oct 10 23:22:43 2004 Good night! -Dieter --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Undefined symbols in recent DRM
On Sun, 10 Oct 2004 22:01:30 +0200 David [EMAIL PROTECTED] wrote: [snip] They are forwards compatible but not backwards compatible. 4.4 modules will work on 6.8, but 6.8 modules won't work on 4.4. So yes, we need to build an Xorg server snapshot. - ajax I don't want to reinstall my whole box every year, so I must find a way to test current snapshots on XFree86 or give up with testing. The new snapshots instructions (Xorg binary, etc...) are giving me this: Adam, can you comment this? How much besides the Xorg server binary is needed in order to get this working? Is it realistic to make Xorg work in a XFree86 installation with only a few binary replacements? How soon is any such thing going to break again? Looks like we also need libextmod and libxtt. And the unresolved symbols in the savage driver module look like it requires some newer libxaa and libfb modules than the XFree86 ones. Anything else? I guess we could add any new xorg modules to the common snapshots. Symbol FontCacheChangeSettings from module /usr/X11R6/lib/modules/extensions/libextmod.a is unresolved! Symbol FontCacheGetStatistics from module /usr/X11R6/lib/modules/extensions/libextmod.a is unresolved! Symbol FontCacheGetSettings from module /usr/X11R6/lib/modules/extensions/libextmod.a is unresolved! Symbol FontCacheCloseCache from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheSearchEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheGetEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheInsertEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheGetEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheOpenCache from module /usr/X11R6/lib/modules/fonts/libxtt..a is unresolved! Symbol FontCacheSearchEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheGetBitmap from module /usr/X11R6/lib/modules/fonts/libxtt..a is unresolved! Symbol FontCacheSearchEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP_PM from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP_PM from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Fatal server error: Some required symbols were unresolved Maybe you can provide us some binary modules with the Xorg snapshot (libextmod and libxtt). Thanks | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 Projective texturing and texgen
I missed that you changed the way texcoords get emitted (4 components for projective texturing) in your patch. Forget the experimental patch in the bug-database, something similar might be necessary only for the old radeon (R100) somewhen, since this one seems to not support 4 component tex-coords. greetings, Andreas Am 2004.10.10 19:13:51 +0200 schrieb(en) Andreas Stenglein: Am 2004.10.10 11:14:11 +0200 schrieb(en) Eric Anholt: http://pdx.freedesktop.org/~anholt/dri/r200-projtex-6.diff #4 had broken nontcl quite significantly. I'm thinking I just stomped some of my changes with another editor window at some point. Things seem decent again with the link above, but tcl doom is still in bad shape. Eric, could you have a look at https://freedesktop.org/bugzilla/show_bug.cgi?id=1461 there is some code for swtcl to detect transition from 3 component coord STR - STQ which might happen in the rare case if TMUx was used for a cubemap and then for projective texturing and the coord components of the other TMUs didnt change, too. At the moment projective texturing in non-tcl mode can't work because the q-coord doesn't get emitted ever, its always the r-coord. (Maybe the global projtex variable from r200_context.h should get inized somewhere) greetings, Andreas --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[rfc] VIA dri and security.
Hi! Sorry for the double posting. This is a thing that needs to be discussed in both communities. The via DRM has started it's journey into the linus kernel, but the 3D driver / DDX still suffers from a security flaw: When the MMIO area is exported read-write it is assumed possible for a dri client to manipulate registers to blit otherwise protected areas of the system memory to video memory. It is the DDX that tells the DRM whether to export the MMIO area read-only or read-write. The OpenGL 3D driver unichrome_dri.so currently needs write access to this area, until someone fixes it up to use register writing ioctls now present in the via drm. The obvious fix is for the DDX to tell DRM to export the MMIO area as read-only. In this way a normal user would get a segfault when trying to run accelerated OpenGL, while it would work as root. There's been a discussion at the unichrome site, where most of the via DDX development is taking place at the moment, on whether to leave the user with this only option. We propose a solution where the user could use a driver option AllowInsecureDRI to have the MMIO area exported read-write. The security hazards of doing this is briefly explained in the via man-page and warning message will be output in the X server log if this option is enabled. Since we also plan on syncing the development with the via driver in Xorg it's important that this does not violate any security policy in Xorg. We figure that to open up the system in this way, you still need to be root and the option name speeks for itself. Also the average user would more likely damage his system running a 3D application as root than be the subject of somebody exploiting this vulnerability. The current via DDX in Xorg allows read-write access to these registers. It would be good to have some comments / ideas about whether the proposed solution could be considered OK. Regards Thomas --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Linux: 2.4.28-pre4, No More New Features For 2.4
http://kerneltrap.org/node/view/3980 Marcelo Tosatti [interview] released 2.4.28-pre4 with few changes since -pre3 a month ago [story], it contains a number of driver updates (pcnet, e1000, gdth, prism54), a network update from David, few more gcc3.4 warning fixes. He noted that no more new features are planned for the 2.4 stable kernel, from now on [I] can change only what is necessary and let the 2.4 tree [rest] in peace :) What should be our policy toward 2.4? For example if 2.4 is now closed should we implement the drm-core model for it? What about new drivers? If 2.4 is closed these aren't going to be accepted. This is a different question than fixing the drivers that are already in 2.4. We should still do that as we find problems. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 Projective texturing and texgen
On Sun, 2004-10-10 at 13:50, Dieter Nützel wrote: Am Sonntag, 10. Oktober 2004 21:56 schrieb Eric Anholt: On Sun, 2004-10-10 at 10:13, Andreas Stenglein wrote: Am 2004.10.10 11:14:11 +0200 schrieb(en) Eric Anholt: http://pdx.freedesktop.org/~anholt/dri/r200-projtex-6.diff #4 had broken nontcl quite significantly. I'm thinking I just stomped some of my changes with another editor window at some point. Things seem decent again with the link above, but tcl doom is still in bad shape. Eric, could you have a look at https://freedesktop.org/bugzilla/show_bug.cgi?id=1461 there is some code for swtcl to detect transition from 3 component coord STR - STQ which might happen in the rare case if TMUx was used for a cubemap and then for projective texturing and the coord components of the other TMUs didnt change, too. At the moment projective texturing in non-tcl mode can't work because the q-coord doesn't get emitted ever, its always the r-coord. (Maybe the global projtex variable from r200_context.h should get inized somewhere) My patch should be basically equivalent to that one, I think, except that I'm still emitting 4 texcoords instead of 3. While 3 would be a small savings, I wonder if that small savings matters compared to having to handle more state switching (switching RE_CNTL for moving from TCL to non-) to do it that way. However, I haven't tested that one, primarily because it was attached inline rather than as a downloadable attachment. The question would be if it actually made projtex work correctly (so that there were no extra corners), versus just getting the scale right. Roland have some work on this, too. https://freedesktop.org/bugzilla/show_bug.cgi?id=1461 Patch https://freedesktop.org/bugzilla/attachment.cgi?id=981 Could you all do 'synchronised' work? As the original message said, I was basing off of his patch. He's stuck on it, so I was seeing if I could come up with anything. I'm thinking this might be as good as we can do as far as texgen goes -- fglrx apparently gets it wrong similarly to how this patch does (though fglrx looks closer for the row 3 col 1 square). -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drmOpen with drm-core
I wish libdrm reported something more than just error 1 (Operation not permitted) The problem is what I described, not setting the name, the strcmp fails as the name it gets back from getversion is drm not the card name.. this causes the libdrm to fail.. fixing the drmto use the proper name will work fine.. Granted apps should try using the newer interface.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drmOpen with drm-core
On Sun, 10 Oct 2004 23:49:49 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote: fixing the drmto use the proper name will work fine.. I just checked in code that should fix the name problem. Give it a try since I haven't figured out how to reproduce the problem yet. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1519] Enabling Anisotropy Locks r200 Driver
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://freedesktop.org/bugzilla/show_bug.cgi?id=1519 --- Additional Comments From [EMAIL PROTECTED] 2004-10-10 15:58 --- Created an attachment (id=1083) -- (https://freedesktop.org/bugzilla/attachment.cgi?id=1083action=view) dbg = 0x6 setting Off of clean CVS I could get a lockup in under 30 seconds. Changing dbg = 0x0 to 0x6 cleared it up. Do we know what exactly dbg = 0x6 does? Are there significant downsides? -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Undefined symbols in recent DRM
On Sunday 10 October 2004 17:45, Felix Kühling wrote:
On Sun, 10 Oct 2004 22:01:30 +0200 David [EMAIL PROTECTED] wrote:
[snip]
They are forwards compatible but not backwards compatible. 4.4 modules
will work on 6.8, but 6.8 modules won't work on 4.4. So yes, we need
to build an Xorg server snapshot.
- ajax
I don't want to reinstall my whole box every year, so I must find a way
to test current snapshots on XFree86 or give up with testing.
The new snapshots instructions (Xorg binary, etc...) are giving me this:
Adam, can you comment this? How much besides the Xorg server binary is
needed in order to get this working? Is it realistic to make Xorg work
in a XFree86 installation with only a few binary replacements? How soon
is any such thing going to break again?
Looks like we also need libextmod and libxtt. And the unresolved symbols
in the savage driver module look like it requires some newer libxaa and
libfb modules than the XFree86 ones. Anything else? I guess we could add
any new xorg modules to the common snapshots.
The server binary and all of ${PROJECTROOT}/lib/modules should be sufficient.
Note that that's pretty much equivalent to upgrading to Xorg.
- ajax
pgpvGVloyWsDh.pgp
Description: PGP signature
3D not working after software suspend/resume
after a software suspend/resume cycle, running glxgears emits the following error msgs and quits: libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x23 libGL warning: 3D driver claims to not support visual 0x26 libGL warning: 3D driver claims to not support visual 0x27 intelWaitIrq: drmI830IrqWait: -16 The kernel also logged the following message: [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 972815 emitted: 972834 I'm running Xorg 6.8.1 with i915-20041008 snapshot. My video card is an Intel 855GM, below is the lspci -v output # lspci -v 00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02) Flags: bus master, fast devsel, latency 0 Memory at unassigned (32-bit, prefetchable) Capabilities: [40] #09 [a105] 00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control Registers (rev 02) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, fast devsel, latency 0 00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration Process Registers (rev 02) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, fast devsel, latency 0 00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at b000 (32-bit, prefetchable) [size=128M] Memory at f000 (32-bit, non-prefetchable) [size=512K] I/O ports at e000 [size=8] Capabilities: [d0] Power Management version 1 00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: fast devsel Memory at 2000 (32-bit, prefetchable) [disabled] [size=128M] Memory at 1e00 (32-bit, non-prefetchable) [disabled] [size=512K] Capabilities: [d0] Power Management version 1 00:1d.0 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #1 (rev 03) (prog-if 00 [UHCI]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at 1200 [size=32] 00:1d.2 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #3 (rev 03) (prog-if 00 [UHCI]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 1700 [size=32] 00:1d.7 USB Controller: Intel Corp. 82801DB (ICH4) USB2 EHCI Controller (rev 03) (prog-if 20 [EHCI]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 11 Memory at f008 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] #0a [2080] 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 83) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: c000-dfff Memory behind bridge: e000-efff Prefetchable memory behind bridge: a000-afff 00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 03) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 03) (prog-if 8a [Master SecP PriP]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at unassigned I/O ports at unassigned I/O ports at unassigned I/O ports at unassigned I/O ports at 1100 [size=16] Memory at 1e08 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corp. 82801DB/DBM (ICH4) SMBus Controller (rev 03) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: medium devsel, IRQ 6 I/O ports at 1400 [size=32] 00:1f.5 Multimedia audio controller: Intel Corp. 82801DB (ICH4) AC'97 Audio Controller (rev 03) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 6 I/O ports at e100 [size=256] I/O ports at e200 [size=64] Memory at f0080400 (32-bit, non-prefetchable) [size=512] Memory at f0080600 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:1f.6 Modem: Intel Corp. 82801DB (ICH4) AC'97 Modem Controller (rev 03) (prog-if 00 [Generic]) Subsystem: Toshiba America Info Systems: Unknown device 0001 Flags: bus master, medium devsel, latency 0, IRQ 6 I/O ports at e300 [size=256] I/O ports at e400 [size=128]
Re: ProSavage DDR XvScaling
The should be fixed now in xorg cvs. Alex On Fri, 27 Aug 2004 12:15:42 -0400, Robert S. Kerr [EMAIL PROTECTED] wrote: I've been looking into the scaling behavior on the ProsavageDDR I'm using Alex's patch on the Xorg cvs tree. Based on a recommendation from Alex, I've been looking in the savage_video.c file and I'm starting to make some progress. Currently I think I have hardware downscaling almost working. I can now hardware downscale to the point that the sources that I have are difficult to see (although I think that downscaling by 16, 32 and 64 might still be off). Plus I'm still not sure I'm doing it quite right (because the register settings I'm using don't seem to make sense compared to any of the older versions of the driver I've seen. But at least I'm getting somewhere. What I haven't been successfull at accomplishing is any hardware upscaling. If I upscale an image at all, then I get corrupted results. There is a comment in savage_video.c that offers me some clue: /* * Process horizontal scaling * upscaling and downscaling smaller than 2:1 controled by MM8198 * MM8190 controls downscaling mode larger than 2:1 */ The MM8198 is (I think) the memory mapped register at offset 0x8198. The driver refers to this elsewhere as SSTREAM_STRETCH_REG. The MM8190 is (I think) the memory mapped register at offset 0x8198. The driver refers to this elsewhere as SSTREAM_CONTROL_REG. I haven't been able to figure out how to get the stretch register to do any stretching though. I did find this: #define S_Filter_Shift28 #define S_Filter_Mask(7L S_Filter_Shift) #define S_1x(0L S_Filter_Shift) #define S_Upto2x(1L S_Filter_Shift) #define S_2xTo4x(2L S_Filter_Shift) #define S_Beyond4x(3L S_Filter_Shift) in the sddata.h file in the XvMC section of the updated VIA/S3 driver. This appears to be what I need, but ORing that into the SSTREAM_STRETCH_REG doesn't seem to help. Any ideas? Rob --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
