Re: R200 ReadPixels optimization
Am Samstag, 9. Oktober 2004 03:33 schrieb Ian Romanick: Ian Romanick wrote: Here's a simple patch that gives about a 50% (on my box) speed boost to glReadPixels performance in 24-bit. I measured using the benchmark built into progs/demos/readpix. The interesting thing is that the core MMX SSE2 routines can be used for other cards as well. For example, it looks like MGA, Unichrome, and others can use the same code for 24-bit. Before persuing this too far, I'd like to look at ways to make the *compiled* code from spantmp.h be more device-independent. That would make it easier to generate a bunch of these generic routines and just plug them in. Here's version 3 of the patch. This is *probably* the last version that will circulate as a patch. Here are the changes from the last version of the patch: - Fixes the problem where the R200 driver would only use the MMX version. - Numerous little optimizations to all 3 versions. The SSE version is still crap. :( - Trivially optimized the C version. ;) I'm thinking that a lot of this will actually get pulled into spantmp.h when I commit it. My thinking is to have the driver define which pixel format it uses (e.g., #define SPANTMP_USE_BGRA_REV) and have spantmp.h automatically generate the optimized versions (based on the existance of USE_MMX_ASM, etc.). Since there are just handful of pixel formats that appear in practice, this should be pretty easy to do. My only concern is big-endian machines. I should be able to try this out on a Rage128 in a Power Mac. Maybe there will be another version as a patch...ugh... Ian, NONE of your three versions gave me direct rendering?! I've tested with and without your TLS-patch (progress?). The symbols are in. DRI-Mesa/Patches nm /usr/X11R6-NO-TLS/lib/modules/dri/r200_dri.so | grep r200ReadRGBASpan_ARGB 00175714 t r200ReadRGBASpan_ARGB 00175be4 t r200ReadRGBASpan_ARGB_MMX 00175ad4 t r200ReadRGBASpan_ARGB_SSE 001759c4 t r200ReadRGBASpan_ARGB_SSE2 But DRI-Mesa/Patches nm /usr/X11R6-NO-TLS/lib/modules/dri/r200_dri.so | grep _generic_read_RGBA_span_BGRA U _generic_read_RGBA_span_BGRA_REV_MMX U _generic_read_RGBA_span_BGRA_REV_SSE U _generic_read_RGBA_span_BGRA_REV_SSE2 I'm on XFree86 DRI CVS build as long as my distro based on it;-) Any ideas? -Dieter BTW The old indirect mode is way faster then direct for me: progs/demos ./readpix Mesa: software DXTn compression/decompression available GL_VERSION = 1.3 Mesa 6.3 GL_RENDERER = Mesa DRI R200 20040929 AGP 4x x86/MMX+/3DNow!+/SSE TCL Loaded 194 by 188 image Benchmarking... Result: 348 reads in 4.009000 seconds = 3165940.633574 pixels/sec Benchmarking... Result: 344 reads in 4.007000 seconds = 3131112.553032 pixels/sec Benchmarking... Result: 346 reads in 4.001000 seconds = 3154039.490127 pixels/sec Benchmarking... Result: 278 reads in 4.007000 seconds = 2530375.842276 pixels/sec Benchmarking... Result: 275 reads in 4.003000 seconds = 2505570.821884 pixels/sec Benchmarking... Result: 272 reads in 4.001000 seconds = 2479476.130967 pixels/sec glDrawBuffer(GL_FRONT) Benchmarking... Result: 342 reads in 4.004000 seconds = 3115240.759241 pixels/sec Benchmarking... Result: 352 reads in 4.01 seconds = 3201532.169576 pixels/sec Benchmarking... Result: 342 reads in 4.004000 seconds = 3115240.759241 pixels/sec Benchmarking... Result: 269 reads in 4.011000 seconds = 2446015.457492 pixels/sec Benchmarking... Result: 268 reads in 4.00 seconds = 2443624.00 pixels/sec Benchmarking... Result: 270 reads in 4.01 seconds = 2455720.698254 pixels/sec Mesa indirect: progs/demos ./readpix GL_VERSION = 1.2 (1.5 Mesa 6.3) GL_RENDERER = Mesa GLX Indirect Loaded 194 by 188 image Benchmarking... Result: 1793 reads in 4.002000 seconds = 16340403.798101 pixels/sec Benchmarking... Result: 1797 reads in 4.00 seconds = 16385046.00 pixels/sec Benchmarking... Result: 1792 reads in 4.00 seconds = 16339456.00 pixels/sec Benchmarking... Result: 800 reads in 4.003000 seconds = 7288933.300025 pixels/sec Benchmarking... Result: 799 reads in 4.004000 seconds = 7278003.996004 pixels/sec Benchmarking... Result: 797 reads in 4.004000 seconds = 7259786.213786 pixels/sec glDrawBuffer(GL_FRONT) Benchmarking... Result: 294 reads in 4.007000 seconds = 2676008.984278 pixels/sec Benchmarking... Result: 290 reads in 4.002000 seconds = 2642898.550725 pixels/sec Benchmarking... Result: 291 reads in 4.008000 seconds = 2648041.916168 pixels/sec Benchmarking... Result: 241 reads in 4.009000 seconds = 2192504.864056 pixels/sec Benchmarking... Result: 240 reads in 4.015000 seconds = 2180144.458281 pixels/sec Benchmarking... Result: 240 reads in 4.014000 seconds = 2180687.593423 pixels/sec --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us
Re: VIA update
So from my point of view it should be safe for the via drm to go into the kernel. Okay I'll try and sort out a patch ASAP, just came back from some deep sea fishing, need to go to bed now :-) Dave. The Mesa driver might need to correct for version number bumps. /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 -- 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
drmOpen with drm-core
Hi! Just tried out the core-based drm today, and I notice that drmOpen(via) does not work anymore. What is the correct way to fix up this? I suspect my client should be using drmOpenByBusID ? 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
Re: [PATCH] Re: DRM oops with unichrome drivers
Is this a left over from gamma maybe?
correct,
I've killed them in CVS, and I'll push a patch to Linus tree also..
Dave.
leading to the null dereference.
I assume these lines need to be wrapped in an
if(drm_core_check_feature(dev, DRIVER_HAVE_DMA)) { } or something, but
I'll leave that to someone who actually understands this code.
Robert
--
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
Just tried out the core-based drm today, and I notice that drmOpen(via) does not work anymore. I think this should still work, as we are meant to retain backwards compat for older clients.. drmOpen calls drmOpenByBusID anyways in libdrm.. there may be something else wrong.. Dave. What is the correct way to fix up this? I suspect my client should be using drmOpenByBusID ? 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 -- 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: Can't apply S3TC patch anymore with current Mesa
On Fri, 08 Oct 2004 14:09:49 -0700, Eric Anholt [EMAIL PROTECTED] wrote: On Fri, 2004-10-08 at 13:40, Marcello Maggioni wrote: On Fri, 08 Oct 2004 13:23:03 -0700, Eric Anholt [EMAIL PROTECTED] wrote: On Fri, 2004-10-08 at 08:41, Dieter Nützel wrote: Am Freitag, 8. Oktober 2004 17:37 schrieb Felix Kühling: On Fri, 8 Oct 2004 17:10:35 +0200 Dieter Nützel [EMAIL PROTECTED] wrote: [snip] When I set 'setenv force_s3tc_enable 1' quake3-smp do NOT start anymore. ATTENTION: default value of option force_s3tc_enable overridden by environment. Fatal error in __driConfigOptions line 75, column 0: illegal default value: 1. That's because 1 is indeed illegal for boolean options such as force_s3tc_enable. Legal values are true and false. OK, but do not help ;-) It's working for myself and Roland. What build system are you using? I only added the USE_EXTERNAL_DXTN_LIB=1 define in Mesa linux-dri (and therefore linux-dri-x86) target. If you're using something else, you'll have to add the define to whatever CFLAGS there. -- 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 I have already -DUSE_EXTERNAL_DXTN_LIB=1 in my CFLAGS , I need something more? env MESA_DEBUG=1 glxgears will produce output if it tried to do s3tc, whether it succeeds or fails. If it doesn't print anything, then the issue was with building (and strings your_dri.so | grep dxtn won't mention the lib name). If it does produce output, then the problem is probably with the lack of the library or lack of env force_s3tc_enable=true. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] I get these messages with lastest MESA : melchior:/home/melchior/driconf-0.2.2# env MESA_DEBUG=1 glxinfo name of display: :0.0 cpu vendor: AuthenticAMD cpu name: AMD Athlon(tm) XP MMX cpu detected. 3DNow! cpu detected. Testing OS support for SSE... yes. Testing OS support for SSE unmasked exceptions... SIGFPE, yes. Tests of OS support for SSE passed. SSE cpu detected. Mesa warning: software DXTn compression/decompression available Using SSE version of ReadRGBASpan display: :0 screen: 0 direct rendering: Yes But I'm not able to understand if DXTn de/compression is used or not . UT2004 backgrounds in menus are still white . Someone can check this? Thanks Marcello --- 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: Can't apply S3TC patch anymore with current Mesa
On Sat, 9 Oct 2004 14:08:58 +0200, Marcello Maggioni [EMAIL PROTECTED] wrote: On Fri, 08 Oct 2004 14:09:49 -0700, Eric Anholt [EMAIL PROTECTED] wrote: On Fri, 2004-10-08 at 13:40, Marcello Maggioni wrote: On Fri, 08 Oct 2004 13:23:03 -0700, Eric Anholt [EMAIL PROTECTED] wrote: On Fri, 2004-10-08 at 08:41, Dieter Nützel wrote: Am Freitag, 8. Oktober 2004 17:37 schrieb Felix Kühling: On Fri, 8 Oct 2004 17:10:35 +0200 Dieter Nützel [EMAIL PROTECTED] wrote: [snip] When I set 'setenv force_s3tc_enable 1' quake3-smp do NOT start anymore. ATTENTION: default value of option force_s3tc_enable overridden by environment. Fatal error in __driConfigOptions line 75, column 0: illegal default value: 1. That's because 1 is indeed illegal for boolean options such as force_s3tc_enable. Legal values are true and false. OK, but do not help ;-) It's working for myself and Roland. What build system are you using? I only added the USE_EXTERNAL_DXTN_LIB=1 define in Mesa linux-dri (and therefore linux-dri-x86) target. If you're using something else, you'll have to add the define to whatever CFLAGS there. -- 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 I have already -DUSE_EXTERNAL_DXTN_LIB=1 in my CFLAGS , I need something more? env MESA_DEBUG=1 glxgears will produce output if it tried to do s3tc, whether it succeeds or fails. If it doesn't print anything, then the issue was with building (and strings your_dri.so | grep dxtn won't mention the lib name). If it does produce output, then the problem is probably with the lack of the library or lack of env force_s3tc_enable=true. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] I get these messages with lastest MESA : melchior:/home/melchior/driconf-0.2.2# env MESA_DEBUG=1 glxinfo name of display: :0.0 cpu vendor: AuthenticAMD cpu name: AMD Athlon(tm) XP MMX cpu detected. 3DNow! cpu detected. Testing OS support for SSE... yes. Testing OS support for SSE unmasked exceptions... SIGFPE, yes. Tests of OS support for SSE passed. SSE cpu detected. Mesa warning: software DXTn compression/decompression available Using SSE version of ReadRGBASpan display: :0 screen: 0 direct rendering: Yes But I'm not able to understand if DXTn de/compression is used or not . UT2004 backgrounds in menus are still white . Someone can check this? Thanks Marcello Hey , I've solved in setting by DRICONF 5 Texture units instead of 6 . There's something wrong in using 6 Texture units with lastest DRI drivers? Marcello --- 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 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. - ajax pgpxBCYvv8OlM.pgp Description: PGP signature
[rfc] VIA drm patch and bk tree for inclusion in kernel..
Hi, Okay the VIA DRM people have asked to include it in the kernel, it only allows accelerated XvMC for non-root users, and 3d for root users (the 3d paths are still not secure)... The bk tree at bk://drm.bkbits.net/drm-via the patch against Linus latest (along with some cleanup patches...) is at (it is quite big...) http://www.skynet.ie/~airlied/patches/dri/via_unichrome_patch.diff Can VIA people test this tree for me? either use bk or grab Linus latest and apply the patch... 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: [rfc] VIA drm patch and bk tree for inclusion in kernel..
Hi, Dave. Hi, Okay the VIA DRM people have asked to include it in the kernel, it only allows accelerated XvMC for non-root users, and 3d for root users (the 3d paths are still not secure)... The bk tree at bk://drm.bkbits.net/drm-via the patch against Linus latest (along with some cleanup patches...) is at (it is quite big...) http://www.skynet.ie/~airlied/patches/dri/via_unichrome_patch.diff Can VIA people test this tree for me? either use bk or grab Linus latest and apply the patch... I will try the patch later today. Also I'd like to clarify that the Unichrome project which has done some of the work is not in any way supported by or endorsed by VIA (the company). It is a standalone volunteer project, and thus my comments about considering the drm secure is just my personal opinion. I'm not sure, though, about whether the same applies for Erdi Chen who contributed the DMA Ring-buffer code. In any case it would be good to have a comment from Erdi about the patch since he is the guy who pointed out the security issues in the first place. Regards Thomas 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 --- 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 Sat, 9 Oct 2004, [ISO-8859-1] Thomas Hellström wrote: Hi! Just tried out the core-based drm today, and I notice that drmOpen(via) does not work anymore. What is the correct way to fix up this? I suspect my client should be using drmOpenByBusID ? This is also broken on radeon's (yesterdays code). best Vladimir Dergachev 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
Re: kern/60474: Temporary fix for DRM support for Radeon 9200
because of this patch, only r300_demo will work. Even that would be progress, no? Currently, when I move the xterm window, I can notice the screen flicker -- on Radeon 9600 and a 3GHz processor... You would get slightly faster 2d rendering, but non-CP 2d should be plenty fast for moving xterm. What kind of flicker is this ? Are you using a panel or a CRT ? best Vladimir Dergachev Thanks! Yours, -mi --- 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: Can't apply S3TC patch anymore with current Mesa
On Sat, 9 Oct 2004 14:14:29 +0200 Marcello Maggioni [EMAIL PROTECTED] wrote: [snip] Hey , I've solved in setting by DRICONF 5 Texture units instead of 6 . There's something wrong in using 6 Texture units with lastest DRI drivers? Marcello The more texture units you have the smaller the maximum texture size gets. The problem is that with N texture units you currently need to be able to have N textures of maximum size and maximum color depth bound to a texture unit. This means they all have to be in texture memory at the same time. With given texture memory that limits the maximum size of textures. Increasing the AGP size (option GARTSize) in xorg.conf would increase the amount of available texture memory which would allow larger textures too. Regards, Felix | 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: Undefined symbols in recent DRM
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. - ajax | 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: kern/60474: Temporary fix for DRM support for Radeon 9200
Mikhail, ati.patch.3 is patch for *2D* driver to enable DRI. However, at the moment, there is *NO* 3d driver for R300 cards except the binary only ati one. So yes, the DRI will be enabled. But, NO, you will not get 3d rendering because of this patch, only r300_demo will work. Even that would be progress, no? Currently, when I move the xterm window, I can notice the screen flicker -- on Radeon 9600 and a 3GHz processor... Thanks! Yours, -mi --- 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: Can't apply S3TC patch anymore with current Mesa
On Sat, 9 Oct 2004 18:00:47 +0200, Felix Kühling [EMAIL PROTECTED] wrote: On Sat, 9 Oct 2004 14:14:29 +0200 Marcello Maggioni [EMAIL PROTECTED] wrote: [snip] Hey , I've solved in setting by DRICONF 5 Texture units instead of 6 . There's something wrong in using 6 Texture units with lastest DRI drivers? Marcello The more texture units you have the smaller the maximum texture size gets. The problem is that with N texture units you currently need to be able to have N textures of maximum size and maximum color depth bound to a texture unit. This means they all have to be in texture memory at the same time. With given texture memory that limits the maximum size of textures. Increasing the AGP size (option GARTSize) in xorg.conf would increase the amount of available texture memory which would allow larger textures too. Regards, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | I've tried your hint of increasing the AGP size with GARTSize option. I've set GARTSize to 64 (an higher value give me problems in visualization ) and doesn't solve the problem . With Mesa Oct 07 2004 (and older) I can use 6 texture units without problems in UT2004 , I have this issue only with recent MESA . (I've ever used 6 texture units) This only happens with UT2004 menu backgrounds (with DOOM3 I haven't such problems) Bye --- 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 Sat, 9 Oct 2004 10:59:35 -0400 (EDT), Vladimir Dergachev [EMAIL PROTECTED] wrote: On Sat, 9 Oct 2004, [ISO-8859-1] Thomas Hellström wrote: Just tried out the core-based drm today, and I notice that drmOpen(via) does not work anymore. What is the correct way to fix up this? I suspect my client should be using drmOpenByBusID ? This is also broken on radeon's (yesterdays code). drmOpen(name) should still work. I just tried starting X with no bus id specificed and it found the driver. That should be using drmOpen(name), right? How exactly does it fail? I fixed getVersion to report the name of the personality module and not DRM so the right name should match. -- 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: drmOpen with drm-core
Hi.
Jon Smirl wrote:
On Sat, 9 Oct 2004 10:59:35 -0400 (EDT), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
On Sat, 9 Oct 2004, [ISO-8859-1] Thomas Hellstrm wrote:
Just tried out the core-based drm today, and I notice that
drmOpen("via") does not work anymore.
What is the correct way to fix up this? I suspect my client should be using
drmOpenByBusID ?
This is also broken on radeon's (yesterdays code).
drmOpen(name) should still work. I just tried starting X with no bus
id specificed and it found the driver. That should be using
drmOpen(name), right? How exactly does it fail? I fixed getVersion to
report the name of the personality module and not DRM so the right
name should match.
I think this is the debug log from the failing open. It's the XvMC
client trying to execute a
drmOpen("via",NULL);
drm:drm_stub_open]
[drm:drm_open_helper] pid = 22416, minor = 0
[drm:drm_ioctl] pid=22416, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0
[drm:drm_ioctl] pid=22416, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0
[drm:drm_release] open_count = 12
[drm:drm_release] pid = 22416, device = 0xe200, open_count = 12
[drm:drm_fasync] fd = -1, device = 0xe200
[drm:drm_stub_open]
[drm:drm_open_helper] pid = 22416, minor = 0
[drm:drm_ioctl] pid=22416, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0
[drm:drm_ioctl] pid=22416, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0
[drm:drm_release] open_count = 12
[drm:drm_release] pid = 22416, device = 0xe200, open_count = 12
[drm:drm_fasync] fd = -1, device = 0xe200
[drm:drm_stub_open]
[drm:drm_open_helper] pid = 22416, minor = 0
[drm:drm_ioctl] pid=22416, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0
[drm:drm_ioctl] pid=22416, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0
[drm:drm_ioctl] pid=22416, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=0
[drm:drm_ioctl] pid=22416, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=0
[drm:drm_release] open_count = 12
[drm:drm_release] pid = 22416, device = 0xe200, open_count = 12
[drm:drm_fasync] fd = -1, device = 0xe200
[drm:drm_stub_open]
[drm:drm_open_helper] pid = 22416, minor = 0
[drm:drm_ioctl] pid=22416, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0
[drm:drm_ioctl] pid=22416, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0
[drm:drm_release] open_count = 12
[drm:drm_release] pid = 22416, device = 0xe200, open_count = 12
[drm:drm_fasync] fd = -1, device = 0xe200
[drm:drm_stub_open]
[drm:drm_open_helper] pid = 22416, minor = 0
[drm:drm_ioctl] pid=22416, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0
[drm:drm_ioctl] pid=22416, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0
[drm:drm_release] open_count = 12
[drm:drm_release] pid = 22416, device = 0xe200, open_count = 12
[drm:drm_fasync] fd = -1, device = 0xe200
[drm:drm_stub_open]
[drm:drm_open_helper] pid = 22416, minor = 0
[drm:drm_ioctl] pid=22416, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0
[drm:drm_ioctl] pid=22416, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0
[drm:drm_ioctl] pid=22416, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=0
[drm:drm_ioctl] pid=22416, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=0
[drm:drm_release] open_count = 12
[drm:drm_release] pid = 22416, device = 0xe200, open_count = 12
[drm:drm_fasync] fd = -1, device = 0xe200
[r200] gltestperf lockup in ZSmooth Triangles
It's the worst one I've ever seen. After some seconds (during first cycle) it falsely draw a few triangles in the _upper right_ corner. Whole system lockup. Even the monitor goes into 'no signal mode'. SYSRQ didn't work. I have to press 'the button'. -Dieter BTW What about the 'texcyl' reflect bug (no reflection, empty black window)? --- 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 Saturday 09 October 2004 12:02, Felix Kühling 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 pgpNMmCNydP2V.pgp Description: PGP signature
Re: drmOpen with drm-core
On Sat, 9 Oct 2004, Jon Smirl wrote: On Sat, 9 Oct 2004 10:59:35 -0400 (EDT), Vladimir Dergachev [EMAIL PROTECTED] wrote: On Sat, 9 Oct 2004, [ISO-8859-1] Thomas Hellström wrote: Just tried out the core-based drm today, and I notice that drmOpen(via) does not work anymore. What is the correct way to fix up this? I suspect my client should be using drmOpenByBusID ? This is also broken on radeon's (yesterdays code). drmOpen(name) should still work. I just tried starting X with no bus id specificed and it found the driver. That should be using drmOpen(name), right? How exactly does it fail? I fixed getVersion to report the name of the personality module and not DRM so the right name should match. X works for me too, though I think it opens by bus id. However, r300_demo fails like this: [EMAIL PROTECTED]:/home/volodya/R300/r300_demo# make test2 sync ./r300_demo --tex-bitblt CHECKPOINT main 488 main::drmOpen: error 1 (Operation not permitted) make: *** [test2] Error 255 The code that fails is drmFD=drmOpen(radeon,NULL); If, on the other hand, I specify busid directly: drmFD=drmOpen(radeon, args_info.bus_id_arg); It works fine. Also any mode works when I use radeon driver from drm/linux-2.6. best Vladimir Dergachev -- 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
[RFC] [patch] drm core internal versioning..
An issue raised by DRM people with the new drm core is how to stop users
shotting themselves in the foot when upgrading drm modules from CVS and
mixing up cores and drivers...
This patch (against DRM CVS) proposes a simple internal version that gets
passed from the module to the core, when built in-kernel, it gets set to
default DRM_INTERNAL_VERSION_KERNEL, when built in DRM CVS or snapshot, it
gets DRM_INTERNAL_VERSION_EXTERNAL, a core built in one will refuse to
load a module build in the other..
This is quite a simple solution that should stop the most obvious issue,
it doesn't stop people updating CVS drivers on top of themselves but my
view is anyone doing this is either following our scripts or knows what
they are doing...
Dave.
Index: linux-core/Makefile
===
RCS file: /cvs/dri/drm/linux-core/Makefile,v
retrieving revision 1.17
diff -u -r1.17 Makefile
--- linux-core/Makefile 30 Sep 2004 20:25:13 - 1.17
+++ linux-core/Makefile 9 Oct 2004 23:48:31 -
@@ -282,6 +282,8 @@
# This needs to go before all other include paths.
CC += -I$(DRMSRCDIR)
+EXTRA_CFLAGS = -DDRM_INTERNVAL_VERSION=DRM_INTERNAL_VERSION_EXTERNAL
+
# Check for Red Hat's 4-argument do_munmap().
DOMUNMAP := $(shell grep do_munmap $(LINUXDIR)/include/linux/mm.h | \
grep -c acct)
Index: linux-core/drmP.h
===
RCS file: /cvs/dri/drm/linux-core/drmP.h,v
retrieving revision 1.130
diff -u -r1.130 drmP.h
--- linux-core/drmP.h 9 Oct 2004 10:58:19 - 1.130
+++ linux-core/drmP.h 9 Oct 2004 23:48:35 -
@@ -87,6 +87,13 @@
#include drm_os_linux.h
+#define DRM_INTERNAL_VERSION_KERNEL 1
+#define DRM_INTERNAL_VERSION_EXTERNAL 2
+
+#ifndef DRM_INTERNAL_VERSION
+#define DRM_INTERNAL_VERSION DRM_INTERNAL_VERSION_KERNEL
+#endif
+
/* If you want the memory alloc debug functionality, change define below */
/* #define DEBUG_MEMORY */
@@ -730,7 +737,8 @@
extern int drm_fb_loaded;
extern int __devinit drm_init(struct pci_driver *driver,
struct pci_device_id *pciidlist,
- struct drm_driver_fn *driver_fn);
+ struct drm_driver_fn *driver_fn,
+ int internal_version);
extern void __exit drm_exit(struct pci_driver *driver);
extern void __exit drm_cleanup_pci(struct pci_dev *pdev);
extern int drm_version(struct inode *inode, struct file *filp,
Index: linux-core/drm_drv.c
===
RCS file: /cvs/dri/drm/linux-core/drm_drv.c,v
retrieving revision 1.96
diff -u -r1.96 drm_drv.c
--- linux-core/drm_drv.c8 Oct 2004 14:31:25 - 1.96
+++ linux-core/drm_drv.c9 Oct 2004 23:48:37 -
@@ -74,6 +74,8 @@
#undef DRM_OPTIONS_FUNC
#endif
+static int drm_internal_version=DRM_INTERNAL_VERSION;
+
int drm_fb_loaded = 0;
/** Ioctl table */
@@ -320,7 +322,7 @@
*/
int drm_init(struct pci_driver *driver,
struct pci_device_id *pciidlist,
- struct drm_driver_fn *driver_fn)
+ struct drm_driver_fn *driver_fn, int internal_version)
{
struct pci_dev *pdev;
struct pci_device_id *pid;
@@ -332,6 +334,11 @@
drm_parse_options(drm_opts);
#endif
+ if (drm_internal_version!=internal_version) {
+ printk(Attempt to load DRM module on different core\m);
+ return -1;
+ }
+
drm_mem_init();
for (i = 0; (pciidlist[i].vendor != 0) !drm_fb_loaded; i++) {
Index: linux-core/i810_drv.c
===
RCS file: /cvs/dri/drm/linux-core/i810_drv.c,v
retrieving revision 1.46
diff -u -r1.46 i810_drv.c
--- linux-core/i810_drv.c 30 Sep 2004 21:12:05 - 1.46
+++ linux-core/i810_drv.c 9 Oct 2004 23:48:37 -
@@ -132,7 +132,7 @@
static int __init i810_init(void)
{
- return drm_init(driver, pciidlist, driver_fn);
+ return drm_init(driver, pciidlist, driver_fn, DRM_INTERNAL_VERSION);
}
static void __exit i810_exit(void)
Index: linux-core/i830_drv.c
===
RCS file: /cvs/dri/drm/linux-core/i830_drv.c,v
retrieving revision 1.13
diff -u -r1.13 i830_drv.c
--- linux-core/i830_drv.c 30 Sep 2004 21:12:05 - 1.13
+++ linux-core/i830_drv.c 9 Oct 2004 23:48:37 -
@@ -142,7 +142,7 @@
static int __init i830_init(void)
{
- return drm_init(driver, pciidlist, driver_fn);
+ return drm_init(driver, pciidlist, driver_fn, DRM_INTERNAL_VERSION);
}
static void __exit i830_exit(void)
Index: linux-core/i915_drv.c
===
RCS file: /cvs/dri/drm/linux-core/i915_drv.c,v
retrieving revision 1.7
diff -u -r1.7 i915_drv.c
--- linux-core/i915_drv.c 30 Sep 2004
Re: Can't apply S3TC patch anymore with current Mesa
Marcello Maggioni wrote: I've tried your hint of increasing the AGP size with GARTSize option. Actually, increasing GARTSize will do nothing for the r200 driver, as it doesn't really use GART memory at all (only if you use Mesa's glx memory allocator) afaik. The r200 driver uses only 1 texture heap. I've set GARTSize to 64 (an higher value give me problems in visualization ) and doesn't solve the problem . Increasing the value should do nothing, but shouldn't cause any problems neither. Not sure what's wrong here, though I vaguely remember there were some bugs mentioned with using large gart sizes and/or cards with 256MB memory (?). With Mesa Oct 07 2004 (and older) I can use 6 texture units without problems in UT2004 , I have this issue only with recent MESA . (I've ever used 6 texture units) This only happens with UT2004 menu backgrounds (with DOOM3 I haven't such problems) I didn't see any problems when I last looked at it, I'll see if I can reproduce it next week. Roland --- 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 fixed the programs in DRM cvs /tests to build. You can use them to test drmOpen like this: ./drmstat -o radeon -v It looks to me like the lower level part of drmOpen is working correctly. You need to trace into libxf86drm and see what is failing at a higher level. The ioctl nr=0 followed by nr=1 is normal for an open. Something is causing the open to be retried. It's probably something that drm is returning wrong but I don't know what it is yet. nr = 0 #define DRM_IOCTL_VERSION DRM_IOWR(0x00, drm_version_t) nr = 1 #define DRM_IOCTL_GET_UNIQUE DRM_IOWR(0x01, drm_unique_t) unique is the IOCTL that ask for the bus_id. -- 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: [RFC] [patch] drm core internal versioning..
How strong of match requirement do we need? Note that this only impacts distribution of binary personality modules, if you have source there is no problem. Several stronger solutions: on each CVS check-in to DRM increment a count and use this for an id manual version number for DRM embed the kernel version embed the kernel version plus distribution info -- 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: [RFC] [patch] drm core internal versioning..
How strong of match requirement do we need? Note that this only impacts distribution of binary personality modules, if you have source there is no problem. Not really I'm thinking more of someone building a module against one core and insmodding it against another one.. so someone builds a kernel with core/personality, then builds just a personality module from CVS and tries to use it with the kernel core one... personally I think binary distributors have the money to keep up with the kernel releases I don't want to re-implement kernel modversions which is what we are close to doing, you can't insmod a module built against a different kernel anyways so it doesn't matter, kernel version, preempt, smp, compiler are all checked on insmod in 2.6 if they don't match it doesn't load it is not possible to distrib a binarry kernel independent module.. without at least a portable stub source loader... 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: Can't apply S3TC patch anymore with current Mesa
This only happens with UT2004 menu backgrounds (with DOOM3 I haven't such problems) I didn't see any problems when I last looked at it, I'll see if I can reproduce it next week. the patch checked in is missing the bit that incresases max texture size when using compressed, as it is a hack... /* adjust max texture size a bit. Hack, but I really want to use larger textures + which will work just fine in 99.99% of all cases, especially with texture compression... */ + if (ctx-Const.MaxTextureLevels 12) ctx-Const.MaxTextureLevels += 1; + Is the code from the original patch in r200_context.c 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
