Menu
▾
▴
dri-devel
|
From: <bug...@bu...> - 2003-06-05 20:27:46
|
[This e-mail has been automatically generated.] Please do not reply to this email. if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=314 ei...@xf... changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|dev...@bu... |dri- | |de...@li... Severity|major |enhancement Platform| |All ------- Additional Comments From ei...@xf... 2003-06-05 16:26 ------- Do you think setting this to major will make people work harder? This is not a bug. It should be addressed to DRI. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-06-05 20:33:38
|
[This e-mail has been automatically generated.] Please do not reply to this email. if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=314 ------- Additional Comments From the...@sa... 2003-06-05 16:32 ------- No, I just don't know how to file a bug report. This is my first one. Sorry. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-06 22:04:49
|
[This e-mail has been automatically generated.] Please do not reply to this email. if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=314 ------- Additional Comments From al...@xf... 2003-07-06 18:03 ------- Try the new drivers which are compiled against the current CVS. To get them goto http://www.xfree86.org/~alanh ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-06 22:34:20
|
[This e-mail has been automatically generated.] Please do not reply to this email. if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=314 ------- Additional Comments From mh...@ww... 2003-07-06 18:33 ------- Hi Christopher, The problem isn't that 3D isn't supported by DRI, but rather that the Linux kernel does not yet support agpgart on Radeon IGP chipsets, and without working agpgart, you have no DRI. Theoretically it may be possible to use pcigart, by using ForcePCIMode, but I've no idea if there are other problems that would prevent that from working or not. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: Luis R. R. <mc...@ru...> - 2003-07-07 13:37:41
|
> ------- Additional Comments From mh...@ww... 2003-07-06 18:33 ------- > Hi Christopher, > > The problem isn't that 3D isn't supported by DRI, but rather that the Linux > kernel does not yet support agpgart on Radeon IGP chipsets, and without working > agpgart, you have no DRI. Theoretically it may be possible to use pcigart, > by using ForcePCIMode, but I've no idea if there are other problems that would > prevent that from working or not. Is this one of the many reasons why Radeon IGP 320/340M chips aren't yet supported too? Luis |
|
From: <bug...@bu...> - 2003-07-08 12:34:37
|
[This e-mail has been automatically generated.] Please do not reply to this email. if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=314 ------- Additional Comments From fr...@e-... 2003-07-08 08:33 ------- Alan, I tried your drivers and the only difference that I noticed is that the card gets detected with its real name looking DRI, it's disabled for my card. glxgears goes ~ 220 fps, and 3d gl games are dog slow (2-5 fps). I tried with ForcePCIMode too. My gpu is an igp340. Hope this helps ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-08 12:53:35
|
[This e-mail has been automatically generated.] Please do not reply to this email. if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=314 ------- Additional Comments From al...@xf... 2003-07-08 08:52 ------- Ah, sorry. I misread the subject. Indeed there is no 3D support for IGP. I don't know of anyone working on it either. Sorry. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-08 13:44:36
|
[This e-mail has been automatically generated.] Please do not reply to this email. if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=314 ------- Additional Comments From ag...@ya... 2003-07-08 09:43 ------- Dave Jones has the databooks for the ATI AGP controller (not the graphics chip), but hasn't written agpgart support yet. once that is done, I would imagine it wouldn't be too hard to add DRI support to the chips. Then again, no one has IGP databooks so who knows... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-08 14:06:53
|
[This e-mail has been automatically generated.] Please do not reply to this email. if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=314 ------- Additional Comments From fr...@e-... 2003-07-08 10:05 ------- Alan, no problem, and thank you for your drivers anyway. Alex, yeah, I'm lurking in dri-devel for this problem and I noticed Dave Jones's email. And from his diary seems the linux agp driver for this thingie is 33% done, so let's hope ;) Anyway, if I can help with testing or everything I can do drop me a mail, fredi at e-salute dot it ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-17 22:33:02
|
http://bugs.xfree86.org/show_bug.cgi?id=314 ------- Additional Comments From j.w...@st... 2003-17-07 18:31 ------- I have written an agpgart driver that probes the chipset (IGP320M) and sets up the GART in 1-level GATT mode, with the TLB and the GART cache disabled. I have no idea if it is useful in any way like this, but it works with the test programs from Dave Jones' website. Probably it isn't useful without the TLB enabled, but I haven't figured why this isn't working yet. Wouter Bijlsma -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-19 15:12:59
|
http://bugs.xfree86.org/show_bug.cgi?id=314 ------- Additional Comments From hy...@ip... 2003-19-07 11:11 ------- Here are the patches for the code on my system. It's in very early stage, for test only. What's working: 4x data rate on IGP320/340 internal graphics. Mesa demos, TuxRacer and Chromium run fine. Q3A has texture problem on some scenes. What's not: 1x and 2x data rate. external graphics (if you have a desktop version motherboard). RS300 (IGP9100) not finished. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-19 15:22:39
|
http://bugs.xfree86.org/show_bug.cgi?id=314 ------- Additional Comments From hy...@ip... 2003-19-07 11:21 ------- Created an attachment (id=415) --> (http://bugs.xfree86.org/attachment.cgi?id=415&action=view) Linux kernel patch for ATI IGP chipsets The patch is built against the 2.4.18 on my system. It uses default 2-level GART, most of code is identical to the code used for AMD Irongate. Make sure you have CONFIG_AGP_ATI turned on when compiling. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-19 15:33:45
|
http://bugs.xfree86.org/show_bug.cgi?id=314 ------- Additional Comments From hy...@ip... 2003-19-07 11:32 ------- Created an attachment (id=416) --> (http://bugs.xfree86.org/attachment.cgi?id=416&action=view) ATI IGP chipset DRI support This is built on top of current XFree86 CVS code. Changes are made in all 2D, DRI kernel, and 3D client drivers, mostly for framebuffer base adjustment to fit into UMA on IGP chipset. I haven't tested if this will break things on regular cards, so don't apply this unless you want to test IGP320/340. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-22 11:22:43
|
http://bugs.xfree86.org/show_bug.cgi?id=314 ------- Additional Comments From fr...@e-... 2003-22-07 07:21 ------- Thank you Hui for doing this, The kernel patch does not apply cleanly to vanilla 2.4.18 neither 2.4.19. I applied it by hand against 2.4.18(*) whitch is the most close with your patch. The patch against xfree-cvs does not applied cleanly too (obviously as it's against a cvs version) against cvs of yesterday (2003-07-21), so I applied it by hand too. Now the kernel during boot gives me this nice info :) : Jul 22 02:35:51 matrix kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann Jul 22 02:35:51 matrix kernel: agpgart: Maximum main memory to use for agp memory: 409M Jul 22 02:35:51 matrix kernel: agpgart: Detected ATI IGP330/340/345/350/M chipset Jul 22 02:35:51 matrix kernel: agpgart: AGP aperture is 64M @ 0xf4000000 Jul 22 02:35:51 matrix kernel: [drm] AGP 0.99 on Unknown @ 0xf4000000 64MB Jul 22 02:35:51 matrix kernel: [drm] Initialized radeon 1.1.1 20010405 on minor 0 But unfortunately after compiling xfree with the patch too, when starting X I get an kernel oops: Jul 22 02:36:17 matrix modprobe: modprobe: Can't locate module char-major-10-134 Jul 22 02:36:22 matrix modprobe: modprobe: Can't locate module char-major-81 Jul 22 02:36:22 matrix kernel: [drm:radeon_do_init_cp] *ERROR* could not find framebuffer! Jul 22 02:36:22 matrix kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000010 Jul 22 02:36:22 matrix kernel: printing eip: Jul 22 02:36:22 matrix kernel: c01c72e7 Jul 22 02:36:22 matrix kernel: *pde = 1b721067 Jul 22 02:36:22 matrix kernel: *pte = 00000000 Jul 22 02:36:22 matrix kernel: Oops: 0000 Jul 22 02:36:22 matrix kernel: CPU: 0 Jul 22 02:36:22 matrix kernel: EIP: 0010:[radeon_do_cleanup_cp+55/320] Not tainted Jul 22 02:36:22 matrix kernel: EIP: 0010:[<c01c72e7>] Not tainted Jul 22 02:36:22 matrix kernel: EFLAGS: 00013246 Jul 22 02:36:22 matrix kernel: eax: 00000000 ebx: dd588180 ecx: 00000000 edx: 00000000 Jul 22 02:36:22 matrix kernel: esi: c1757800 edi: dc1b7f08 ebp: c1757800 esp: dc1b7eb8 Jul 22 02:36:22 matrix kernel: ds: 0018 es: 0018 ss: 0018 Jul 22 02:36:22 matrix kernel: Process X (pid: 1071, stackpage=dc1b7000) Jul 22 02:36:22 matrix kernel: Stack: c01c38b0 c170f388 dc61db80 dc61db80 dd588180 c01c6af6 c1757800 00000000 Jul 22 02:36:22 matrix kernel: 000000c4 00000138 dc1b7f04 dc61dc40 dc1b7f08 c1757800 dcfb4c80 dc292400 Jul 22 02:36:22 matrix kernel: c01c7466 c1757800 dc1b7f08 00000054 00000001 00000898 00000000 40000000 Jul 22 02:36:22 matrix kernel: Call Trace: [radeon_alloc+80/128] [radeon_do_init_cp+134/2112] [radeon_cp_init+118/128] [rade on_ioctl+205/304] [sys_ioctl+185/448] Jul 22 02:36:22 matrix kernel: Call Trace: [<c01c38b0>] [<c01c6af6>] [<c01c7466>] [<c01c1e0d>] [<c0143e39>] Jul 22 02:36:22 matrix kernel: [system_call+51/56] Jul 22 02:36:22 matrix kernel: [<c0107337>] Jul 22 02:36:22 matrix kernel: Jul 22 02:36:22 matrix kernel: Code: 8b 50 10 85 d2 74 0b 8b 40 04 85 c0 0f 85 8a 00 00 00 8b 83 Maybe I've forgotten to include something in the kernel build? I have the framebuffer compiled in the kernel (not modular), the selected driver is radeon, but the same happens with vesafb too. But FWIK the kernel's framebuffer driver is not used by xfree so I can not understand this oops. Any sugestions welkomed. BTW, as for your comments about the patch working in agp4 only I added this in my XF86Config-4 (Including all the Device section for completeness): Section "Device" Identifier "device1" VendorName "ATI Technologies Inc" BoardName "ATI Radeon" Driver "radeon" Option "DPMS" Option "AGPMode" "4" <- This is what I added EndSection I tried agptool too and here's the output with your patch: agptool by Dave Jones. <da...@su...> Found AGP host bridge. 1002:cab2 :-1002:cab2 Host capabilities: Compliant with version 2.0 of the AGP standard. It is capable of doing x4 AGP, but AGP transfers are currently disabled. Found AGP graphics card. 1002:4337 :-1002:4337 Card capabilities: Compliant with version 2.0 of the AGP standard. It is capable of doing x4 AGP, but AGP transfers are currently disabled. System is capable of doing x4 AGP. rate before: f000217 setting rate to f000214 Here's the output without your patch: agptool by Dave Jones. <da...@su...> Found AGP host bridge. 1002:cab2 :-1002:cab2 Host capabilities: Compliant with version 2.0 of the AGP standard. It is capable of doing x4 AGP, but is not initialised. Found AGP graphics card. 1002:4337 :-1002:4337 Card capabilities: Compliant with version 2.0 of the AGP standard. It is capable of doing x4 AGP, but is not initialised. System is capable of doing x4 AGP. Couldn't open /dev/agpgart (*) I tried the kernel patch to apply to vanilla 2.4.22-pre7 too but from kernel 2.4.21 there is no num_of_masks member to the agp_bridge_data struct. I'll look at the conversion of the other drivers, the change in the kernel happened during 2.4.21. Hope this helps, and of course if you need some test being done, just ask. Bye, Fredi -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-22 13:11:18
|
http://bugs.xfree86.org/show_bug.cgi?id=314 ------- Additional Comments From j.w...@st... 2003-22-07 09:04 ------- Hi Hui, I also tried your patches, but with different success. The kernel patch worked ok for me (vanilla 2.4.18, nu patch problems). AGP and DRM initialize fine. When I run the patched CVS X (4.3.99.8) it hardlocks on 2.4.18. I got it to load only once. When I checked the logfiles, there were some DRI/DRM error messages like '[drm] cannot open /dev/dri/card0: Device or resource busy' and '[dri] - driCreateScreen failed'. Or something like that. I haven't been able to reproduce the logs, because right now the whole thing hardlocks the system. The problem seems to be in the X build, because testgart and agptool work fine. Agptool output and XFree86 settings are exactly identical to Frederik Nosi's (see posting above). So I tried porting the agpgart driver to 2.5.73, which was pretty easy. Again no problems with testgart and agptool, and X starts without crashing. Sadly, still no direct rendering. The logfiles only said '[W] agp: AGP disabled' . Maybe this is because of a version check or something? Anyways I would like to keep testing new patches, especially with the driver ported to 2.5. Do you have an indication when your XFree patch is going to be merged into XFree-CVS? Wouter -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-22 14:04:56
|
http://bugs.xfree86.org/show_bug.cgi?id=314 ------- Additional Comments From hy...@ip... 2003-22-07 10:03 ------- Thanks for testing. One thing I can think of about the error you got is that you might have loaded the original radeon dri module come with the Linux kernel source. This module is not patched and should not be used. You should use the patched one inside XFree86 source tree (either replace radeon.o in your default module path or insert the patched one manually). The kernel agpgart patch is built on the kernel source from a retail CD (just something handy on my system), it shouldn't be difficult to apply it manually as you did. The XFree radeon driver in CVS has been changed these two days, if you want the patch to be applied cleanly you can get the original version with xf-4_3_99_8 tag. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-22 14:23:21
|
http://bugs.xfree86.org/show_bug.cgi?id=314 ------- Additional Comments From fr...@e-... 2003-22-07 10:22 ------- > Thanks for testing. Thank you for your work Hui, > One thing I can think of about the error you got is that you might have > loaded the original radeon dri module come with the Linux kernel source. > This module is not patched and should not be used. Stupid me (good news for the patch :) ), I compiled (statically) the drm module of the kernel. Maybe I should not test things in 2:00 of the morning. > You should use the > patched one inside XFree86 source tree (either replace radeon.o in your > default module path or insert the patched one manually). Sure, expect my reports tomorrow as from now I'll be offline. About the patches, it was trivial applying by hand them, so no problem, it was just to inform you. I wonder how happened to Wouter to apply cleanly, just now I downloaded the 2.4.18 vanilla and I get rejects ;) I forgot to run the Oops through ksymoops, here is the output just in case: >>EIP; c01c72e7 <radeon_do_cleanup_cp+37/140> <===== Trace; c01c38b0 <radeon_alloc+50/80> Trace; c01c6af6 <radeon_do_init_cp+86/840> Trace; c01c7466 <radeon_cp_init+76/80> Trace; c01c1e0d <radeon_ioctl+cd/130> Trace; c0143e39 <sys_ioctl+b9/1c0> Trace; c0107337 <system_call+33/38> Code; c01c72e7 <radeon_do_cleanup_cp+37/140> 00000000 <_EIP>: Code; c01c72e7 <radeon_do_cleanup_cp+37/140> <===== 0: 8b 50 10 mov 0x10(%eax),%edx <===== Code; c01c72ea <radeon_do_cleanup_cp+3a/140> 3: 85 d2 test %edx,%edx Code; c01c72ec <radeon_do_cleanup_cp+3c/140> 5: 74 0b je 12 <_EIP+0x12> Code; c01c72ee <radeon_do_cleanup_cp+3e/140> 7: 8b 40 04 mov 0x4(%eax),%eax Code; c01c72f1 <radeon_do_cleanup_cp+41/140> a: 85 c0 test %eax,%eax Code; c01c72f3 <radeon_do_cleanup_cp+43/140> c: 0f 85 8a 00 00 00 jne 9c <_EIP+0x9c> Code; c01c72f9 <radeon_do_cleanup_cp+49/140> 12: 8b 83 00 00 00 00 mov 0x0(%ebx),%eax Bye, Fredi -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-22 14:33:42
|
http://bugs.xfree86.org/show_bug.cgi?id=314 ------- Additional Comments From hy...@ip... 2003-22-07 10:32 ------- Hi Wouter, my previous message is the reply to Frederik Nosi (you got in before I sent). You may have the same problem as Frederik -- loaded the original radeon DRI kernel module (radeon.o) from the Linux kernel tree. Make sure you used the patched one in xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ As for when the patch is going to be merged into XFree-CVS, it probably won't until it's merged into DRI project first and tested there. I used the XFree CVS code because that's somethng handy on my system. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-22 15:45:37
|
http://bugs.xfree86.org/show_bug.cgi?id=314 ------- Additional Comments From mi...@da... 2003-22-07 11:44 ------- The correct thing to do then would be to bump the DRM minor version and only attempt to initialize the DRI on IGP chips if the DRM has high enough a minor version. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-22 21:40:12
|
http://bugs.xfree86.org/show_bug.cgi?id=314 ------- Additional Comments From mi...@da... 2003-22-07 17:39 ------- This could become a backwards compatibility nightmare, as the framebuffer aperture is currently hardcoded everywhere to be at 0. :\ At the very least, the DRM minor version must be bumped, new entries must only be added at the end of structs used for communication between components, and each component must be careful only to use them if they are known to contain valid values. However, as a different memory layout is desirable for other reasons like video capturing, we should make another attempt at a discussion to get it right once and for all, probably on dri-devel but at least including people like Ben Herrenschmidt and Vladimir Dergachev as well. Here's an idea for a scheme to preserve at least some level of backwards compatibility: Add a new ioctl for the X server to tell the DRM 'I want to use the new memory layout'. Unless this is called, everything keeps working as it is now (i.e. things like DRI on IGP chips or video capturing won't work). Otherwise, the DRM bumps its major version as well. The 3D driver is adapted to cope with both major DRM versions. This would provide backwards compatibility for the new 3D driver with old X servers / DRMs / hardware. Old 3D drivers would stop working with the combination of new X server and new DRM, but this might be as good as it gets in terms of backwards compatibility. Or maybe someone else has a better idea? -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: Keith W. <ke...@tu...> - 2003-07-22 21:53:20
|
I don't think we can get away with breaking older clients, though this does look like it would only break the situation where you have old 3d client with new 2d driver, which is a slightly unusual situation. The real question is how much does the 3d client actually rely on the radeon memory layout? It gets pointers to most things it cares about in the initialization messages, these could be adjusted to point to the correct places in the new layout. Further, if a client is known to be old, the kernel can go through its commands & adjust them for the new layout (assuming we can't dupe the client into using the right values for itself). I'd prefer this approach (in addition to the turn-on ioctl) to anything that involves bumping the major version. Keith > ------- Additional Comments From mi...@da... 2003-22-07 17:39 ------- > This could become a backwards compatibility nightmare, as the framebuffer > aperture is currently hardcoded everywhere to be at 0. :\ At the very least, the > DRM minor version must be bumped, new entries must only be added at the end of > structs used for communication between components, and each component must be > careful only to use them if they are known to contain valid values. > > However, as a different memory layout is desirable for other reasons like video > capturing, we should make another attempt at a discussion to get it right once > and for all, probably on dri-devel but at least including people like Ben > Herrenschmidt and Vladimir Dergachev as well. > > Here's an idea for a scheme to preserve at least some level of backwards > compatibility: Add a new ioctl for the X server to tell the DRM 'I want to use > the new memory layout'. Unless this is called, everything keeps working as it is > now (i.e. things like DRI on IGP chips or video capturing won't work). > Otherwise, the DRM bumps its major version as well. The 3D driver is adapted to > cope with both major DRM versions. This would provide backwards compatibility > for the new 3D driver with old X servers / DRMs / hardware. Old 3D drivers would > stop working with the combination of new X server and new DRM, but this might be > as good as it gets in terms of backwards compatibility. Or maybe someone else > has a better idea? > |
|
From: Michel <mi...@da...> - 2003-07-22 22:26:59
|
On Tue, 2003-07-22 at 23:53, Keith Whitwell wrote: > I don't think we can get away with breaking older clients, though this does > look like it would only break the situation where you have old 3d client with > new 2d driver, which is a slightly unusual situation. Yes, I think the 2D driver and in particular the DRM are much more likely to be old. > The real question is how much does the 3d client actually rely on the radeon > memory layout? It gets pointers to most things it cares about in the > initialization messages, these could be adjusted to point to the correct > places in the new layout. I'm afraid this doesn't work, e.g. - rmesa->hw.ctx.cmd[CTX_RB3D_COLOROFFSET] = rmesa->state.color.drawOffset; + rmesa->hw.ctx.cmd[CTX_RB3D_COLOROFFSET] = rmesa->state.color.drawOffset+rmesa->radeonScreen->fbBase; and rmesa->state.color.drawOffset = rmesa->radeonScreen->frontOffset; but rmesa->state.color.drawOffset probably needs to stay the same for software rendering? (it seems to be used as an offset into the framebuffer mapping) > Further, if a client is known to be old, the kernel can go through its > commands & adjust them for the new layout This might actually work, nifty. :) I wonder how much effort this would take and/or whether it would have an impact on performance though. > I'd prefer this approach (in addition to the turn-on ioctl) to anything that > involves bumping the major version. Well, if this works, we might actually get away without bumping the major, which would be great... let's hope this works out taking into consideration everything including video capturing, radeonfb, ... -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
|
From: Keith W. <ke...@tu...> - 2003-07-22 22:32:18
|
Michel D=E4nzer wrote: > On Tue, 2003-07-22 at 23:53, Keith Whitwell wrote: >=20 >>I don't think we can get away with breaking older clients, though this = does=20 >>look like it would only break the situation where you have old 3d clien= t with=20 >>new 2d driver, which is a slightly unusual situation. >=20 >=20 > Yes, I think the 2D driver and in particular the DRM are much more > likely to be old. >=20 >=20 >=20 >>The real question is how much does the 3d client actually rely on the r= adeon=20 >>memory layout? It gets pointers to most things it cares about in the=20 >>initialization messages, these could be adjusted to point to the correc= t=20 >>places in the new layout. >=20 >=20 > I'm afraid this doesn't work, e.g. >=20 > - rmesa->hw.ctx.cmd[CTX_RB3D_COLOROFFSET] =3D rmesa->state.color.draw= Offset; > + rmesa->hw.ctx.cmd[CTX_RB3D_COLOROFFSET] =3D rmesa->state.color.draw= Offset+rmesa->radeonScreen->fbBase; >=20 > and >=20 > rmesa->state.color.drawOffset =3D rmesa->radeonScreen->frontOffset; >=20 > but rmesa->state.color.drawOffset probably needs to stay the same for > software rendering? (it seems to be used as an offset into the > framebuffer mapping) >=20 >=20 >=20 >>Further, if a client is known to be old, the kernel can go through its=20 >>commands & adjust them for the new layout >=20 >=20 > This might actually work, nifty. :) I wonder how much effort this would > take and/or whether it would have an impact on performance though. A slight impact, but that's the price you pay for backwards compatibility= . If=20 people want max performance, they can upgrade to a newer 3d client. In a= ny=20 case, I doubt it would be measurable. >=20 >>I'd prefer this approach (in addition to the turn-on ioctl) to anything= that=20 >>involves bumping the major version. >=20 >=20 > Well, if this works, we might actually get away without bumping the > major, which would be great... let's hope this works out taking into > consideration everything including video capturing, radeonfb, ... More than great - necessary. We can't be bumping the major number withou= t=20 very good reason, and I just don't see that here. Keith |
|
From: <bug...@bu...> - 2003-07-23 02:51:04
|
http://bugs.xfree86.org/show_bug.cgi?id=314 ------- Additional Comments From hy...@ip... 2003-22-07 22:49 ------- The patch doesn't really break any existing code. You can apply the patch and all supported cards should still work (if not, it's a bug). I've tested a 7500 breifly with the patch applied, everything worked properly. All it changes is a fb_offset added when sending a fb location related packet (like ColorOffset, DepthOffset, TxOffset). For all regular cards this fb_offset is set to zero and FB_LOCATION is not changed. I haven't tried any video capture thing though, but don't think there will be a big compatibity issue. All existing IGP boards only have TV-out, no video-in feature. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2003-07-23 08:07:34
|
http://bugs.xfree86.org/show_bug.cgi?id=314 ------- Additional Comments From mat...@la... 2003-23-07 04:06 ------- I tried to apply your agp patch to a 2.4.21. I had to do it by hand and I get an error while compiling at this line: agp_bridge.num_of_masks = 1; I read that there was some agp cleanup since the 2.4.20. I simply removed this line from the source code and it compiles but my card (IGP 340M) is not detected by the kernel. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
Thanks for helping keep SourceForge clean.
X