On Wed, Apr 01, 2015 at 11:04:45PM +0100, Emil Velikov wrote: > On 1 April 2015 at 22:26, Jerome Glisse <j.glisse@xxxxxxxxx> wrote: > > On Wed, Apr 01, 2015 at 09:57:40PM +0100, Emil Velikov wrote: > >> On 1 April 2015 at 21:34, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: > >> > On 1 April 2015 at 18:30, Jerome Glisse <j.glisse@xxxxxxxxx> wrote: > >> >> On Wed, Apr 01, 2015 at 05:15:13PM +0100, Emil Velikov wrote: > >> >>> Missing definition and unused since their introduction. > >> >>> > >> >>> Cc: Jerome Glisse <jglisse@xxxxxxxxxx> > >> >>> Signed-off-by: Emil Velikov <emil.l.velikov@xxxxxxxxx> > >> >> > >> >> NAK > >> >> > >> >> I use all this in tools to debug lockup. Best course of action is to > >> >> exclude bof.h from being distributed. My tools static link and i just > >> >> point them to libdrm git tree. > >> >> > >> > Did not notice any mention of such out-of-tree tools in the commit > >> > that introduced these functions, so I've naively assumed that they are > >> > unused. > >> Scratch that - I'm blind. > >> > >> Upon closer look at your radeondb repo, I cannot see any static > >> linking in there. Also it seems that some of the functionality is > >> duplicated between the two. With the radeondb version being out of > >> date :'( > > > > Yeah i guess i never pushed anywhere patches that did that, divergence btw > > my memory and what is out there. All this symbol can just be hidden and > > never exported. It would cleaner, but i still need the bof.h intact as i > > tend to just cp it afaict into my local radeondb copy so that i am in > > sync with libdrm code. > > > I can volunteer with the cleanup/integration of radeondb next to > libdrm_radeon. If you update your repo (or push your work elsewhere), > I could double-check, integrate and nuke the duplication. It will > avoid the next person from coming over and trying to nuke things, the > divergence mentioned, plus the copy/pasting of bof.[ch] every time you > use the tool. > > How does that sound ? If you feel like it yes, but as i said i fear bof will stay relevant only for the duration xf86-video-ati is and i fear with the advance of the generic modesetting and glamor acceleration this might not last long. As mesa is using a different scheme to allow capture and replay of cs. Anyway, the only tool that matter regarding bof is bofreplay from my joujou repository git://people.freedesktop.org/~glisse/joujou I used to have a tool to allow bisecting bof cs but it might have been lost in translation somewhere. Thought all is needed is a parameter to bofreplay to limit the number of dwords replayed. Happy coding if you decide to go down that road :) Cheers, Jérôme > > Cheers, > Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
