Improvement suggestions

Improvement suggestions

Sergey M.'s picture

Hi there,

I've been using Intel GPA for at least a year now. Am partially happy with it, thus is this topic with some suggestions.

1. GPA should be able to run two instances - it would be tremendously more easy to compare/diff stuff, for example tracking a bug

2. Shown state problems (my main problem actually)

2.1. Texture vs sampler ordering. Which texture is bound to which sampler? Very confusing!

2.2. Texture alpha, render target alpha, native depth. Even better a toggleable mask with the RGBA channels

2.3. Shader constants - show current constants in a given, user specified range, not only the ones set between this and the previous arg! Most engines do cache stuff and showing the immediate setup before the Arg is actually not so usefull, since shader use a lot more constants. Specifying the range can help to concentrate on some specific parameter of the shader

3. Experiments:

3.1. Use 2x2 textures for everything *except* the ones used as Render targets - or else deferred renderers just can't use that in a sensible way 3.2. Change resolution - quite often the resolution is very easy to spot and to reallocate all Render targets that match it to some other dimensions. Yep, shader constants that use resolution could get it wrong, but most of the time they don't matter for the performance 3.3. Limit DIP primitive count to some max value

Some small gripes I have, but hour after hour they get really in the way:

4. Select Arg update is not quite fast and very often I just uncheck curent Arg and check another one. Bam, two updates of the UI + render targets... Can you make something like 'Select only that Arg'?

5. Changing Args should try to keep the current selected Render target if any. Often they are the thing people inspect and constantly selecting then instead of the Back buffer is... well.

6. Easy stepping forward and back one Arg at a time would be great + highlighting the changed stuff vs non-changed

7. API log is good, but it would be better if we can filter the stuff there. Groups like 'Render target', 'Viewport', 'shader const setup', etc. to exclude the stuf we don't need and to be able to observe some specific behavior in the whole frame log.

8. API log objects - would be great if we could see the render targets / shaders without going to the exact Arg, so the browing of the large logs would be really handy

Thanks!

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Neal P (Intel)'s picture

Hi,

Thanks for using Intel GPA, and for your detailed and helpful suggestions! I'll add these to our new features queue.

Also, to help our development team prioritize these items, can you tell me a bit about your workflow and the platforms your are targeting, as well as your company? You can send me a private message with this information if you prefer to not disclose this information in the forums.

Regards,

Neal

Adam Miles's picture

2.2 and 5 are my two biggest gripes.

Unless I've missed something, GPA doesn't appear to show the link between bound textures/SRVs and their slot index. If someone asks me what texture is bound to SRV slot 7, the textures tab appears not to be able to tell me that information. Similiarly with render targets, I can see a list of around 100 render targets, but not which ones are bound to a given RTV index, of which there can only be 8 at any given time.

#5 though is a big pain. Every time you change an erg it goes back to displaying the 'Front Buffer' and not the render target(s) that it was actually rendering to at the time. This means if you want to see the difference between two ergs you have to repeatedly scroll through a list to find the RTV you know that's changed and select it.

Adam

Neal P (Intel)'s picture

Hello Adam,

Thanks for the feedback -- with a couple of you requesting these features that'll help raise the priority on these.

Regards,

Neal

laurent lessieux - Toshiba Medical's picture

OpenCL Metrix support

- infos about kernels, stall time, synchronization waiting time, texture sampling from OpenCL etc.. would be nice too.

Laurent

Neal P (Intel)'s picture

Hi,

I forgot to close the loop here to let you know that I've added this request to our enhancement backlog.

Thanks again for your use of the Intel GPA product!

Regards,

Neal

Login to leave a comment.