[PATCH libdrm 02/24] radeon: remove empty function declarations

[Jerome Glisse]

On Wed, Apr 01, 2015 at 11:04:45PM +0100, Emil Velikov wrote:
> On 1 April 2015 at 22:26, Jerome Glisse <j.glisse at gmail.com> 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 at gmail.com> wrote:
> >> > On 1 April 2015 at 18:30, Jerome Glisse <j.glisse at gmail.com> 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 at redhat.com>
> >> >>> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
> >> >>
> >> >> 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