From: Ian R. <id...@us...> - 2005-08-18 23:55:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There's been quite a bit of discussion about this on #dri-devel the past few days. I thought I'd write up a quick summary and post it to the list. I know that there are a lot of interested parties that are on the list, but who don't hang out in #dri-devel. :) As described in an old message[1], the new memory manager will be partially in the kernel and partially in user space. The discussions in IRC have focused on the interface between the two. Listed below are the functions that have been discussed. The names are just made up. initialize_pool - Initialze a new memory pool. This will be called once for each memory pool (e.g., on-card, AGP, PCI, etc.). get_pool_state - When a new process starts up it needs to know the state of a pool. That is, it needs to know which regions are allocated or not allocated. Since all allocations / frees are written to a log that is stored in a circular buffer, it is possible for the log to wrap around between times when a given processes the log. In that case the process will also need to use this function. force_log_update - The kernel updates its view of memory periodically when processes call into it. It is possible (though very unlikely) that a process could wrap the log between these occurances. The process can detect this and, before wrapping the log, call this function so that the kernel can update its view of memory. backup_region - Regions can be marked with a "preserve" bit. This means that the contents have to be saved before the memory can be reclaimed. backup_region instructs the kernel to do this for a specified portion of a region. restore_region - Restores the contents of a previously backed-up region to a new location. Depending on how backup_region is implemented, this function may not be necessary. alloc_id_block - Each region is tracked by a unique ID. This function allocates a block of these IDs to a process. They will be automatically reclaimed if the process dies. release_id_block - Releases a block of previously allocated IDs. [1] http://marc.theaimsgroup.com/?l=mesa3d-dev&m=111101398019810&w=2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDBR+BX1gOwKyEAw8RAklnAJ9IGE2jxdkEFHFCRxPqbCXLoLP7AwCeOcA9 wE73NbJLz1PCjREtxjNNV5o= =iB2G -----END PGP SIGNATURE----- |
From: Aapo T. <ae...@ra...> - 2005-08-19 18:27:40
|
On Thu, 18 Aug 2005 16:53:37 -0700 Ian Romanick <id...@us...> wrote: > [1] http://marc.theaimsgroup.com/?l=mesa3d-dev&m=111101398019810&w=2 Couple links on the subject: http://doom-ed.com/john-carmack/virtualized-video-card-local-memory-is-the-right-thing.html http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220050168472%22.PGNR.&OS=DN/20050168472&RS=DN/20050168472 -- Aapo Tahkola |
From: Stephane M. <mar...@ic...> - 2005-08-21 15:16:24
|
Ian Romanick a =E9crit : >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >There's been quite a bit of discussion about this on #dri-devel the past >few days. I thought I'd write up a quick summary and post it to the >list. I know that there are a lot of interested parties that are on the >list, but who don't hang out in #dri-devel. :) > >As described in an old message[1], the new memory manager will be >partially in the kernel and partially in user space. The discussions in >IRC have focused on the interface between the two. Listed below are the >functions that have been discussed. The names are just made up. > >initialize_pool - Initialze a new memory pool. This will be called once >for each memory pool (e.g., on-card, AGP, PCI, etc.). > >get_pool_state - When a new process starts up it needs to know the state >of a pool. That is, it needs to know which regions are allocated or not >allocated. Since all allocations / frees are written to a log that is >stored in a circular buffer, it is possible for the log to wrap around >between times when a given processes the log. In that case the process >will also need to use this function. > >force_log_update - The kernel updates its view of memory periodically >when processes call into it. It is possible (though very unlikely) that >a process could wrap the log between these occurances. The process can >detect this and, before wrapping the log, call this function so that the >kernel can update its view of memory. > >backup_region - Regions can be marked with a "preserve" bit. This means >that the contents have to be saved before the memory can be reclaimed. >backup_region instructs the kernel to do this for a specified portion of >a region. > >restore_region - Restores the contents of a previously backed-up region >to a new location. Depending on how backup_region is implemented, this >function may not be necessary. > > =20 > As you said on IRC, this might not be needed. >alloc_id_block - Each region is tracked by a unique ID. This function >allocates a block of these IDs to a process. They will be automatically >reclaimed if the process dies. > >release_id_block - Releases a block of previously allocated IDs. > > =20 > Now, there is one question that sounds to me like it will have=20 implications over the whole memory manager design : do we want to=20 enforce video memory ownership ? Stephane |
From: Stephane M. <mar...@ic...> - 2005-08-23 14:13:41
|
Stephane Marchesin wrote: > Now, there is one question that sounds to me like it will have > implications over the whole memory manager design : do we want to > enforce video memory ownership ? > Ok, here is what came out of the irc meeting : - we don't need to enforce video memory ownership, but the drm needs to be able to track allocation owners anyway, for example if a process dies unexpectedly. - regions that are marked as "preserve" have a matching backing store region in system ram. That region is made of pinned pages. Stephane |
From: Ian R. <id...@us...> - 2005-08-23 16:48:10
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Marchesin wrote: > Stephane Marchesin wrote: > >> Now, there is one question that sounds to me like it will have >> implications over the whole memory manager design : do we want to >> enforce video memory ownership ? > > Ok, here is what came out of the irc meeting : > - we don't need to enforce video memory ownership, but the drm needs to > be able to track allocation owners anyway, for example if a process dies > unexpectedly. Correct. The kernel can do that tracking via the log. Each process gets a block of region IDs from the kernel. Each time a process makes an allocation, it writes the offset, size, and ID to the log. > - regions that are marked as "preserve" have a matching backing store > region in system ram. That region is made of pinned pages. Okay. There are also regions that are maked as 'pinned'. The only regions that should need this marking are memory areas that are being scanned out (e.g., cursor, current front buffer, etc.) by the video hardware. We'll eventually want to be able to move those regions, but I think we can skip that for now. The thing that killed this project for me the first time around was trying to tackle everything all at once. I've been told that I have a big mouth, but I can only bite off so much at once. ;) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDC1MvX1gOwKyEAw8RAvz9AJ9pd2Wy7B6rgV72n/Tb3ipdhZPIgQCfXfar WOxN/CBydERASH8ZDFocmlQ= =yx/R -----END PGP SIGNATURE----- |
From: Keith P. <ke...@ke...> - 2005-08-23 16:50:39
|
On Tue, 2005-08-23 at 16:22 +0200, Stephane Marchesin wrote: > Ok, here is what came out of the irc meeting : > - we don't need to enforce video memory ownership, but the drm needs to > be able to track allocation owners anyway, for example if a process dies > unexpectedly. How expensive would it be to protect one processes video memory from another? I would like to be able to run applications for different users on the screen at the same time and prevent both reading and writing of the images. If not possible on current hardware, what would it take from new hardware to make this possible? > - regions that are marked as "preserve" have a matching backing store=20 > region in system ram. That region is made of pinned pages. Do they really need to be pinned? That's a huge waste of memory. -keith |
From: Ian R. <id...@us...> - 2005-08-23 17:00:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Keith Packard wrote: > On Tue, 2005-08-23 at 16:22 +0200, Stephane Marchesin wrote: > >>Ok, here is what came out of the irc meeting : >>- we don't need to enforce video memory ownership, but the drm needs to >>be able to track allocation owners anyway, for example if a process dies >>unexpectedly. > > How expensive would it be to protect one processes video memory from > another? I would like to be able to run applications for different users > on the screen at the same time and prevent both reading and writing of > the images. If not possible on current hardware, what would it take from > new hardware to make this possible? You'd need the same stuff that you need to protect system memory. You'd need a hardware MMU that could block the accesses. It might be possible to do it in software by looking at the command stream, but I suspect that would be pretty expensive. It would be worth a try, I suppose. >>- regions that are marked as "preserve" have a matching backing store >>region in system ram. That region is made of pinned pages. > > Do they really need to be pinned? That's a huge waste of memory. We had this discussion too. The problem is you need the memory allocated in advance to avoid the allocation failures when the kernel needs to back up the data. If the memory isn't pinned, it can get paged out, and, apparently, the kernel can page-in user pages in the way that we want. Dave Airlie made some comments about that, but I don't remember exactly what he said. Ideally, we want to reserve some pages, but we don't care about their contents. When the kernel needs to back the data, it just needs to get a bunch of blank pages. Dave also mentioned that there were some "dirty kernel tricks" that would allow that, but that it might not be portable (to BSD) or even stable across Linux kernel versions. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDC1YsX1gOwKyEAw8RAvqkAJ9qfMowGZ6e1B0ejRJaLX3X9gKRrACeNim7 oUZia1N544Mzvx/sLx2mtNs= =G8iT -----END PGP SIGNATURE----- |
From: Michel <mi...@da...> - 2005-08-23 17:32:18
|
On Tue, 2005-08-23 at 10:00 -0700, Ian Romanick wrote: >=20 > Keith Packard wrote: > > On Tue, 2005-08-23 at 16:22 +0200, Stephane Marchesin wrote: > >=20 > >>Ok, here is what came out of the irc meeting : > >>- we don't need to enforce video memory ownership, but the drm needs to > >>be able to track allocation owners anyway, for example if a process die= s > >>unexpectedly. > >=20 > > How expensive would it be to protect one processes video memory from > > another? I would like to be able to run applications for different user= s > > on the screen at the same time and prevent both reading and writing of > > the images. If not possible on current hardware, what would it take fro= m > > new hardware to make this possible? >=20 > You'd need the same stuff that you need to protect system memory. You'd > need a hardware MMU that could block the accesses. It might be possible > to do it in software by looking at the command stream, but I suspect > that would be pretty expensive. It would be worth a try, I suppose. Yeah, I don't expect it to be prohibitive; we're basically doing just that for Radeons already. Another part would be to only allow mapping owned parts of the framebuffer. --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Stephane M. <mar...@ic...> - 2005-08-23 17:59:41
|
Michel D=C3=A4nzer wrote: >>You'd need the same stuff that you need to protect system memory. You'= d >>need a hardware MMU that could block the accesses. It might be possibl= e >>to do it in software by looking at the command stream, but I suspect >>that would be pretty expensive. It would be worth a try, I suppose. >=20 >=20 > Yeah, I don't expect it to be prohibitive; we're basically doing just > that for Radeons already. Well, right now any app can use BITBLT_MULTI to read/write to others=20 video memory, for example. Not that it's a problem to me, or that I wish=20 to solve it by auditing all the dri drivers to add the necessary checks := ) As for the performance, what is done right now (checking that the offset=20 falls within a given region) is some orders of magnitude simpler than=20 what we would have to do (checking the offset against all regions=20 allocated by a process). Also, with the current log design for the memory manager, it is possible=20 for a rogue process to make the log wrap and not call the=20 force_log_update ioctl, thus being able to create some kind of race=20 condition where the drm believes it still owns the memory but another=20 process has allocated it. >=20 > Another part would be to only allow mapping owned parts of the > framebuffer. >=20 You'd have to get the cliprects from a trusted source then... Stephane |
From: Ian R. <id...@us...> - 2005-08-23 18:04:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Marchesin wrote: > Also, with the current log design for the memory manager, it is possible > for a rogue process to make the log wrap and not call the > force_log_update ioctl, thus being able to create some kind of race > condition where the drm believes it still owns the memory but another > process has allocated it. The log design presents numerous opportunities for rogue processes to do bad things. At some level, that's inherent in the nature of direct rendering. If you don't trust the processes, don't enable direct rendering. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDC2UmX1gOwKyEAw8RArVVAKCUqkLLjCc0r3EkW5HrKDqbAZTRAgCfcCF6 Iam+OSVg2EOiNOY39EhlkYA= =P5mt -----END PGP SIGNATURE----- |
From: Ville <sy...@sc...> - 2005-08-23 19:02:14
|
On Tue, Aug 23, 2005 at 11:04:22AM -0700, Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Stephane Marchesin wrote: >=20 > > Also, with the current log design for the memory manager, it is possi= ble > > for a rogue process to make the log wrap and not call the > > force_log_update ioctl, thus being able to create some kind of race > > condition where the drm believes it still owns the memory but another > > process has allocated it. >=20 > The log design presents numerous opportunities for rogue processes to d= o > bad things. At some level, that's inherent in the nature of direct > rendering. If you don't trust the processes, don't enable direct rende= ring. Considering one of the major uses for direct rendering is games I don't=20 think that idea will work. --=20 Ville Syrj=E4l=E4 sy...@sc... http://www.sci.fi/~syrjala/ |
From: Alan C. <al...@lx...> - 2005-08-23 20:23:15
|
> The log design presents numerous opportunities for rogue processes to do > bad things. At some level, that's inherent in the nature of direct > rendering. If you don't trust the processes, don't enable direct rendering. Thats a very poor answer to the problem. DRI needs to be moving towards being more secure, and building in assumptions of insecurity just makes it worse when better cards are used. Its critical that the kernel knows what memory on the video space is being used for command queue and protects it. From the description of the SiS turboqueue I suspect you may be able to root a sis video box that way but without full docs I can't tell. Other stuff like textures is merely annoyance value. Knowing who owned a block for cleanup matters and the DRI lock/mem handling on some chips already handles it. Its also cheap because you only have to track some kind of texture handles not pages for cleanup. Alan |
From: Stephane M. <mar...@ic...> - 2005-08-23 22:31:40
|
Alan Cox wrote: >>The log design presents numerous opportunities for rogue processes to do >>bad things. At some level, that's inherent in the nature of direct >>rendering. If you don't trust the processes, don't enable direct rendering. > > > Thats a very poor answer to the problem. DRI needs to be moving towards > being more secure, and building in assumptions of insecurity just makes > it worse when better cards are used. Security is more than just the memory manager. To enforce video memory protection, we'd have to audit the code and add memory protection to existing drm modules. That is quite a lot of work, and requires extensive knowledge of each card. So I don't think it's worth the trouble with current cards. > > Its critical that the kernel knows what memory on the video space is > being used for command queue and protects it. From the description of > the SiS turboqueue I suspect you may be able to root a sis video box > that way but without full docs I can't tell. > Protecting a statically assigned command queue is one thing (something similar to what's currently done on radeon would be sufficient), protecting dynamically allocated video memory is another. > Other stuff like textures is merely annoyance value. Knowing who owned a > block for cleanup matters and the DRI lock/mem handling on some chips > already handles it. Its also cheap because you only have to track some > kind of texture handles not pages for cleanup. Actually, the long term idea is to have both dri and ddx allocate from the same memory pool. So we can't rely on texture handles for that. Stephane |
From: Vladimir D. <vo...@mi...> - 2005-08-23 23:19:43
|
On Wed, 24 Aug 2005, Stephane Marchesin wrote: > Alan Cox wrote: >>> The log design presents numerous opportunities for rogue processes to do >>> bad things. At some level, that's inherent in the nature of direct >>> rendering. If you don't trust the processes, don't enable direct >>> rendering. >> >> >> Thats a very poor answer to the problem. DRI needs to be moving towards >> being more secure, and building in assumptions of insecurity just makes >> it worse when better cards are used. > > Security is more than just the memory manager. To enforce video memory > protection, we'd have to audit the code and add memory protection to > existing drm modules. That is quite a lot of work, and requires extensive > knowledge of each card. So I don't think it's worth the trouble with current > cards. Something like that has already been added to R300 driver and should not be portable to radeon and r200. best Vladimir Dergachev |
From: Michel <mi...@da...> - 2005-08-24 02:49:57
|
On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote: > Alan Cox wrote: > >>The log design presents numerous opportunities for rogue processes to d= o > >>bad things. At some level, that's inherent in the nature of direct > >>rendering. If you don't trust the processes, don't enable direct rende= ring. > >=20 > >=20 > > Thats a very poor answer to the problem. DRI needs to be moving towards > > being more secure, and building in assumptions of insecurity just makes > > it worse when better cards are used. >=20 > Security is more than just the memory manager. To enforce video memory=20 > protection, we'd have to audit the code and add memory protection to=20 > existing drm modules. That is quite a lot of work, and requires=20 > extensive knowledge of each card. So I don't think it's worth the=20 > trouble with current cards. I still think 'we may not succeed 100%, at least in the short term' is a bad excuse for not trying, but that seems to be mostly me. > > Its critical that the kernel knows what memory on the video space is > > being used for command queue and protects it. From the description of > > the SiS turboqueue I suspect you may be able to root a sis video box > > that way but without full docs I can't tell. >=20 > Protecting a statically assigned command queue is one thing (something=20 > similar to what's currently done on radeon would be sufficient),=20 > protecting dynamically allocated video memory is another. If the DRM operated on memory objects instead of with offsets directly, it should be trivial: It only has to check that the caller has permission to access the memory objects involved. > > Other stuff like textures is merely annoyance value. Knowing who owned = a > > block for cleanup matters and the DRI lock/mem handling on some chips > > already handles it. Its also cheap because you only have to track some > > kind of texture handles not pages for cleanup. >=20 > Actually, the long term idea is to have both dri and ddx allocate from=20 > the same memory pool. So we can't rely on texture handles for that. May I ask why we can't, assuming this is done via EXA callbacks into the DDX driver that use the shared memory manager? --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Ville <sy...@sc...> - 2005-08-24 03:52:46
|
On Tue, Aug 23, 2005 at 10:49:28PM -0400, Michel D=E4nzer wrote: > On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote: > > Alan Cox wrote: > > > Its critical that the kernel knows what memory on the video space i= s > > > being used for command queue and protects it. From the description = of > > > the SiS turboqueue I suspect you may be able to root a sis video bo= x > > > that way but without full docs I can't tell. > >=20 > > Protecting a statically assigned command queue is one thing (somethin= g=20 > > similar to what's currently done on radeon would be sufficient),=20 > > protecting dynamically allocated video memory is another. >=20 > If the DRM operated on memory objects instead of with offsets directly, > it should be trivial: It only has to check that the caller has > permission to access the memory objects involved. To make this bullet proof it would also have to make sure the operation i= s=20 clipped so that it doesn't extend beyond the allocated memory. --=20 Ville Syrj=E4l=E4 sy...@sc... http://www.sci.fi/~syrjala/ |
From: Brian P. <bri...@tu...> - 2005-08-24 15:20:01
|
Michel D=C3=A4nzer wrote: > On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote: >=20 >>Alan Cox wrote: >> >>>>The log design presents numerous opportunities for rogue processes to= do >>>>bad things. At some level, that's inherent in the nature of direct >>>>rendering. If you don't trust the processes, don't enable direct ren= dering. >>> >>> >>>Thats a very poor answer to the problem. DRI needs to be moving toward= s >>>being more secure, and building in assumptions of insecurity just make= s >>>it worse when better cards are used. >> >>Security is more than just the memory manager. To enforce video memory=20 >>protection, we'd have to audit the code and add memory protection to=20 >>existing drm modules. That is quite a lot of work, and requires=20 >>extensive knowledge of each card. So I don't think it's worth the=20 >>trouble with current cards. >=20 >=20 > I still think 'we may not succeed 100%, at least in the short term' is = a > bad excuse for not trying, but that seems to be mostly me. >=20 >=20 >=20 >>>Its critical that the kernel knows what memory on the video space is >>>being used for command queue and protects it. From the description of >>>the SiS turboqueue I suspect you may be able to root a sis video box >>>that way but without full docs I can't tell. >> >>Protecting a statically assigned command queue is one thing (something=20 >>similar to what's currently done on radeon would be sufficient),=20 >>protecting dynamically allocated video memory is another. >=20 >=20 > If the DRM operated on memory objects instead of with offsets directly, > it should be trivial: It only has to check that the caller has > permission to access the memory objects involved. >=20 >=20 >=20 >>>Other stuff like textures is merely annoyance value. Knowing who owned= a >>>block for cleanup matters and the DRI lock/mem handling on some chips >>>already handles it. Its also cheap because you only have to track some >>>kind of texture handles not pages for cleanup. >> >>Actually, the long term idea is to have both dri and ddx allocate from=20 >>the same memory pool. So we can't rely on texture handles for that. >=20 >=20 > May I ask why we can't, assuming this is done via EXA callbacks into th= e > DDX driver that use the shared memory manager? When thinking about the memory manager, there's far more uses for=20 graphics memory than just textures: The framebuffer (including color, Z, stencil, etc) Pbuffers Renderbuffer/Framebuffer objects Pixel/Vertex buffer objects Texture images OpenGL miscellaneous (e.g. vertex/fragment programs) X server miscellaneous (pixmap cache, etc) So, just constructing a memory manager around texture handles seems=20 short-sighted. Furthermore, different memory objects may have different=20 requirements/properties: 1. The location of the object in memory (perhaps the framebuffer has to be at the start of memory). 2. Particular byte/word alignments 3. Can we use VRAM and/or AGP memory for the object? 4. Can the object can be lost asynchronously (Pbuffers)? ... plus others I'm surely forgetting or not aware of. Bearing in mind that I'm probably among the least knowledgeable of the=20 Linux kernel among those here, here are my thoughts on the subject. 1. I'd like an allocator that can be used outside/independent of the=20 Xserver. Specifically, an allocator that EGL and EGL drivers can use. 2. There needs to be a way to share memory blocks between processes. 3. Blocks should get automatically freed when the process that creates=20 them terminates (unless they're shared w/ another process, perhaps). 4. Blocks should probably be named by an opaque handle. That might=20 help to support some kind of simple security model plus allow memory=20 blocks to be relocated, etc. 5. Blocks would have to be locked in some manner while they were=20 actually in use. We don't want to move a texture image while it's=20 being used. 6. There should be a mechanism for the allocator to notify a process=20 when one of its blocks is moved/ejected/changed. 7. The public interface to the allocator should be OS-independent so=20 that it can be implemented on Linux, FreeBSD, etc. Perhaps the public=20 API would be exposed through a library which wraps an OS-specific=20 interface based on ioctls, etc. 8. Try to keep both the interface and implementation as simple as=20 possible with an eye toward future extensions. I think it would be worthwhile to start a specification document for=20 this project (or perhaps a wiki page) where the requirements, issues=20 and proposed interface could be recorded. Any volunteers? -Brian |
From: Michel <mi...@da...> - 2005-08-24 15:39:01
|
On Wed, 2005-08-24 at 09:18 -0600, Brian Paul wrote: > Michel D=C3=A4nzer wrote: > > On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote: > >=20 > >>Alan Cox wrote: > >> > >>>Other stuff like textures is merely annoyance value. Knowing who owned= a > >>>block for cleanup matters and the DRI lock/mem handling on some chips > >>>already handles it. Its also cheap because you only have to track some > >>>kind of texture handles not pages for cleanup. > >> > >>Actually, the long term idea is to have both dri and ddx allocate from=20 > >>the same memory pool. So we can't rely on texture handles for that. > >=20 > >=20 > > May I ask why we can't, assuming this is done via EXA callbacks into th= e > > DDX driver that use the shared memory manager? >=20 > When thinking about the memory manager, there's far more uses for=20 > graphics memory than just textures: >=20 > The framebuffer (including color, Z, stencil, etc) > Pbuffers > Renderbuffer/Framebuffer objects > Pixel/Vertex buffer objects > Texture images > OpenGL miscellaneous (e.g. vertex/fragment programs) > X server miscellaneous (pixmap cache, etc) >=20 > So, just constructing a memory manager around texture handles seems=20 > short-sighted. Indeed, I think Alan probably meant the opaque handle for memory objects you mention below, at least that's how I read it. > Furthermore, different memory objects may have different=20 > requirements/properties: >=20 > 1. The location of the object in memory (perhaps the framebuffer has > to be at the start of memory). > 2. Particular byte/word alignments > 3. Can we use VRAM and/or AGP memory for the object? > 4. Can the object can be lost asynchronously (Pbuffers)? > ... plus others I'm surely forgetting or not aware of. Yes, I think these and maybe more should be handled via parameters when allocating a memory object. What I'm not sure is whether it's better to specify these specific but HW-dependent attributes or maybe some kind of abstract attributes (can be rendered to/from / scanned out / ...) which are then translated into specific constraints by a HW specific part of the memory manager. I'm leaning towards the latter. > Bearing in mind that I'm probably among the least knowledgeable of the=20 > Linux kernel among those here, here are my thoughts on the subject. [...] I agree with all your requirements. > I think it would be worthwhile to start a specification document for=20 > this project (or perhaps a wiki page) where the requirements, issues=20 > and proposed interface could be recorded. Indeed, thanks for such a nice summary! --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Ian R. <id...@us...> - 2005-08-24 15:56:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michel D=C3=A4nzer wrote: > On Wed, 2005-08-24 at 09:18 -0600, Brian Paul wrote: >=20 >>1. The location of the object in memory (perhaps the framebuffer has >> to be at the start of memory). >>2. Particular byte/word alignments >>3. Can we use VRAM and/or AGP memory for the object? >>4. Can the object can be lost asynchronously (Pbuffers)? >>... plus others I'm surely forgetting or not aware of. >=20 > Yes, I think these and maybe more should be handled via parameters when > allocating a memory object. What I'm not sure is whether it's better to > specify these specific but HW-dependent attributes or maybe some kind o= f > abstract attributes (can be rendered to/from / scanned out / ...) which > are then translated into specific constraints by a HW specific part of > the memory manager. I'm leaning towards the latter. That's what the BUFFLAG_ bits in memory_buffer.h were for. When a memory pool is created, the driver specifies a set of attributes for it. For example, cards like the G400 that can put the depth buffer in AGP memory would have (BUFFLAG_DEPTH_BUFFER | BUFFLAG_STENCIL_BUFFER | BUFFLAG_TEXTURE | BUFFLAG_COMMAND) for the AGP pool. A card like the R200 that can't put the depth buffer in AGP but can pull vertex data from AGP would have (BUFFLAG_TEXTURE | BUFFLAG_VERTEX | BUFFLAG_COMMAND). When an object is associated with a region ID (*not* when it is committed to memory, see my other post) these bits are associated with it. The allocator then searches for a pool that meets all the requirements. Note that per-region requirements are only kept (or needed) within the user-mode driver. Since the kernel doesn't make any decisions about where to put an object, it doesn't care. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD4DBQFDDJh2X1gOwKyEAw8RAj5vAJi8jT6pmLFPlPIRdvNCBqeoKV0yAJ9fvPo+ U7X5nlyIKYoeXL6tECfjfQ=3D=3D =3DX1VX -----END PGP SIGNATURE----- |
From: Ian R. <id...@us...> - 2005-08-24 15:48:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Paul wrote: > 1. I'd like an allocator that can be used outside/independent of the > Xserver. Specifically, an allocator that EGL and EGL drivers can use. > > 2. There needs to be a way to share memory blocks between processes. So that an off-screen "window" could be shared by the X-server and the client-side driver? The current designs don't really account for that. I suspect that this would just require a way to associate multiple process IDs with a region ID (see below). The does change the way we'd have to manage region IDs. Hmm... > 3. Blocks should get automatically freed when the process that creates > them terminates (unless they're shared w/ another process, perhaps). > > 4. Blocks should probably be named by an opaque handle. That might help > to support some kind of simple security model plus allow memory blocks > to be relocated, etc. > > 5. Blocks would have to be locked in some manner while they were > actually in use. We don't want to move a texture image while it's being > used. > > 6. There should be a mechanism for the allocator to notify a process > when one of its blocks is moved/ejected/changed. In the prototype code that I posted to the list several months ago, these four things were handled together. Each object has an associated "region ID". The region IDs are allocated to a process by the kernel, and they can therefore be reclaimed when the process dies. When a process wants to use a region, it calls a function to conver the region ID to an address. Two functions exist. One converts the region ID to a CPU address, and the other, with the help of a device-specific callback, converts the region ID to a card address. This commits the object to memory. After an object is committed to memory, another function is called to get a list of "dirty" ranges in the region. These are portions of the region that need to be restored. In the original design the commit routine would automatically have the kernel restore precious regions. Since we've made the change that user-mode provides the kernel with backing store for the region, this is no longer necessary. The user-mode driver restores precious regions just like other regions. I had all this spread into 3 layers. There's a kernel layer, a device-independent user-mode layer, and a device-dependent user-mode layer. Almost everything should be doable in the device-independent user-mode layer. > 7. The public interface to the allocator should be OS-independent so > that it can be implemented on Linux, FreeBSD, etc. Perhaps the public > API would be exposed through a library which wraps an OS-specific > interface based on ioctls, etc. > > 8. Try to keep both the interface and implementation as simple as > possible with an eye toward future extensions. > > > I think it would be worthwhile to start a specification document for > this project (or perhaps a wiki page) where the requirements, issues and > proposed interface could be recorded. Any volunteers? Yeah. We've got discussions going on in enough different places that we really need to gather all the information in one place. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDDJaaX1gOwKyEAw8RAtysAJsEIE/lB535melOceIMEI2vWJuIWwCdGsQd 9TmFEh93cMn9WDuT/tNqp3U= =ejuh -----END PGP SIGNATURE----- |
From: Brian P. <bri...@tu...> - 2005-08-24 16:27:10
|
Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Brian Paul wrote: > > >>1. I'd like an allocator that can be used outside/independent of the >>Xserver. Specifically, an allocator that EGL and EGL drivers can use. >> >>2. There needs to be a way to share memory blocks between processes. > > > So that an off-screen "window" could be shared by the X-server and the > client-side driver? Right. The X server may create/allocate an off-screen window that a direct rendering client draws into and a compositing manager also binds as a texture for compositing/display. That makes three parties interested in that buffer. > The current designs don't really account for that. > I suspect that this would just require a way to associate multiple > process IDs with a region ID (see below). The does change the way we'd > have to manage region IDs. Hmm... > > >>3. Blocks should get automatically freed when the process that creates >>them terminates (unless they're shared w/ another process, perhaps). >> >>4. Blocks should probably be named by an opaque handle. That might help >>to support some kind of simple security model plus allow memory blocks >>to be relocated, etc. >> >>5. Blocks would have to be locked in some manner while they were >>actually in use. We don't want to move a texture image while it's being >>used. >> >>6. There should be a mechanism for the allocator to notify a process >>when one of its blocks is moved/ejected/changed. > > > In the prototype code that I posted to the list several months ago, > these four things were handled together. Each object has an associated > "region ID". The region IDs are allocated to a process by the kernel, > and they can therefore be reclaimed when the process dies. > > When a process wants to use a region, it calls a function to conver the > region ID to an address. Two functions exist. One converts the region > ID to a CPU address, and the other, with the help of a device-specific > callback, converts the region ID to a card address. This commits the > object to memory. > > After an object is committed to memory, another function is called to > get a list of "dirty" ranges in the region. These are portions of the > region that need to be restored. In the original design the commit > routine would automatically have the kernel restore precious regions. > Since we've made the change that user-mode provides the kernel with > backing store for the region, this is no longer necessary. The > user-mode driver restores precious regions just like other regions. I guess I don't understand how particular "ranges" within a "region" would become dirty. It sounds like there's two-levels of allocation going on. It would seem to make sense to put all the images which constitute a texture object into one region (a mipmapped cube texture might have 60 or more images). But what about multiple texture objects in one region? If allocations are slow/expensive, the GL driver might make allocations in large-ish chunks that it divides up for multiple texture objects by itself. > I had all this spread into 3 layers. There's a kernel layer, a > device-independent user-mode layer, and a device-dependent user-mode > layer. Almost everything should be doable in the device-independent > user-mode layer. > > >>7. The public interface to the allocator should be OS-independent so >>that it can be implemented on Linux, FreeBSD, etc. Perhaps the public >>API would be exposed through a library which wraps an OS-specific >>interface based on ioctls, etc. >> >>8. Try to keep both the interface and implementation as simple as >>possible with an eye toward future extensions. >> >> >>I think it would be worthwhile to start a specification document for >>this project (or perhaps a wiki page) where the requirements, issues and >>proposed interface could be recorded. Any volunteers? > > > Yeah. We've got discussions going on in enough different places that we > really need to gather all the information in one place. -Brian |
From: Ian R. <id...@us...> - 2005-08-24 16:35:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Paul wrote: > Ian Romanick wrote: > >> In the prototype code that I posted to the list several months ago, >> these four things were handled together. Each object has an associated >> "region ID". The region IDs are allocated to a process by the kernel, >> and they can therefore be reclaimed when the process dies. >> >> When a process wants to use a region, it calls a function to conver the >> region ID to an address. Two functions exist. One converts the region >> ID to a CPU address, and the other, with the help of a device-specific >> callback, converts the region ID to a card address. This commits the >> object to memory. >> >> After an object is committed to memory, another function is called to >> get a list of "dirty" ranges in the region. These are portions of the >> region that need to be restored. In the original design the commit >> routine would automatically have the kernel restore precious regions. >> Since we've made the change that user-mode provides the kernel with >> backing store for the region, this is no longer necessary. The >> user-mode driver restores precious regions just like other regions. > > I guess I don't understand how particular "ranges" within a "region" > would become dirty. It sounds like there's two-levels of allocation > going on. > > It would seem to make sense to put all the images which constitute a > texture object into one region (a mipmapped cube texture might have 60 > or more images). But what about multiple texture objects in one region? > > If allocations are slow/expensive, the GL driver might make allocations > in large-ish chunks that it divides up for multiple texture objects by > itself. 1. Video card has 8MB. 2. 1MB of the card memory is allocated for the front buffer and pinned. 3. Process A allocates (and commits) a 7MB region for a big texture. 4. Process B allocates (and commits) a 2MB region for a texture. To do this, it kick out part of process A's allocation. 5. Process A re-commits its 7MB texture. At #5 we'd much rather just upload the damaged 1MB than have to upload the whole 7MB. This is just a simple example, but the same scenario happens with larger on-card memory + AGP memory and larger textures. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDDKG+X1gOwKyEAw8RAqEIAJ0YFkTG6oe55UpfEg/T5OzhLfDz7QCfdWkb aWOOo91HZrCtcMEyvysEo7U= =3ptv -----END PGP SIGNATURE----- |
From: Eric A. <et...@lc...> - 2005-08-24 16:49:05
|
On Wed, 2005-08-24 at 08:47 -0700, Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Brian Paul wrote: >=20 > > 1. I'd like an allocator that can be used outside/independent of the > > Xserver. Specifically, an allocator that EGL and EGL drivers can use. > >=20 > > 2. There needs to be a way to share memory blocks between processes. >=20 > So that an off-screen "window" could be shared by the X-server and the > client-side driver? The current designs don't really account for that. > I suspect that this would just require a way to associate multiple > process IDs with a region ID (see below). The does change the way we'd > have to manage region IDs. Hmm... >=20 > > 3. Blocks should get automatically freed when the process that creates > > them terminates (unless they're shared w/ another process, perhaps). > >=20 > > 4. Blocks should probably be named by an opaque handle. That might hel= p > > to support some kind of simple security model plus allow memory blocks > > to be relocated, etc. > >=20 > > 5. Blocks would have to be locked in some manner while they were > > actually in use. We don't want to move a texture image while it's bein= g > > used. > >=20 > > 6. There should be a mechanism for the allocator to notify a process > > when one of its blocks is moved/ejected/changed. >=20 > In the prototype code that I posted to the list several months ago, > these four things were handled together. Each object has an associated > "region ID". The region IDs are allocated to a process by the kernel, > and they can therefore be reclaimed when the process dies. >=20 > When a process wants to use a region, it calls a function to conver the > region ID to an address. Two functions exist. One converts the region > ID to a CPU address, and the other, with the help of a device-specific > callback, converts the region ID to a card address. This commits the > object to memory. >=20 > After an object is committed to memory, another function is called to > get a list of "dirty" ranges in the region. These are portions of the > region that need to be restored. In the original design the commit > routine would automatically have the kernel restore precious regions. > Since we've made the change that user-mode provides the kernel with > backing store for the region, this is no longer necessary. The > user-mode driver restores precious regions just like other regions. >=20 > I had all this spread into 3 layers. There's a kernel layer, a > device-independent user-mode layer, and a device-dependent user-mode > layer. Almost everything should be doable in the device-independent > user-mode layer. >=20 > > 7. The public interface to the allocator should be OS-independent so > > that it can be implemented on Linux, FreeBSD, etc. Perhaps the public > > API would be exposed through a library which wraps an OS-specific > > interface based on ioctls, etc. > >=20 > > 8. Try to keep both the interface and implementation as simple as > > possible with an eye toward future extensions. > >=20 > >=20 > > I think it would be worthwhile to start a specification document for > > this project (or perhaps a wiki page) where the requirements, issues an= d > > proposed interface could be recorded. Any volunteers? >=20 > Yeah. We've got discussions going on in enough different places that we > really need to gather all the information in one place. Could we use http://dri.freedesktop.org/wiki/DriMemoryManagerDesign ? I've added some bits on XAA/EXA and kernel swapping-out issues. --=20 Eric Anholt et...@lc... http://people.freebsd.org/~anholt/ anholt@FreeBSD.org |
From: Ian R. <id...@us...> - 2005-08-24 16:53:43
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Anholt wrote: > On Wed, 2005-08-24 at 08:47 -0700, Ian Romanick wrote: >>Brian Paul wrote: >> >>>I think it would be worthwhile to start a specification document for >>>this project (or perhaps a wiki page) where the requirements, issues and >>>proposed interface could be recorded. Any volunteers? >> >>Yeah. We've got discussions going on in enough different places that we >>really need to gather all the information in one place. > > Could we use http://dri.freedesktop.org/wiki/DriMemoryManagerDesign ? > > I've added some bits on XAA/EXA and kernel swapping-out issues. That document is *horribly* out of date. We'll have to start by gutting it and replacing it with something derived from: http://marc.theaimsgroup.com/?l=mesa3d-dev&m=111101398019810&w=2 I should be able to do some of that on Friday, if nobody gets to it first. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDDKYKX1gOwKyEAw8RAgWNAJ9+KHNat22lCa58V9BpKYzxqLn3hgCfUD1m p3qZb0gduOpwsiid0GknlCM= =On7H -----END PGP SIGNATURE----- |
From: Ian R. <id...@us...> - 2005-09-03 08:20:59
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Anholt wrote: > On Wed, 2005-08-24 at 08:47 -0700, Ian Romanick wrote: >>Brian Paul wrote: >> >>>I think it would be worthwhile to start a specification document for >>>this project (or perhaps a wiki page) where the requirements, issues and >>>proposed interface could be recorded. Any volunteers? >> >>Yeah. We've got discussions going on in enough different places that we >>really need to gather all the information in one place. > > Could we use http://dri.freedesktop.org/wiki/DriMemoryManagerDesign ? > > I've added some bits on XAA/EXA and kernel swapping-out issues. I just made a pretty major update (read: total re-write) based on the current design. It's not complete because I'm too tired to finish it right now. I should be able to fill in the rest tomorrow. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDGVy5X1gOwKyEAw8RAoQTAJ9IkSOwDtZ8QkeGOBDuEBdaGcuZhwCeK/MU gjro2U9saRZbpxRcAhhygmc= =PKmL -----END PGP SIGNATURE----- |