sparse and DRM on non-x86
I just spent sometime looking at about a thousand errors from sparse in the DRM code. There are two main problems, first DRM makes use of opaque handles which are passed to user space. These handles can be to normal or iomem memory. Since the handles are typeless this generates a lot of sparse errors. Other data associated with the handle can be use to tell if it is normal or iomem. Second the DRM code always treats the framebuffer as if it is in IOMEM. But what about IGP type devices where the framebuffer is in main memory? These only exist on the x86 so treating their framebuffer as IOMEM works since there is no difference between IOMEM and normal memory access on an x86. Is there an example of a IGP type device on an architecture where normal and IOMEM need different access functions? I suspect DRI/DRM would break on the device. This implies that DRM should be passing back two distinct handle types, one for normal and one for IOMEM, so that the user space app will use the correct access function. This is also a pretty good argument for hiding direct framebuffer access and forcing access with read/write calls on a handle like the IA64 people want to do. Of course there are a thousand errors to browse though and I may not be interpreting everything right. -- 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: sparse and DRM on non-x86
Jon Smirl wrote: I just spent sometime looking at about a thousand errors from sparse in the DRM code. There are two main problems, first DRM makes use of opaque handles which are passed to user space. These handles can be to normal or iomem memory. Since the handles are typeless this generates a lot of sparse errors. Other data associated with the handle can be use to tell if it is normal or iomem. Second the DRM code always treats the framebuffer as if it is in IOMEM. But what about IGP type devices where the framebuffer is in main memory? These only exist on the x86 so treating their framebuffer as IOMEM works since there is no difference between IOMEM and normal memory access on an x86. The framebuffer lives in agp memory on those devices, presumably this is iomem as it appears to be memory of the agp device. Is there an example of a IGP type device on an architecture where normal and IOMEM need different access functions? I suspect DRI/DRM would break on the device. The trouble is that until one materializes, we don't really know how it will work. Until such a device comes along, I'd rather not waste time worrying about it. This implies that DRM should be passing back two distinct handle types, one for normal and one for IOMEM, so that the user space app will use the correct access function. This is also a pretty good argument for hiding direct framebuffer access and forcing access with read/write calls on a handle like the IA64 people want to do. When you say read and write and handle, do you mean read(2)/write(2) and filehandle? Or some sort of #defined read/write macros? or something else? Keith --- 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: sparse and DRM on non-x86
On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: This implies that DRM should be passing back two distinct handle types, one for normal and one for IOMEM, so that the user space app will use the correct access function. This is also a pretty good argument for hiding direct framebuffer access and forcing access with read/write calls on a handle like the IA64 people want to do. When you say read and write and handle, do you mean read(2)/write(2) and filehandle? Or some sort of #defined read/write macros? or something else? They want to use read(2)/write(2). Keith -- 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: sparse and DRM on non-x86
On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: Second the DRM code always treats the framebuffer as if it is in IOMEM. But what about IGP type devices where the framebuffer is in main memory? These only exist on the x86 so treating their framebuffer as IOMEM works since there is no difference between IOMEM and normal memory access on an x86. The framebuffer lives in agp memory on those devices, presumably this is iomem as it appears to be memory of the agp device. On normal AGP/PCI cards the memory is on the card. It is accessed over the AGP/PCI bus which requires special IO instructions on non-x86 hardware. IGP cards use the normal system memory for their buffers. You don't use the special IO instructions to access this memory. The key is where the memory lives, on the graphics card or on the motherboard. On x86 both types of memory use the same access instructions since the x86 makes AGP/PCI memory look like normal system memory. So we don't have a problem. On other platforms introduction of an IGP type device will break X/mesa since they don't know to switch from IO instruction access to normal memory access. IA64 may have already run into this on unreleased products since they have been asking questions along these lines. -- 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: sparse and DRM on non-x86
Jon Smirl wrote: On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: This implies that DRM should be passing back two distinct handle types, one for normal and one for IOMEM, so that the user space app will use the correct access function. This is also a pretty good argument for hiding direct framebuffer access and forcing access with read/write calls on a handle like the IA64 people want to do. When you say read and write and handle, do you mean read(2)/write(2) and filehandle? Or some sort of #defined read/write macros? or something else? They want to use read(2)/write(2). Hmm, not sure that's going to happen. Keith --- 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: sparse and DRM on non-x86
Jon Smirl wrote: On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: Second the DRM code always treats the framebuffer as if it is in IOMEM. But what about IGP type devices where the framebuffer is in main memory? These only exist on the x86 so treating their framebuffer as IOMEM works since there is no difference between IOMEM and normal memory access on an x86. The framebuffer lives in agp memory on those devices, presumably this is iomem as it appears to be memory of the agp device. On normal AGP/PCI cards the memory is on the card. It is accessed over the AGP/PCI bus which requires special IO instructions on non-x86 hardware. IGP cards use the normal system memory for their buffers. You don't use the special IO instructions to access this memory. The key is where the memory lives, on the graphics card or on the motherboard. On x86 both types of memory use the same access instructions since the x86 makes AGP/PCI memory look like normal system memory. So we don't have a problem. I understand this. I'm pointing out that agp memory, ie. system memory mapped into the GART table, though it is backed by system memory, is typically accessed through an io range of the gart device. So what sort of memory is that? For the Intel chipsets, again, although the framebuffer is backed by system memory, all accesses to that memory are through a device io memory range, not by reading/writing to the backing memory directly. On other platforms introduction of an IGP type device will break X/mesa since they don't know to switch from IO instruction access to normal memory access. IA64 may have already run into this on unreleased products since they have been asking questions along these lines. I've seen stuff on the web that suggests Intel wants to unify its chipsets to support both x86 and IA64, so that's not a huge suprise. It'd still be good to base any design on actual known examples rather than guesses as to what might be coming. Keith --- 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: sparse and DRM on non-x86
I note that we (HP) have just nuked our future IA64 workstations; and as we shipped the largest volume of such machines (by far), constraints there will be use of graphics cards on servers, rather than any volume... - Jim I've seen stuff on the web that suggests Intel wants to unify its chipsets to support both x86 and IA64, so that's not a huge suprise. It'd still be good to base any design on actual known examples rather than guesses as to what might be coming. --- 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: sparse and DRM on non-x86
On Fri, 01 Oct 2004 18:54:50 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: Jon Smirl wrote: On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: Second the DRM code always treats the framebuffer as if it is in IOMEM. But what about IGP type devices where the framebuffer is in main memory? These only exist on the x86 so treating their framebuffer as IOMEM works since there is no difference between IOMEM and normal memory access on an x86. The framebuffer lives in agp memory on those devices, presumably this is iomem as it appears to be memory of the agp device. On normal AGP/PCI cards the memory is on the card. It is accessed over the AGP/PCI bus which requires special IO instructions on non-x86 hardware. IGP cards use the normal system memory for their buffers. You don't use the special IO instructions to access this memory. The key is where the memory lives, on the graphics card or on the motherboard. On x86 both types of memory use the same access instructions since the x86 makes AGP/PCI memory look like normal system memory. So we don't have a problem. I understand this. I'm pointing out that agp memory, ie. system memory mapped into the GART table, though it is backed by system memory, is typically accessed through an io range of the gart device. So what sort of memory is that? GART memory is system memory. The GART is used by the graphics chip to access the main system memory. Accesses from the main CPU never travel through the GART. Only memory access cycles initiated by the GPU use the GART. For the Intel chipsets, again, although the framebuffer is backed by system memory, all accesses to that memory are through a device io memory range, not by reading/writing to the backing memory directly. That's kind of odd, they must have a cache on the graphics chip and that's how you keep it coherent. In this cause you would use the IO instructions. Direct access to the memory from CPU is probably 10x faster. For a clear/blit it would probably be better to directly access the memory and then flush the cache. What do the ATI chips do? -- 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: sparse and DRM on non-x86
--- Jon Smirl [EMAIL PROTECTED] wrote: On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: This implies that DRM should be passing back two distinct handle types, one for normal and one for IOMEM, so that the user space app will use the correct access function. This is also a pretty good argument for hiding direct framebuffer access and forcing access with read/write calls on a handle like the IA64 people want to do. When you say read and write and handle, do you mean read(2)/write(2) and filehandle? Or some sort of #defined read/write macros? or something else? They want to use read(2)/write(2). IMHO this is loonisy... You will also need to use lseek(2) since ssize_t read(int fd, void *buf, size_t count); is missing some things that mmap(2) was made to work around. I realy don't think there is ANY device on this planet that uses registers for it's framebuffer, not that registers are any diffrent from a memory stick. It's just that most IO ports arn't memory there fifos that sometimes will recall the last value writen if asked. A framebuffer by it's vary nature MUST recall the last value writen when asked, thus it's memory not an IOmaped FIFO. Keith -- 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 __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail --- 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: sparse and DRM on non-x86
--- Keith Whitwell [EMAIL PROTECTED] wrote: Jon Smirl wrote: On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: Second the DRM code always treats the framebuffer as if it is in IOMEM. But what about IGP type devices where the framebuffer is in main memory? These only exist on the x86 so treating their framebuffer as IOMEM works since there is no difference between IOMEM and normal memory access on an x86. The framebuffer lives in agp memory on those devices, presumably this is iomem as it appears to be memory of the agp device. On normal AGP/PCI cards the memory is on the card. It is accessed over the AGP/PCI bus which requires special IO instructions on non-x86 hardware. IGP cards use the normal system memory for their buffers. You don't use the special IO instructions to access this memory. The key is where the memory lives, on the graphics card or on the motherboard. On x86 both types of memory use the same access instructions since the x86 makes AGP/PCI memory look like normal system memory. So we don't have a problem. I understand this. I'm pointing out that agp memory, ie. system memory mapped into the GART table, though it is backed by system memory, is typically accessed through an io range of the gart device. So what sort of memory is that? Yes, thoguht it might help you better to view this IO port is a ?multi?point-to-point AGP bus. From the CPU, on the FSB, this memory as well as any other mmaped IO is accesed as system memory(with intructions like mov) and not IO-Ports that use in(asm) and out(asm) intructions. For the Intel chipsets, again, although the framebuffer is backed by system memory, all accesses to that memory are through a device io memory range, not by reading/writing to the backing memory directly. io memory range, still dosen't sound like an IO-Port(from the CPU's FSB PoV). This would most likely be memory-maped IO? On other platforms introduction of an IGP type device will break X/mesa since they don't know to switch from IO instruction access to normal memory access. IA64 may have already run into this on unreleased products since they have been asking questions along these lines. I've seen stuff on the web that suggests Intel wants to unify its chipsets to support both x86 and IA64, so that's not a huge suprise. It'd still be good to base any design on actual known examples rather than guesses as to what might be coming. Good, lets talk about i386's ISA bus. Most every 16bit operation is still valid, the number of bits shoulden't be an issue. Port IO uses the same Address and Data bus as memory IO, the only difference being the PORTIO bit is 1(not 0 like with memeory reads/writes). When A program wishes to use PORTIO it must use the out(asm) and in(asm) instructions. All other IO is done with a multitude of other instructions. This is why mmaped IO is the way togo, there are more operations one can do with one instruction. To go one more layer up we start talking about C. --- BOTOM LINE --- In C all memory access can be done with operators(like '='), wather it's a memory maped device or not. This is simply a product of the blocks on witch it's built. From C to asm to hardware buss, memory IO is not device(destination) specific. Port-io is the only other destination(port). We can change where memory IO goes by fideling with ports with our new fancy PCI bus, but this still dose not change the instructions(asm) or operators(C) that we use to access memory. Keith --- 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 __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.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: sparse and DRM on non-x86
Jon Smirl wrote: On Fri, 01 Oct 2004 18:54:50 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: Jon Smirl wrote: On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: Second the DRM code always treats the framebuffer as if it is in IOMEM. But what about IGP type devices where the framebuffer is in main memory? These only exist on the x86 so treating their framebuffer as IOMEM works since there is no difference between IOMEM and normal memory access on an x86. The framebuffer lives in agp memory on those devices, presumably this is iomem as it appears to be memory of the agp device. On normal AGP/PCI cards the memory is on the card. It is accessed over the AGP/PCI bus which requires special IO instructions on non-x86 hardware. IGP cards use the normal system memory for their buffers. You don't use the special IO instructions to access this memory. The key is where the memory lives, on the graphics card or on the motherboard. On x86 both types of memory use the same access instructions since the x86 makes AGP/PCI memory look like normal system memory. So we don't have a problem. I understand this. I'm pointing out that agp memory, ie. system memory mapped into the GART table, though it is backed by system memory, is typically accessed through an io range of the gart device. So what sort of memory is that? GART memory is system memory. The GART is used by the graphics chip to access the main system memory. Accesses from the main CPU never travel through the GART. Only memory access cycles initiated by the GPU use the GART. Maybe there's a problem with terminology, but when we write to agp memory in the drivers, we are definitely using the GART. Keith --- 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: sparse and DRM on non-x86
On Fri, 01 Oct 2004 21:11:54 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: Maybe there's a problem with terminology, but when we write to agp memory in the drivers, we are definitely using the GART. The GART is remapping your addresses, but it's still a normal system RAM access. Keith -- 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: sparse and DRM on non-x86
Jon Smirl wrote: On Fri, 01 Oct 2004 21:11:54 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: Maybe there's a problem with terminology, but when we write to agp memory in the drivers, we are definitely using the GART. The GART is remapping your addresses, but it's still a normal system RAM access. Hmm, maybe the i8x0 is unusual. To access the GART on those systems, when internal graphics is active, you have to map an io range of the gart device. Keith --- 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: sparse and DRM on non-x86
--- Keith Whitwell [EMAIL PROTECTED] wrote: Jon Smirl wrote: On Fri, 01 Oct 2004 21:11:54 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: Maybe there's a problem with terminology, but when we write to agp memory in the drivers, we are definitely using the GART. The GART is remapping your addresses, but it's still a normal system RAM access. Hmm, maybe the i8x0 is unusual. To access the GART on those systems, when internal graphics is active, you have to map an io range of the gart device. Maby IO in this case means MMIO vs PIO. I seriously doubt PIO would be used for anything other then setup and configuration/state mngmnt. Keith --- 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 ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.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
