On 08/08/18 21:55, Rafael Antognolli wrote:
t
@@ -790,6 +892,7 @@ aub_viewer_render_batch(struct aub_viewer_decode_ctx *ctx,
for (unsigned i = 0; i < ARRAY_SIZE(info_decoders); i++) {
if (strcmp(inst_name, info_decoders[i].cmd_name) == 0) {
+ ctx->stage = info_decoders[i].stage;
info_decoders[i].decode(ctx, inst, p);
break;
Looks like you run the info_decoders before the display decoders (even
though some of them decode the same type of instructions) because you
want to first do a pass storing all the information required for the
display_decoders, right?
And in this case, you also want to store the stage we are at, so when we
run the info_decoders that information is available.
Also, is there a chance we use these same info decoders for storing
other information than urb related stuff? If so, maybe we should just
call them handle_3ds_gs, handle_3ds_constant_vs, etc... Or something
along those lines. But of course we could just rename them in the
future.
The UI code (decode_* functions) run conditionally to the instruction
having their fields visible (expanded by clicking on them).
info_decoders runs unconditionally so that we can have a consistent
accumulated state that doesn't depend on the UI state.
For example, you might not want to display urb instructions & their
content. Yet you still need to parse their content so that URB state can
be displayed on a latter instruction (like 3DPRIMITIVE).
This is poorly named indeed and could be done more efficiently. This can
be done later (once you get the hang of ImGui. It's really fun!).
-
Lionel
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
