Jerome Glisse wrote: > Hi Thomas, > > I got a question about BO object it seems that from kernel > point of view we don't store the size the user requested for > allocation, also there is no easy way to quickly get BO handle. > > I would need both for two reasons. I need to know user size > allocation request so i can check if user is trying to access > outside the area it has requested for (even though the request > might still end in the allocated area as its rounded to page). > I would need BO handle mostly to help debuguing user/kernel space > interaction and quickly see about which object each other are > thinking of. > > Hi, Jerome. Requested allocation size is unfortunately not availabe, ATM. Handle is easier. It's bo->base.hash.key.
> Also does fence class have ever been tested ? I would like to > have a class for 3d and one for 2d on radeon (as flush and > pipeline are different). > Yes, It has been tested thoroughly on Poulsbo, which has separate 2D and 3D engines. I think we've pushed all needed changes upstream. However, If you're thinking of doing swapbuffers with 2D, fence classes will force a wait for back-buffer idle when you validate the buffers for the swapbuffer operation. Here you might want to implement something clever hardware specific in command_stream_barrier() instead. > Side remark should there be some check on flag, mask, hint the > userspace ask for as for instance userspace might ask for buffer > to not be fenced while it's needed. And am i right in assuming > that validate will fail if userspace still have a mapping of > the buffer active ? > There are probably a lot of cases where you can supply illegal flags. However, the HINT_DONT_FENCE has been obsoleter for a while and should have no effect in practice. Validation of a mapped buffer will wait until the buffer becomes unmapped. > I don't think i fully understand bo->fence_type, it is set in > drm_fence_buffer_objects. My understanding is that for instance > if you get submited a command stream like this: > -BO cmd, EXE fence > -BO dst, WRITE fence > -BO src, READ fence > The fence emited will be EXE|WRITE|READ, fency_type will be > set to EXE|WRITE|READ but yet once the EXE fence is signaled > this EXE BO can be free (or reused) right ? ie fence not fully > signaled. Yes, that's correct. So the bo->fence_type of the CMD buffer will be EXE only. > If that's right then i didn't fully understand fence > yet :) If so, i think i already asked with one, does signaling > multiple time same sequence number with different flag isn't > troublesome ? Because then i will emit multiple time the > sequence to free EXE buffer as soon as possible. > Yes, it's OK to give the fence handler the same sequence multiple times. with the same fence type or with different fence types. > Also when you call drm_bo_handle_validate you put the bo on > the unfenced list, don't you ? Isn't there another way to > get buffer object without putting it on validate list ? I need > that because fence, class, mask will depend from the command > stream and i don't want to scan 2 times the command stream > one for getting proper fence class & mask and bo flag mask > second to update bo offset in command stream. > > With the command stream submit ioctl, you can only submit for a single fence class at a time. With that IOCTL, you usually also submit a list of buffers, carrying the validation flags and masks, and finally a list of relocations that may be used to patch the command stream, if needed. I think the intel_execbuf.c code does this in a good way now, so it's a good reference. I'm not really sure what you mean you need to scan the command stream? > Thanks a lot Thomas for all your help, you saved me hours of > code reading :) And in the end i will have an optimal|beautifull > BO & fence code :) > > Cheers, > Jerome Glisse <[EMAIL PROTECTED]> > Thanks, Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
