Thomas Hellström wrote: > Thomas Hellström wrote: > >> Jerome Glisse wrote: >> >> >> >>> Hi Thomas, >>> >>> I am in a situation where i need to allocate vram for the gart table >>> ie i can't (in fact i can >>> if i avoid using the memory manager and don't let the manager handle >>> this part of stolen >>> vram but i prefer to go throught the allocator if possible) >>> initialize ttm until i allocated this >>> vram. I have been looking through call chains in drm_ttm.c and >>> drm_bo.c and it seems to >>> me that drm_ttm_init might not be call until ttm is firstly used so >>> i think i am fine but as >>> i might have miss some calls i would like your expert stance on this :) >>> >>> So does this looks good for initialization: >>> drm_bo_driver_init(dev); >>> drm_bo_init_mm(dev, DRM_BO_MEM_VRAM, 0, vramsize); >>> ret = drm_buffer_object_create(dev, gart_table_size, >>> drm_bo_type_kernel, >>> DRM_BO_FLAG_READ | >>> DRM_BO_FLAG_WRITE | >>> DRM_BO_FLAG_MEM_VRAM | >>> DRM_BO_FLAG_NO_EVICT | >>> >>> DRM_BO_HINT_DONT_FENCE, 0, 0x1, 0, >>> >>> &dev_priv->gart_table); >>> /* now and only now create_ttm_backend_entry can be called */ >>> drm_bo_init_mm(dev, DRM_BO_MEM_TT, 0, numpages); >>> >>> Cheers, >>> Jerome Glisse >>> >> >> Hi, Jerome. >> >> Yes. This is OK. In principle it should be OK to add and remove a >> memory area at any point. >> >> If you specify a memory type that's not added, let's say you also >> specify also TT in the above create call, it would just not be >> considered. >> >> Note that the code may still create TTMS for local (system) memory >> buffers. However they should never be moved into the AGP memory area. >> >> /Thomas >> >> > Hmm. > You should note however, that IF the X server has a policy to clean > out VRAM and TT when you switch virtual terminal, the kernel will > complain about the NO_EVICT buffer and throw it out. > > This means that if you want the X server to clean this up while > VT-switching you probably need to implement a driver specific IOCTL that > > 1) Takes the bm_lock in write mode. > 2) Cleans the TT memory and removes the TT memory type. > 3) Unpins the NO_EVICT VRAM buffer > 4) Cleans the VRAM memory. > > And upon switching VT back, > > 1) Pins the VRAM buffer. > 2) Re-adds the TT memory type. > 3) Releases the bm_lock. > > /Thomas > > Right now i am in the wonderful world of modesetting where VT switch doesn't exist :) just load/unload and suspend/resume where i need to take care to backup this table.
Another question is what happen if card_page_size < system_ram_page_size and system_ram_page_size isn't a multiple of card_page_size. So if i am right in such situation you can't linearly map system ram ie if you copy data from vram to ttm there will be gap in data btw each page, also you would need size_to_map/card_page_size pages to be able to copy and this will be higher than size_to_map/system_ram_page_size. I don't think i have such case but as i am always assuming the worse :) i am trying to understand if such situation won't be problematic for the memory manager. Cheers, Jerome Glisse ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
