From: A V N. M. R. <nm...@sa...> - 2000-03-14 17:59:08
|
Hi, When can i expect i810 dri kernel module ready???? Thanks & Regards, --------------------------------------- Muni Reddy Silicon Automation Systems Ph. +91(80)5281461 ext 4137 --------------------------------------- |
From: Keith W. <ke...@pr...> - 2000-03-14 19:33:33
|
A V Naga Muni Reddy wrote: > > Hi, > > When can i expect i810 dri kernel > module ready???? > The agpgart module is already existant in recent 2.3 kernels. The i810 dri module should appear on the trunck of the dri sourceforge tree later this week. Keith |
From: Doug R. <df...@ca...> - 2000-03-15 11:48:55
|
On Tue, 14 Mar 2000, Keith Whitwell wrote: > A V Naga Muni Reddy wrote: > > > > Hi, > > > > When can i expect i810 dri kernel > > module ready???? > > > > The agpgart module is already existant in recent 2.3 kernels. > > The i810 dri module should appear on the trunck of the dri sourceforge tree > later this week. > > Keith Who maintains the agpgart module? There are some serious problems with the way the various ioctl numbers are constructed which will make it difficult to emulate under other operating systems. -- Doug Rabson Mail: df...@ca... Technical Director, Qube Software Ltd. Phone: +44 171 431 9995 |
From: Jeff H. <jha...@pr...> - 2000-03-15 17:55:52
|
Doug Rabson wrote: > > Who maintains the agpgart module? There are some serious problems with the > way the various ioctl numbers are constructed which will make it difficult > to emulate under other operating systems. I maintain the agpgart module. What kind of problems are there in the ioctl numbering scheme? I would very much like to see agp support on other operating systems. -Jeff |
From: Doug R. <df...@ca...> - 2000-03-15 18:21:09
|
On Wed, 15 Mar 2000, Jeff Hartmann wrote: > Doug Rabson wrote: > > > > Who maintains the agpgart module? There are some serious problems with the > > way the various ioctl numbers are constructed which will make it difficult > > to emulate under other operating systems. > > I maintain the agpgart module. What kind of problems are there in the > ioctl numbering scheme? I would very much like to see agp support on > other operating systems. The main problem is that the size argument to the various _IOW and _IOWR macros is wrong. The header agpgart.h uses pointers for this argument where it should use the base type. The sizeof this type is used by some operating systems to automate the copying of date to/from the user address space. For instance, the current declaration: _IOR(AGPIOC_BASE, 0, agp_info*) specifies that sizeof(agp_info*) bytes of information are generated by the ioctl. Since the ioctl is really providing sizeof(agp_info) bytes of information, this is a problem. The correct declaration should be: _IOR(AGPIOC_BASE, 0, agp_info) This is a fairly trivial issue and can probably be patched by the Linux emulation layer of FreeBSD but I think it ought to be fixed since it obscures what is really going on in the ioctl and may even break in a future Linux kernel implementation of ioctl. The main problem with the agpgart ioctl api is that it seems to require that the driver can maintain a certain amount of state per open file. This is not possible in FreeBSD due to the way that drivers are used by the kernel and may also be a problem for other operating systems. In practice, I'm intending to only support a subset of the agpgart api in order to allow the X server to use AGP memory for e.g. i810 frame buffers etc. For multiple client support, I will probably rely on the DRI interfaces. -- Doug Rabson Mail: df...@ca... Technical Director, Qube Software Ltd. Phone: +44 171 431 9995 |
From: Jeff H. <jha...@pr...> - 2000-03-15 19:12:15
|
Doug Rabson wrote: > > The main problem is that the size argument to the various _IOW and _IOWR > macros is wrong. The header agpgart.h uses pointers for this argument > where it should use the base type. The sizeof this type is used by some > operating systems to automate the copying of date to/from the user address > space. > > For instance, the current declaration: > > _IOR(AGPIOC_BASE, 0, agp_info*) > > specifies that sizeof(agp_info*) bytes of information are generated by the > ioctl. Since the ioctl is really providing sizeof(agp_info) bytes of > information, this is a problem. > > The correct declaration should be: > > _IOR(AGPIOC_BASE, 0, agp_info) > > This is a fairly trivial issue and can probably be patched by the Linux > emulation layer of FreeBSD but I think it ought to be fixed since it > obscures what is really going on in the ioctl and may even break in a > future Linux kernel implementation of ioctl. Sounds completely reasonable. I'll take a look at it. > > The main problem with the agpgart ioctl api is that it seems to require > that the driver can maintain a certain amount of state per open file. This > is not possible in FreeBSD due to the way that drivers are used by the > kernel and may also be a problem for other operating systems. Interesting. Having a private data area per each open file is quite useful. I've never looked at the Freebsd kernel, but can you at least get the number of the open file doing the ioctl? You could do the storage of data based on that. > > In practice, I'm intending to only support a subset of the agpgart api in > order to allow the X server to use AGP memory for e.g. i810 frame buffers > etc. For multiple client support, I will probably rely on the DRI > interfaces. Sounds reasonable. Another thing that was suggested by David Dawes is a os independant layer for agp functionality. I think this becomes quite important if the exact interface can not be replicated under other os'es. Perhaps its time to look at doing something like this in Xfree. -Jeff |
From: Doug R. <df...@ca...> - 2000-03-16 11:41:04
|
On Wed, 15 Mar 2000, Jeff Hartmann wrote: > Doug Rabson wrote: > > > > The main problem is that the size argument to the various _IOW and _IOWR > > macros is wrong. The header agpgart.h uses pointers for this argument > > where it should use the base type. The sizeof this type is used by some > > operating systems to automate the copying of date to/from the user address > > space. > > > > For instance, the current declaration: > > > > _IOR(AGPIOC_BASE, 0, agp_info*) > > > > specifies that sizeof(agp_info*) bytes of information are generated by the > > ioctl. Since the ioctl is really providing sizeof(agp_info) bytes of > > information, this is a problem. > > > > The correct declaration should be: > > > > _IOR(AGPIOC_BASE, 0, agp_info) > > > > This is a fairly trivial issue and can probably be patched by the Linux > > emulation layer of FreeBSD but I think it ought to be fixed since it > > obscures what is really going on in the ioctl and may even break in a > > future Linux kernel implementation of ioctl. > > Sounds completely reasonable. I'll take a look at it. Thanks. Fixing this will change the ABI so you might want to support the old ioctl numbers too for a while. > > > > > The main problem with the agpgart ioctl api is that it seems to require > > that the driver can maintain a certain amount of state per open file. This > > is not possible in FreeBSD due to the way that drivers are used by the > > kernel and may also be a problem for other operating systems. > > Interesting. Having a private data area per each open file is quite > useful. I've never looked at the Freebsd kernel, but can you at least > get the number of the open file doing the ioctl? You could do the > storage of data based on that. Unfortunately, the drivers are insulated from this information. We have been thinking of changing the device driver interface for FreeBSD 5.0 but that won't be released for at least a year and probably won't allow per-open-file private data either. To support the DRI (which has similar requirements), I did some handwaving and looked up the private data based on the pid but its not very satisfactory. > > > > > In practice, I'm intending to only support a subset of the agpgart api in > > order to allow the X server to use AGP memory for e.g. i810 frame buffers > > etc. For multiple client support, I will probably rely on the DRI > > interfaces. > > Sounds reasonable. Another thing that was suggested by David Dawes is a > os independant layer for agp functionality. I think this becomes quite > important if the exact interface can not be replicated under other > os'es. Perhaps its time to look at doing something like this in Xfree. I think this is the best solution since it can leverage the authentication aspects of XFree. On the other hand, isn't this exactly what the DRI interface to AGP does now? -- Doug Rabson Mail: df...@ca... Technical Director, Qube Software Ltd. Phone: +44 171 431 9995 |
From: A V N. M. R. <nm...@sa...> - 2000-03-16 21:45:45
|
Hi, I tried to load the agpgart module on i810 machine. it is reporting device / reosurce busy error. following is the message in /var/log/messages -------------------------------------------------------------------------- Mar 17 00:22:03 pcc233 kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann Mar 17 00:22:03 pcc233 kernel: agpgart: Maximum main memory to use for agp memory: 26M ------------------------------------------------------------------------- I am using gart version 0.99 and kernel version 2.3.48. Is this the latest code? --------------------------------------- Muni Reddy Silicon Automation Systems Ph.+91(80)5281461 ext 4137 --------------------------------------- |
From: A V N. M. R. <nm...@sa...> - 2000-03-16 23:30:28
|
Hi, Still in agpgart module the start of pages to insert in GTT is passed by the user through bind ioctl. If one has to insert pages he needs to check for -EBUSY errors and loop through the entire GTT. Would it be better if the driver fills up pg_start of agp_bind structure instead of user filling up. Regards, --------------------------------------- Muni Reddy Ph. 5281461 ext 4137 --------------------------------------- On Tue, 14 Mar 2000, Keith Whitwell wrote: > A V Naga Muni Reddy wrote: > > > > Hi, > > > > When can i expect i810 dri kernel > > module ready???? > > > > The agpgart module is already existant in recent 2.3 kernels. > > The i810 dri module should appear on the trunck of the dri sourceforge tree > later this week. > > Keith > |
From: Jeff H. <jha...@pr...> - 2000-03-17 00:47:51
|
A V Naga Muni Reddy wrote: > > Hi, > > Still in agpgart module the start of pages to insert in GTT > is passed by the user through bind ioctl. > > If one has to insert pages he needs to check for -EBUSY > errors and loop through the entire GTT. Would it be better if > the driver fills up pg_start of agp_bind structure instead of > user filling up. All this allocation should be done by only one process. If you need memory in the GTT you should be asking the Xserver for it (or whatever your controlling process is). Things are implemented this way so that the controlling process can know intimate details of how memory is laid out. This is very important for the I810, since you want to set tiled memory on certain regions of the aperture. If you made the kernel do the layout, then you would have to create device specific code in the kernel to make sure that the backbuffer/dcache are aligned for tiled memory. This adds complexity to the kernel that doesn't need to be there, and imposes restrictions on what you can do with agp memory. Also, the current Xserver implementation (4.0) actually locks out other applications from adding to the GTT. While the Xserver is active, the Xserver is the only one who can add memory. Only the controlling process may add things to the GTT, and while a controlling process is active, no other application can be the controlling process. Microsoft's VGART does things like you are describing I believe. I think its bad design. It enforces a policy on whoever uses it, and is not flexible. When you are designing low level system routines I think it is very important to make sure your design has the minimum of policy. Otherwise when you want to do something different you have to change the interface, or create custom drivers for each application that needs to do things differently. -Jeff |
From: A V N. M. R. <nm...@sa...> - 2000-03-17 01:24:15
|
GTT pages allocation in i810 > All this allocation should be done by only one process. If you need > memory in the GTT you should be asking the Xserver for it (or whatever > your controlling process is). What should i do if I need graphics memory when X is not up. ( like a fbdev driver ) > Things are implemented this way so that > the controlling process can know intimate details of how memory is laid > out. This is very important for the I810, since you want to set tiled > memory on certain regions of the aperture. If you made the kernel do > the layout, then you would have to create device specific code in the > kernel to make sure that the backbuffer/dcache are aligned for tiled > memory. I accept that for tiling the regions has to aligned on large boundaries and in the process fragments the GTT. But if agpgart cannot be device specific, i feel drm for i810 can serve that purpose. or There should be a mechanism by which a module ( kernel or user ) get the free regions with the necessary alignment requested. I feel lack of policy should not create lack of mechanisms. > This adds complexity to the kernel that doesn't need to be > there, and imposes restrictions on what you can do with agp memory. > Also, the current Xserver implementation (4.0) actually locks out other > applications from adding to the GTT. While the Xserver is active, the > Xserver is the only one who can add memory. Only the controlling > process may add things to the GTT, and while a controlling process is > active, no other application can be the controlling process. If i use dri can i request through dri to get a tiled memory ( of say 8 MB aligned on 8 MB boundary with some pitch say 1024 ) > > Microsoft's VGART does things like you are describing I believe. I > think its bad design. It enforces a policy on whoever uses it, and is > not flexible. When you are designing low level system routines I think > it is very important to make sure your design has the minimum of > policy. Otherwise when you want to do something different you have to > change the interface, or create custom drivers for each application that > needs to do things differently. > > -Jeff > > _______________________________________________ > Dri-devel mailing list > Dri...@li... > http://lists.sourceforge.net/mailman/listinfo/dri-devel > |
From: A V N. M. R. <nm...@sa...> - 2000-03-20 14:00:32
|
Hi, I am waiting for reply on this issue. I went through the code of drm for i810. I saw the alloc and bind ioctl's. But i am not able to see the structures needed for these ioctl's?? I think it is not yet in the CVS??? - Muni Reddy > > GTT pages allocation in i810 > > > All this allocation should be done by only one process. If you need > > memory in the GTT you should be asking the Xserver for it (or whatever > > your controlling process is). > > What should i do if I need graphics memory when X is not up. > ( like a fbdev driver ) > > > Things are implemented this way so that > > the controlling process can know intimate details of how memory is laid > > out. This is very important for the I810, since you want to set tiled > > memory on certain regions of the aperture. If you made the kernel do > > the layout, then you would have to create device specific code in the > > kernel to make sure that the backbuffer/dcache are aligned for tiled > > memory. > > I accept that for tiling the regions has to aligned on large > boundaries and in the process fragments the GTT. But if agpgart cannot > be device specific, i feel drm for i810 can serve that purpose. > > or > > There should be a mechanism by which a module ( kernel or user ) > get the free regions with the necessary alignment requested. > > I feel lack of policy should not create lack of mechanisms. > > > This adds complexity to the kernel that doesn't need to be > > there, and imposes restrictions on what you can do with agp memory. > > Also, the current Xserver implementation (4.0) actually locks out other > > applications from adding to the GTT. While the Xserver is active, the > > Xserver is the only one who can add memory. Only the controlling > > process may add things to the GTT, and while a controlling process is > > active, no other application can be the controlling process. > > If i use dri can i request through dri to get a tiled memory > ( of say 8 MB aligned on 8 MB boundary with some pitch say 1024 ) > > > > > Microsoft's VGART does things like you are describing I believe. I > > think its bad design. It enforces a policy on whoever uses it, and is > > not flexible. When you are designing low level system routines I think > > it is very important to make sure your design has the minimum of > > policy. Otherwise when you want to do something different you have to > > change the interface, or create custom drivers for each application that > > needs to do things differently. > > > > -Jeff > > |
From: Jeff H. <jha...@pr...> - 2000-03-20 17:34:30
|
A V Naga Muni Reddy wrote: > > Hi, > > I am waiting for reply on this issue. > I went through the code of drm for i810. I saw the > alloc and bind ioctl's. But i am not able to see the > structures needed for these ioctl's?? > > I think it is not yet in the CVS??? What CVS are you using? Look at mga-0-0-2-branch. > > - Muni Reddy > > > > GTT pages allocation in i810 > > > > > All this allocation should be done by only one process. If you need > > > memory in the GTT you should be asking the Xserver for it (or whatever > > > your controlling process is). > > > > What should i do if I need graphics memory when X is not up. > > ( like a fbdev driver ) You will have to write allocation routines yourself and create a user space manager for the drm. Noone has done this yet. > > > > > Things are implemented this way so that > > > the controlling process can know intimate details of how memory is laid > > > out. This is very important for the I810, since you want to set tiled > > > memory on certain regions of the aperture. If you made the kernel do > > > the layout, then you would have to create device specific code in the > > > kernel to make sure that the backbuffer/dcache are aligned for tiled > > > memory. > > > > I accept that for tiling the regions has to aligned on large > > boundaries and in the process fragments the GTT. But if agpgart cannot > > be device specific, i feel drm for i810 can serve that purpose. > > > > or > > > > There should be a mechanism by which a module ( kernel or user ) > > get the free regions with the necessary alignment requested. > > > > I feel lack of policy should not create lack of mechanisms. This is what the Xserver side of the dri provides. It creates tiled memory and aligns things correctly. It just has to be taken out of the Xserver and put into another application if you have to run without X. The lack of policy I am talking about is policy in the kernel. Putting policy in kernel code is a very bad idea. You can put this type of policy in a user space application, and it belongs there in my opinion. A kernel API should be simple and flexible, so that a user space application can use it in a variety of ways. > > > > > This adds complexity to the kernel that doesn't need to be > > > there, and imposes restrictions on what you can do with agp memory. > > > Also, the current Xserver implementation (4.0) actually locks out other > > > applications from adding to the GTT. While the Xserver is active, the > > > Xserver is the only one who can add memory. Only the controlling > > > process may add things to the GTT, and while a controlling process is > > > active, no other application can be the controlling process. > > > > If i use dri can i request through dri to get a tiled memory > > ( of say 8 MB aligned on 8 MB boundary with some pitch say 1024 ) Right now all memory allocation is static. If you need a 8 mb aligned piece of memory, you need to add that allocation to i810_dri.c. -Jeff |