Re: offtopic: quake3 source
Roland Scheidegger wrote: I've just noticed I have page-flipping enabled in my xorg.conf. I can't afford to crash my X session at this time, but I'll try disabling it later. Works just fine for me (x86, latest drm, latest Mesa, rv250, pageflipping, color tiling, hyperz). My xorg is a bit outdated though (one week old). Hmmm... I'm on x86_64. Perhaps it's a bug in the DRM ioctl32 code? Neverball for x86_64 works fine btw... I shall try with a 32bit version too. -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: offtopic: quake3 source
Vladimir Dergachev wrote: By the way, quake3 (original version) doesn't work any more with latest Mesa + DRM on both r200 and r300. It just hangs immediately after entering a map. Have you tried disabling some graphics options ? I just run Quake3 on somewhat old version of Mesa, but recent DRM and r300 driver. I've tried both vertex and lightmap, with no changes. Quake hangs after drawing the first frame, which looks visually correct. I think the bug is in Mesa CVS since a couple of weeks. r200 cards are also affected, so it's not an r300 specific bug. I've just noticed I have page-flipping enabled in my xorg.conf. I can't afford to crash my X session at this time, but I'll try disabling it later. -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: offtopic: quake3 source
Jacek Popławski wrote: I don't know if you are interested, but there is quake3 source available for a while... You can download it from: http://icculus.org/quake3/ By the way, quake3 (original version) doesn't work any more with latest Mesa + DRM on both r200 and r300. It just hangs immediately after entering a map. Last time I've checked, the 64bit version of quake3 (icculus version) displays garbage instead of textures. Not sure wether it's a Mesa or Quake bug. -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tester needed with a pure 64-bit system...
Dave Airlie wrote: still works... Define pure 64-bit. AFAIK, the only truly pure 64-bit system is that Alpha, but I don't think that's what you mean. :) Do you mean 64-bit kernel 64-bit X-server? Well a 64-bit kernel and 64-bit X and 64-bit glxgears linked against 64-bit libGL with a 64-bit radeon_dri.so :-) I've just rebuilt everything from CVS on my x86_64 box: - X starts with direct rendering enabled (it used to crash just a few days before); - The latest Mesa appears to be out of sync with DRM: ERROR! sizeof(RADEONDRIRec) does not match passed size from device driver - Using Mesa from xc/lib/GL/ works fine with glxgears, but I only get 1500fps on a Radeon 9200 Pro. I used to get over 4000fps a few months ago on x86. Do you want me to try specific applications? I'd like to test some 32bit stuff, but first I need to fix the RADEONDRIRec problem. -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tester needed with a pure 64-bit system...
Dave Airlie wrote: Well the main thing is that on a 64-bit/kernel and 64-bit X that X starts and DRI is enabled in the Xorg.0.log... if you send me the Xorg.0.log it would be most helpful... Attached. I can also test with an r300 board if you need it. The DRIRec is Mesa and X.org out of sync.. maybe Alan or Egbert can say why Perhaps it's just my fault: I've built xorg with the in-tree version of Mesa and then installed Mesa separately, overweiting libGL and the dri_*.so modules. This used to work for over one year, but maybe it was just luck. The thing is, I can't build xc with MesaSrcDir set to Mesa's CVS sandbox because that version contains a different set of sources and the Imakefiles need tweaking. How do the other developers do this? -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ This is a pre-release version of the The X.Org Foundation X11. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the xorg product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the The X.Org Foundation monolithic tree CVS repository hosted at http://www.freedesktop.org/Software/xorg/ X Window System Version 6.8.99.900 (6.9.0 RC 0) (Unsupported Custom Build by bernie: 6.8.2-36) Release Date: 01 August 2005 + cvs X Protocol Version 11, Revision 0, Release 6.8.99.900 Build Operating System: Linux 2.6.12-1.1482_FC5-x86_64.bernie x86_64 [ELF] Current Operating System: Linux beetle.trilan 2.6.12-1.1482_FC5-x86_64.bernie #1 Sat Aug 13 23:44:33 CEST 2005 x86_64 Build Date: 17 August 2005 Build Host: beetle.trilan Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Thu Aug 18 19:17:29 2005 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Videocard0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (WW) `fonts.dir' not found (or not valid) in /usr/X11R6/lib/X11/fonts/CID. Entry deleted from font path. (Run 'mkfontdir' on /usr/X11R6/lib/X11/fonts/CID). (WW) The directory /usr/local/share/fonts does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/openoffice does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/mathml does not exist. Entry deleted from font path. (**) FontPath set to /usr/X11R6/lib/X11/fonts/misc:unscaled,/usr/X11R6/lib/X11/fonts/75dpi:unscaled,/usr/X11R6/lib/X11/fonts/100dpi:unscaled,/usr/X11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/fonts/local,/usr/X11R6/lib/X11/fonts/TTF,/usr/X11R6/lib/X11/fonts/OTF,/usr/share/fonts/ja/TrueType,/usr/share/fonts/default/Type1,/usr/share/fonts/microsoft,/usr/share/fonts,/usr/X11R6/lib/X11/fonts,/usr/share/fonts/bitmap-fonts,/usr/share/fonts/bitstream-vera,/usr/share/fonts/default,/usr/share/fonts/ja (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/local/xorg/lib64/modules (**) Option AllowMouseOpenFail yes (**) Extension XEVIE is enabled (**) Extension RENDER is enabled (II) No APM support in BIOS or kernel (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.7 X.Org XInput driver : 0.4 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/local/xorg/lib64/modules/fonts/libbitmap.so (II) Module bitmap: vendor=X.Org Foundation compiled for 6.8.99.900, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/local/xorg/lib64/modules/libpcidata.so (II) Module pcidata: vendor=X.Org Foundation compiled for 6.8.99.900, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 (++) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,0282 card 1043,80a3 rev 00 class 06,00,00 hdr 80 (II) PCI: 00:00:1: chip 1106,1282 card , rev 00 class 06,00,00 hdr 00 (II) PCI: 00:00:2: chip 1106,2282 card , rev 00 class 06,00,00 hdr 00 (II) PCI: 00:00:3: chip 1106,3282 card , rev 00 class 06,00,00 hdr 00 (II) PCI: 00:00:4: chip 1106,4282 card , rev 00 class 06,00,00 hdr 00 (II) PCI: 00:00:7: chip 1106,7282 card , rev 00 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b188 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:07:0: chip 1106,3044 card 1043,808a rev 80 class 0c,00,10 hdr 00 (II) PCI: 00:0a:0: chip 11ab,4320 card 1043,811a rev 13 class 02,00,00 hdr 00 (II) PCI: 00:0f:0: chip 1106,3149 card 1043,80ed rev 80 class 01,04,00
Re: DRM_CAS bug with x86_64
Alan Coopersmith wrote: I was wondering why ffb was even being built on x86_64. If it's referring to the board from Sun (which marketing called a Creator or Creator 3D), it was only ever made for the UPA bus (UltraSPARC Port Architecture), not PCI or any other common bus, and I've never seen a UPA bus outside of a SPARC machine. It's enabled in Mesa/configs/linux-dri, and I pasted the list over into my host.def to customize the list of drivers. I've left ffb there by mistake. ffb is also included on x86 and ia64 in DevelDriDrivers. Those drivers are only built when BuildDevelDRIDrivers is set. Today I must have been reading imake's configuration files for too long... Need some rest :-) -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM_CAS bug with x86_64
Hello,
this patch fixes two x86_64 problems in Xorg. These changes
should probably be propagated upstream to Mesa and DRM
(both lists are in Cc).
GAS choked on the DRM_CAS invocation in ffb_lock.h because
__ret was declared as int and so it gets passed in %edx
instead of %dl or %dh as required by the setnz instruction.
I just wrapped the declaration with DRM_CAS_RESULT() as done
elsewhere.
I also noticed that the various copies of xf86drm.h are slightly
out of sync. One copy used __AMD64__, which isn't a valid GCC
predefine. So the slow version of DRM_CAS was being used on x86_64.
Index: ./extras/drm/libdrm/xf86drm.h
===
RCS file: /cvs/xorg/xc/extras/drm/libdrm/xf86drm.h,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 xf86drm.h
--- ./extras/drm/libdrm/xf86drm.h 15 Jun 2005 18:31:52 - 1.1.1.2
+++ ./extras/drm/libdrm/xf86drm.h 8 Aug 2005 21:06:14 -
@@ -287,7 +287,7 @@ typedef struct _drmSetVersion {
#define DRM_LOCK_CONT 0x4000U /** Hardware lock is contended */
#if defined(__GNUC__) (__GNUC__ = 2)
-# if defined(__i386) || defined(__AMD64__)
+# if defined(__i386) || defined(__amd64__)
/* Reflect changes here to drmP.h */
#define DRM_CAS(lock,old,new,__ret)\
do { \
Index: extras/Mesa/src/mesa/drivers/dri/ffb/ffb_lock.h
===
RCS file: /cvs/xorg/xc/extras/Mesa/src/mesa/drivers/dri/ffb/ffb_lock.h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 ffb_lock.h
--- extras/Mesa/src/mesa/drivers/dri/ffb/ffb_lock.h 16 Jun 2004 09:17:59
- 1.1.1.1
+++ extras/Mesa/src/mesa/drivers/dri/ffb/ffb_lock.h 8 Aug 2005 21:06:14
-
@@ -15,7 +15,7 @@ extern void ffbXMesaUpdateState(ffbConte
#else
#define LOCK_HARDWARE(fmesa) \
do { \
-int __ret=0; \
+DRM_CAS_RESULT(__ret); \
DRM_CAS(fmesa-driHwLock, fmesa-hHWContext, \
(DRM_LOCK_HELD | fmesa-hHWContext), __ret);\
if (__ret) { \
--
// Bernardo Innocenti - Develer S.r.l., RD dept.
\X/ http://www.develer.com/
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 support
=134576304, total64=7948829, used64=8005760,addr64=8005796 bernie: i=21, idx64=8005816, total64=21488, used64=2008,addr64=-12808 bernie: i=22, idx64=10387328, total64=134576304, used64=7999476,addr64=0 bernie: i=23, idx64=7204845, total64=10390632, used64=134573272,addr64=-12744 bernie: i=24, idx64=134573768, total64=524288, used64=8006844,addr64=0 bernie: i=25, idx64=-12744, total64=10299249, used64=521,addr64=3 bernie: i=26, idx64=7203007, total64=8005760, used64=134592792,addr64=7999476 bernie: i=27, idx64=134573272, total64=-12696, used64=7203007,addr64=134573272 bernie: i=28, idx64=64, total64=-12664, used64=-12648,addr64=134573272 bernie: i=29, idx64=16777217, total64=134575092, used64=7999476,addr64=134570408 bernie: i=30, idx64=7210738, total64=8005760, used64=512,addr64=-135269416 bernie: i=31, idx64=-12600, total64=-134736292, used64=512,addr64=0 glxgears32[4460]: segfault at 0008 rip 006dec48 rsp cdec error 6 ---cut--- Some of those numbers look weird to me, but I'm not sure what the correct values should look like. Any idea? (I'm leaving for vacation today and won't be able to read my mail for a few days). -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 support
Bernardo Innocenti wrote: Maybe the fields of RADEONInfoRec should be reworked to use types with a predefined size. Is that right? I've just found out I didn't apply dri-32-compat.patch, which already addresses this problem. Sorry for the noise. -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 support
Bernardo Innocenti wrote:
Now libGL works, but something else fails and 32bit
clients fall back to indirect rendering:
After digging around with GDB, I can now elaborate a
bit more.
The call to drmMap() fails because it attempts to
map 0 bytes of memory. We're in r300/radeon_screen.c:radeonCreateScreen():
screen-mmio.handle = dri_priv-registerHandle;
screen-mmio.size = dri_priv-registerSize;
if (drmMap(sPriv-fd,
screen-mmio.handle, screen-mmio.size, screen-mmio.map)) {
dri_priv points to a RADEONInfoRec, which is filled
in by the server side in XF86DRIGetDeviceInfo().
The contents seem to be borked, perhaps because many
fields arn't the same size in the 64bit server side.
The full contents are:
deviceID = 16723,
width = 1400,
height = 1050,
depth = 24,
bpp = 32,
IsPCI = 0,
AGPMode = 8,
frontOffset = 0,
frontPitch = 1408,
backOffset = 23789568,
backPitch = 1408,
depthOffset = 29704192,
depthPitch = 1408,
textureOffset = 35651584,
textureSize = 98566144,
log2TexGran = 21,
registerHandle = 4225761280,
registerSize = 0,
statusHandle = 524288,
statusSize = 0,
gartTexHandle = 378144,
gartTexMapSize = 0,
log2GARTTexGran = 4096,
textureSize = 98566144,
log2TexGran = 21,
registerHandle = 4225761280,
registerSize = 0,
statusHandle = 524288,
statusSize = 0,
gartTexHandle = 378144,
gartTexMapSize = 0,
log2GARTTexGran = 4096,
gartTexOffset = 0,
sarea_priv_offset = 3224379392
Which is perhaps more readable in hex:
deviceID = 0x4153,
width = 0x578,
height = 0x41a,
depth = 0x18,
bpp = 0x20,
IsPCI = 0x0,
AGPMode = 0x8,
frontOffset = 0x0,
frontPitch = 0x580,
backOffset = 0x16b,
backPitch = 0x580,
depthOffset = 0x1c54000,
depthPitch = 0x580,
textureOffset = 0x220,
textureSize = 0x5e0,
log2TexGran = 0x15,
registerHandle = 0xfbe0,
registerSize = 0x0,
statusHandle = 0x8,
statusSize = 0x0,
gartTexHandle = 0xc0101000,
gartTexMapSize = 0x0,
log2GARTTexGran = 0x1000,
textureSize = 0x5e0,
log2TexGran = 0x15,
registerHandle = 0xfbe0,
registerSize = 0x0,
statusHandle = 0x8,
statusSize = 0x0,
gartTexHandle = 0xc0101000,
gartTexMapSize = 0x0,
log2GARTTexGran = 0x1000,
gartTexOffset = 0x0,
sarea_priv_offset = 0xc0302000
Maybe the fields of RADEONInfoRec should be reworked
to use types with a predefined size. Is that right?
--
// Bernardo Innocenti - Develer S.r.l., RD dept.
\X/ http://www.develer.com/
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 support
Donnie Berkholz wrote: Bernardo Innocenti wrote: Is there a reason why this code is not appropriate for merging into the official DRM? You might like to follow https://bugs.freedesktop.org/show_bug.cgi?id=943. Thank you! I fetched the latest patch and it applied quite nicely to the patched drm tree in r300 CVS, and the modules still work fine with 64bit clients. I had some hard time trying to build a working 32bit libGL.so. GL clients crashed and GDB also crashed while debugging them. Finally, I discovered that ld was linking a few x86_64 objects from libdrm without even issuing an hard error. Damnit, building 32bit stuff in a 64bit is quite tricky! Now libGL works, but something else fails and 32bit clients fall back to indirect rendering: ---cut--- # LIBGL_DEBUG=verbose ./glxgears32 libGL: XF86DRIGetClientDriverName: 4.0.1 r300 (screen 0) libGL: OpenDriver: trying /usr/local/xorg/lib/modules/dri/r300_dri.so bernie: drmOpen = 0xf7d74738 or 0xf7f6a8d0 bernie: drmOpen=0xf7f6a8d0(NULL,pci::01:00.0) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:00.0 libGL error: radeonCreateScreen: drmMap failed libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering 1918 frames in 5.0 seconds = 383.600 FPS ---cut--- -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
ioctl32 support
Hello, I extracted this patch by Egbert Eich from SuSe's kernel source package: http://www.develer.com/drm-ioctl32.patch It allows running 32bit DRI clients on 64bit systems, which is a very common situation due to proprietary games. Is there a reason why this code is not appropriate for merging into the official DRM? If nobody else is interested, I'd like to try rebasing the patch with the current CVS code. I have near-zero previous experience with it, so I'll probably need help. -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Doom3 works on R200!
Dave Airlie wrote: r200 render path looks really A LOT better, unfortunately the open-source driver doesn't implement the required extensions (some bits of documentation are missing afaik, and even if not (I have no idea what's in the documentation or not) it would probably quite a bit of work as core mesa doesn't support them neither (mostly ATI_(text_)fragment_shader). Well I've started it, but it'll take me a while to finish off the software implementation, Eric thinks he can do the hardware side (I think I can probably do it as well.. but I'll try and get the software side working first hopefully...) Thank you for doing this work. We really need to get the open-source ATI driver on par with the propretary driver (both feature-wise and performance-wise). Even though I just have a Radeon 9200, I'm very excited about the ongoning R300 effort and with there was a similar project for NVidia cards too. -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- 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: [Mesa3d-dev] Doom3 works on R200!
Dieter Nützel wrote: Thank you for doing this work. We really need to get the open-source ATI driver on par with the propretary driver (both feature-wise and performance-wise). But sadly we will NEVER match it. NO SmoothVision, HyperZ docu ever Do you really need the datasheet to get these to work? Some time ago I disassembled ATI's fglrx kernel module and their DRI module. The asm output looks quite readable: you can see symbol names and accesses to PCI registers (base ptr + offset). I'm not familiar with 3D hardware, but my rough guess is that you could easily guess what the registers if you know what the GL extensions are supposed to do and see what values are written in registers. IANAL, but reverse engineering is perfectly legal here in Europe and probably even in the USA if your goal is achieving compatibility. Even though I just have a Radeon 9200, I'm very excited about the ongoning R300 effort and with there was a similar project for NVidia cards too. Above applies here, too. - Sorry. The situation seems to be much worse in the future. Bad IP (TRIPS, etc.) madness due to USA-law. This is certaily bad, but not as bad as being unable to develop the driver at all. You may implement patented algorithms and restrict its use in some countries. I can freely use the S3TC extension here because it's not (yet) patentable. Any US developer could write it and even compile it, as long as he doesn't sell it in his country. -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- 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: [Mesa3d-dev] Doom3 works on R200!
Dieter Nützel wrote: The asm output looks quite readable: you can see symbol names and accesses to PCI registers (base ptr + offset). A bad original for DRI;-) This information should only be used to write a header file describing the registers. Of course I'm not talking about cutting pasting asm code into the open-source DRI module ;-) I'm not familiar with 3D hardware, but my rough guess is that you could easily guess what the registers if you know what the GL extensions are supposed to do and see what values are written in registers. Some are on it for ages, but. Perhaps I'm underestimating the complexity behind that code... I seemed to me that there was not too much glue code between the module API and the hardware registers. IANAL, but reverse engineering is perfectly legal here in Europe and probably even in the USA if your goal is achieving compatibility. If we didn't get another IP right (software patents, which we didn't have today, even if the EPÜ/EPC did it falsely the US-way) in Europe. The new patent law is still being discussed. The current convention explicitly disallows patenting computer programs, mathematical methods and the like: http://www.european-patent-office.org/legal/epc/e/ar52.html BTW Which is the official Italian standpoint. European Commision Draft or Parliament (later is against)? Italy has always been vaguely against the new software patent law. AFAIK, the strongest supporter of this regulation is Irland (where Microsoft's European HQ is, along with many other big corporations). The law will be discussed again in the Parliament... let's hope not too many politicians will already have been bought by that time. I can freely use the S3TC extension here because it's not (yet) patentable. Yes, but IS falsely by the EPÜ/EPC... ...and solved with Roland's work;-) Who I'm very grateful to for his clever hack. Let's hope the distributors can license that code from VIA. Microsoft did so for DX9. Any US developer could write it and even compile it, as long as he doesn't sell it in his country. Somewhat to simple I think. Well, WANL (We Are Not Lawyers)... -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- 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
Doom3 works on R200!
Hello, I just wanted to report success running the Linux native version of Doom 3 with the open-source ATI driver with only minor glitches. Congratulations: you've beated ATI's propretary driver which still doesn't work properly with Doom :-) To get it working, I've built the latest CVS snapshots of xorg, dri and Mesa, plus the external S3TC library: http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html For the past few days, I couldn't get Mesa to build in the xorg tree with working direct-rendering. So I've applied Adam's recent patch to build GLX in Mesa's tree: http://sourceforge.net/mailarchive/forum.php?thread_id=5797905forum_id=5154 The patch doesn't care update the Makefile to install the dri modules, so I had to install the manually. I also had to change the modules path hardcoded in libGL by adding -DDEFAULT_DRIVER_DIR=\/usr/local/xorg/lib/modules/dri\ to CFLAGS. The DRM linux-core worked fine with 2.6.9 (almost vanilla), of course after disabling the in-kernel version. I hope the new core can soon be dropped in Linus's tree or at least in -mm. After installing all this stuff, everything was fine with glxinfo, glxgears and et, while doom3 was just crashing. This was easily fixed with the LD_PRELOAD trick: LD_PRELOAD=/usr/local/xorg/lib/libGL.so.1 doom3 Speed with my 9200 is almost as good as with Wine's version: 15 to 30fps depending on the scene complexity, with a usual rate of 22-25fps. The only thing I'm complaining about is the light torch: the aura looks good, but the projected light circle is invisible most of the times. Other lightning effects look fine, including dangling lights in ceilings. I also noticed that wine + Doom3.exe doesn't work any more (blue window complaining about OPENGL32.DLL missing). I'm not sure if it's caused by new Mesa or new Wine, but I could investigate. -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- 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
