Re: Accessing AGP
On Tue, Dec 28, 2004 at 09:10:12AM +0100, Thomas Hellström wrote: Vladimir Dergachev wrote: Can someone more knowledgable explain to me how to properly access AGP space from within Mesa driver ? This has just been implemented in the Unichrome driver, and I'm not sure wether it's the best or most appopriate way to do it but it works as follows: 1. The Mesa driver fills a malloced system memory buffer with vertex data. 2. The Mesa driver then calls the DRM through a via-specific IOCTL. (via_ioctl.c) 3. The via drm copies the buffer to another buffer in kernel system memory ( static storage ), (via_dma.c) 4. The via drm verifies the content of the buffer to reject buffers that contain commands that are considered harmful. (via_verifier.c) 5. The buffer is copied to AGP space, and the engine pointers are updated. (via_dma.c) The reason for 3. is that running the verifier directly on AGP memory is very slow. Is there some reason you can't run the verifier on the user-space buffers? Copying the data twice seems terribly wasteful. Enlightenment requested :) Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Accessing AGP
On Tue, Dec 28, 2004 at 09:10:12AM +0100, Thomas Hellström wrote: Vladimir Dergachev wrote: Can someone more knowledgable explain to me how to properly access AGP space from within Mesa driver ? This has just been implemented in the Unichrome driver, and I'm not sure wether it's the best or most appopriate way to do it but it works as follows: 1. The Mesa driver fills a malloced system memory buffer with vertex data. 2. The Mesa driver then calls the DRM through a via-specific IOCTL. (via_ioctl.c) 3. The via drm copies the buffer to another buffer in kernel system memory ( static storage ), (via_dma.c) 4. The via drm verifies the content of the buffer to reject buffers that contain commands that are considered harmful. (via_verifier.c) 5. The buffer is copied to AGP space, and the engine pointers are updated. (via_dma.c) The reason for 3. is that running the verifier directly on AGP memory is very slow. Is there some reason you can't run the verifier on the user-space buffers? Copying the data twice seems terribly wasteful. Hi! It's simply because nobody should be allowed to change the buffer contents after it's been verified, but before it's copied to AGP. I assume at least a multithreaded DRI application on an SMP machine would be able to do that. In reality the second copy seems to take very little time. Ideally one would write a copy_from_user_while_verifying(), but since I'm not that familiar with kernel programming, I haven't yet. /Thomas Enlightenment requested :) Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Xorg cvs problem
Looking everywhere i notice that framebuffer sets the following : RADEON_DP_DATATYPE to RADEON_HOST_BIG_ENDIAN_EN but the xfree86 drivers do not seems to worry about this register, anyway i do not think that this correct the problem but i am wondering what is the purpose of this register. framebuffer also set RADEON_RB2D_DSTCACHE_MODE to 0 for r300 chipset Anythings that may help ? I have looked in other radeon driver and found nothing, beos drivers seems to only support intel arch for r300 :(. best, Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS DRM driver for radeon needed pci=routeirq
Use the linux-core directory in CVS to build not the linux-2.6, linux-core is the future of DRM, hopefully it will be merged into 2.6.11 soon... other option is to move the pci_enable_device(pdev) line in drm_stub.h outside the if statement it is in .. Dave. On Sun, 26 Dec 2004, Chris Rankin wrote: Hi, I just tried booting the new 2.6.10 kernel with the radeon DRM module from CVS (at dri.freedesktop.org), and the IRQ was left unrouted at IRQ 11: [drm] Initialized radeon 1.13.0 20041207 on minor 0: ATI Technologies Inc RV280 [Radeon 9200] ACPI: PCI interrupt :01:00.0[A] - GSI 16 (level, low) - IRQ 16 agpgart: Found an AGP 3.0 compliant device at :00:00.0. agpgart: X passes broken AGP3 flags (1f00420f). Fixed. agpgart: Putting AGP V3 device at :00:00.0 into 8x mode agpgart: Putting AGP V3 device at :01:00.0 into 8x mode Linux video capture interface: v1.00 [drm] Loading R200 Microcode irq 16: nobody cared! [c0134344] __report_bad_irq+0x24/0x7d [c0134441] note_interrupt+0x86/0xa5 [c0133e99] __do_IRQ+0x14d/0x15c [c0104f02] do_IRQ+0x46/0x6a === [c0103732] common_interrupt+0x1a/0x20 [c010101a] default_idle+0x0/0x2f [c0101043] default_idle+0x29/0x2f [c01010aa] cpu_idle+0x2e/0x3c [c031d890] start_kernel+0x15e/0x19a [c031d312] unknown_bootoption+0x0/0x1d5 handlers: [f89c5453] (usb_hcd_irq+0x0/0x6f [usbcore]) Disabling IRQ #16 Adding the pci=routeirq option fixed things. The relevant lspci output is: 01:00.0 Class 0300: 1002:5961 (rev 01) Subsystem: 174b:7c13 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (2000ns min), cache line size 10 Interrupt: pin A routed to IRQ 16 Region 0: Memory at f000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at ec00 [size=256] Region 2: Memory at ff8f (32-bit, non-prefetchable) [size=64K] Expansion ROM at c100 [disabled] [size=128K] Capabilities: [58] AGP version 3.0 Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8 Command: RQ=32 ArqSz=2 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x8 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 01:00.1 Class 0380: 1002:5941 (rev 01) Subsystem: 174b:7c12 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (2000ns min), cache line size 10 Region 0: Memory at e800 (32-bit, prefetchable) [size=128M] Region 1: Memory at ff8e (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- I am sending you this email as requested by the dmesg output. Cheers, Chris ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Accessing AGP
This has just been implemented in the Unichrome driver, and I'm not sure wether it's the best or most appopriate way to do it but it works as follows: 1. The Mesa driver fills a malloced system memory buffer with vertex data. 2. The Mesa driver then calls the DRM through a via-specific IOCTL. (via_ioctl.c) 3. The via drm copies the buffer to another buffer in kernel system memory ( static storage ), (via_dma.c) 4. The via drm verifies the content of the buffer to reject buffers that contain commands that are considered harmful. (via_verifier.c) 5. The buffer is copied to AGP space, and the engine pointers are updated. (via_dma.c) The reason for 3. is that running the verifier directly on AGP memory is very slow. Hi Thomas, Thank you very much for the explanation :) What kind of verification of vertex data does unichrome need ? thank you ! Vladimir Dergachev /Thomas --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Xorg cvs problem
Yellow dog seems to have support for radeon 9600. At least they claim so. I tried to find out the source of their distribution but only manage to get iso for binary. Anyone got source of yellow dog ? Maybe they added the patch to xfree86, i will give look for that... Still i am a bit disapointed that i can access the source of yellow dog, what is open source if you coud not have them ? :( best, Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Accessing AGP
Hi! Vladimir Dergachev wrote: This has just been implemented in the Unichrome driver, and I'm not sure wether it's the best or most appopriate way to do it but it works as follows: 1. The Mesa driver fills a malloced system memory buffer with vertex data. 2. The Mesa driver then calls the DRM through a via-specific IOCTL. (via_ioctl.c) 3. The via drm copies the buffer to another buffer in kernel system memory ( static storage ), (via_dma.c) 4. The via drm verifies the content of the buffer to reject buffers that contain commands that are considered harmful. (via_verifier.c) 5. The buffer is copied to AGP space, and the engine pointers are updated. (via_dma.c) The reason for 3. is that running the verifier directly on AGP memory is very slow. Hi Thomas, Thank you very much for the explanation :) What kind of verification of vertex data does unichrome need ? thank you ! Vladimir Dergachev On the Unichrome it's possible to do quite a lot using AGP DMA. Some of the things that can be done are not disclosed by VIA, but apparently you can blit memory contents from more or less anywhere to more or less anywhere What the command verifier does is that it lets commands thrugh that is knows: 1. Only accesses the 2D-engine or Mpeg engine through writes. (Other areas are blocked). 2. Does not attempt to fetch memory contents from system memory. 3. Does not attempt to fetch memory contents from AGP memory that is outside the user-mappable range (textures). Frame-buffer memory is considered open territory, as is the user-mappable part of AGP-memory. Note that the AGP command buffers must NOT reside in the user-mappable parts of AGP-memory. Regards /Thomas /Thomas --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Accessing AGP
What the command verifier does is that it lets commands thrugh that is knows: 1. Only accesses the 2D-engine or Mpeg engine through writes. (Other areas are blocked). 2. Does not attempt to fetch memory contents from system memory. 3. Does not attempt to fetch memory contents from AGP memory that is outside the user-mappable range (textures). Frame-buffer memory is considered open territory, as is the user-mappable part of AGP-memory. Note that the AGP command buffers must NOT reside in the user-mappable parts of AGP-memory. I see. Thank you ! Is it true then that on Unichrome all vertex data is immediate - i.e. embedded in the command stream ? This is as opposed to saving it in a separate array in AGP memory and only issuing a command to load pointers to it via command stream. best Vladimir Dergachev Regards /Thomas /Thomas --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Accessing AGP
What the command verifier does is that it lets commands thrugh that is knows: 1. Only accesses the 2D-engine or Mpeg engine through writes. (Other areas are blocked). 2. Does not attempt to fetch memory contents from system memory. 3. Does not attempt to fetch memory contents from AGP memory that is outside the user-mappable range (textures). Frame-buffer memory is considered open territory, as is the user-mappable part of AGP-memory. Note that the AGP command buffers must NOT reside in the user-mappable parts of AGP-memory. I see. Thank you ! Is it true then that on Unichrome all vertex data is immediate - i.e. embedded in the command stream ? This is as opposed to saving it in a separate array in AGP memory and only issuing a command to load pointers to it via command stream. best Vladimir Dergachev Yes, that's true as far as I can tell. Texture data is, however, saved in AGP memory and pointed to by the command stream. This involves allocating a piece of mappable AGP memory from the drm AGP memory allocator, putting the data in it and send pointers over the command stream. /Thomas Regards /Thomas /Thomas --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI Wiki has bad snapshots links.
http://dri.freedesktop.org/wiki/Download Has links to http://www.freedesktop.org/~dri/snapshots/, that should be fixed up. I would be gald to help, but the page is immutable. __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Xorg cvs problem
Jerome Glisse schrieb: Yellow dog seems to have support for radeon 9600. At least they claim so. I tried to find out the source of their distribution but only manage to get iso for binary. On their site they state that they support only 2D, no hardware-accelerated 3D. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Xorg cvs problem
Philipp Klaus Krause wrote: Jerome Glisse schrieb: Yellow dog seems to have support for radeon 9600. At least they claim so. I tried to find out the source of their distribution but only manage to get iso for binary. On their site they state that they support only 2D, no hardware-accelerated 3D. 2D is what is matter here, we are not talking about 3D, only 2D endianness issue. Thus they may have the solution if they truely support 2D... best, Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI Wiki has bad snapshots links.
On Tuesday 28 December 2004 14:22, Mike Mestnik wrote: http://dri.freedesktop.org/wiki/Download Has links to http://www.freedesktop.org/~dri/snapshots/, that should be fixed up. I would be gald to help, but the page is immutable. This is probably a good time to mention that I've copied the wiki pages across to dri.freedesktop.org. Many links are busted because they're not proper WikiWords, and it's still immutable because the ownership on the files needs fixing. The first I can fix with a bit of sed magic, for the second I'll need a sitewrangler... - ajax pgp9EIxrvyBVs.pgp Description: PGP signature
Re: CVS DRM driver for radeon needed pci=routeirq
--- Dave Airlie [EMAIL PROTECTED] wrote: Use the linux-core directory in CVS to build not the linux-2.6, linux-core is the future of DRM, hopefully it will be merged into 2.6.11 soon... other option is to move the pci_enable_device(pdev) line in drm_stub.h outside the if statement it is in .. Thanks; I was indeed using the CVS linux-2.6 directory. All I was really looking for was the 'most stable' DRM code to use with Xorg 6.8.1, and that code did not seem to be the code that shipped with the kernel sources. (One of the 'migration' threads in 2.6.9 was consuming a lot of CPU time with the in-tree radeon module.) Is the CVS linux-2.6 directory considered 'dead', then? It seems stable enough. How stable is code in linux-core? Cheers, Chris ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS DRM driver for radeon needed pci=routeirq
Thanks; I was indeed using the CVS linux-2.6 directory. All I was really looking for was the 'most stable' DRM code to use with Xorg 6.8.1, and that code did not seem to be the code that shipped with the kernel sources. (One of the 'migration' threads in 2.6.9 was consuming a lot of CPU time with the in-tree radeon module.) the kernel tree contains the stable drm, there should be no-known issues in it :-), the development tree is in CVS, linux-core is the new style drm and this is hopefully going to be merged to the kernel rsn... Is the CVS linux-2.6 directory considered 'dead', then? It seems stable enough. How stable is code in linux-core? in my mind linux-2.6 and others are dead wood, future features in the main drm should happen in linux-core, driver features are usually added to both trees for ppl running 2.4 but CVS should be more unstable than kernel tree... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri_util.c:157: warning: pointer targets differ in signedness.
First let me say that if anyone would like to take over updating the dri-trunk-sid packages on a semi-regular basis, I'd really appreciate it. I don't track the Debian X or DRI mailing lists closely enough to keep up with changes. On Tue, 2004-12-28 at 15:00 -0800, Mike Mestnik wrote: The source I'm using contains the old DRI xc. I can see where the old xc source is needed to build the OLD Xserver and Mesa is needed there to build it's dri, glx, and opengl Xdrivers. How ever I can't see why this old xc code has not been diffed in to debian's Xfree86? Would submitting a patch to TDBTS help? I'm not a member of the Debian X team so I don't speak for them, but I wouldn't expect that a patch of DRI's changes to XFree86 will be accepted. The reason I started updating Michel Daenzer's packages was that I needed MergedFB support and wanted some of the fixes that were being incorporated into DRI. Requests for MergedFB in Debian's X packages date back to June 2003. I wouldn't imagine there will be any major changes to Debian's X until Sarge releases. At this time Xorg is used for most of the DRI development. It also seams that the dri, glx, and opengl Xdrivers can be built in the Mesa tree with libGL and the dri_ Xdrivers. Since Mesa is now able to build against Xfree86 and Xorg this would seam to fix most of the problems. This is news to me. I thought the current recommended way of doing things was to build an Xorg xserver, glx, and libgl, then build the 3D drivers in Mesa. http://dri.sourceforge.net/cgi-bin/moin.cgi/Building Rather than updating the dri-trunk-sid packages to build Xorg it might be easier to direct users to the experimental Xorg packages at http://debian.linux-systeme.com/ With a new libGL in place, installing Mesa and drm CVS by hand isn't that difficult and doesn't have to overwrite the packaged X server. It would be nice if driconf had a way of overriding LIBGL_DRIVERS_PATH on a per-user or global basis though. I got this after cvs updating the tar.gz of the unofficial debian source... This source is at least missing the DRI_NEW_INTERFACE_ONLY define dri_util.c:1073, cause it uses the xc Makefiles to build Mesa. dri_util.c: In function `glx_find_dri_screen': dri_util.c:157: warning: pointer targets in passing arg 1 of `glXGetProcAddress' differ in signedness I ran into the same problem, but this message convinced me there was little point in trying to fix it. http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg20719.html John signature.asc Description: This is a digitally signed message part
