On Mon, 2004-11-08 at 02:43 +0000, Dave Airlie wrote: > > > I've just patched this into the radeon driver (and texmem.c) > > > http://freedesktop.org/~airlied/patches/dri/radeon_texturetop.patch > > Okay the patch above should now work on the radeon driver, I had forgotten > a call to update the texture.... > > Just some comments and criticisms from a quick look over it: > > The protocol processing code in the texturetop (server code - it > is called client code but it listens on a socket which makes it a server > in my mind)
I reversed the client/server setup at one point in the development,
and it is still the "server" that sends commands and the client that
responds. :-) Yes, that file was confusingly named and I've renamed it
to texprof-lib.[ch] I tried to say "application" "profiler" most places
in the docs.
> , is fragile, starting manytex with -n 99 makes it crap out on
> my system,
Ah, in addition to the bug you pointed out with it incorrectly reporting
overlong commands, there was another bug when a \r occurred right at
the end of the buffer.
I also fixed an obvious problem with manytex -n 99 - it wasn't
truncating the list of textures to fit into the screen.
All three problems are fixed in the texturetop-1.1 I just put up on
the texturetop web page.
> I think the processing of the buffer from the client isn't
> robust enough, it should probably use a proper circular buffer or a state
> machine based decode..
I wrote it pretty carefully... I'm not saying that there aren't more
bugs, but it should be fundamentally pretty sound. (It is a simple
state machine over the lines if you look inside textprof-lib.c. Each
line has a fixed format.)
> I also would wonder if a packet protocol might not be better placed for a
> protocol that goes between two processes where no human is going to be
> looking at it,, it certainly would be more efficient,
>
> <pkttype><length><info>
>
> string processing in C is always ugly.....
A binary protocol would certainly be more efficient. I chose a text
based protocol mostly because it's a whole lot easier to debug - if an
error occurs, just print out the line that caused the error. And
despite the poor string processing facilities of C, it's still probably
a bit easier to write than a binary protocol.
But if efficiency turns out to be a problem, I'd certainly welcome
someone reworking it to use a binary protocol.
> I might get a chance to mess more with it later, my main application uses
> between 10s and 1000s of textures!! so it is a great way to stress it...
> also a sorting option like top would be nice ;-)
That would be nice. The main difficulty is actually not the sorting,
but taking keystrokes, so far texturetop has the most simplistic output
routines you can imagine, and doesn't do input at all; not that it
is that hard to figure out the necessary tcsetattr() invocation.
(At some point using curses rather than hardcoding VT100 escape
sequences would be a win, but I wanted to avoid dragging in an extra
dependency...)
Anyways many thanks for trying this out and for the feedback.
Regards,
Owen
signature.asc
Description: This is a digitally signed message part
