On Tue, 08 Apr 2008 19:29:50 +0200
Thomas Hellström <[EMAIL PROTECTED]> wrote:

> 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.

Do you mind if i add things to store this size and to get it ?

> > 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.

Yes, i have seen this after writing my mail, does the barrier happen
even if no buffer in the 2d class are in use in the 3d class (and
the other way too) ?

> > 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.

Ok so i will add sequence with just exe before flush, i need to think
a bit to flush so i don't add one at each command but when user ask
for a fence flush for instance.

> > 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?

On radeon we scan packet to see if the packet is authorized or not, for
instance we want to forbid user to submit a blit with no bo relocation
so to arbitrary memory location. This is the type of command i scan in
the stream which in the end determine if i want to flush 2d or 3d or
both (and each buffer might not be on the same kind).

Cheers,
Jerome Glisse <[EMAIL PROTECTED]>

-------------------------------------------------------------------------
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
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to