Output tensor size does not present in the sqlite db binding

[atamazov]

Let's conder this:

./bin/MIOpenDriver conv -c 192 -H 28 -W 28 -y 5 -x 5 -k 32 -n 17 -p 1 -q 1 -v 1 -u 1 -F 1 -V 0 -t 1
...
MIOpen(HIP): Info [SetValues] 192-28-28-5x5-32-26-26-16-1x1-1x1-1x1-0-NCHW-FP32-F...
                                               ^^^^^
              this is size of output tensor -----|
...
00001 MIOpen(HIP): Info2 [PrepareAndBind] [NCHW,FP32,F,2,192,28,28,1,5,5,1,32,16,1,1,0,1,1,0,1,1,0,0,1]

It seems like output tensor size does not present in the sqlite db binding.

IIRC the size of output tensor is important to distinguish asymmetric padding cases (that may happen in same padding mode), for example:

./bin/test_conv2d --float --cmode conv  --group-count 1 --input 1, 1, 3, 3 --weights 1, 1, 2, 2 --pads_strides_dilations 1 1 1 1 1 1 --pmode same --disable-backward-data --disable-backward-weights
...
[SetValues] 1-3-3-2x2-1-3-3-1-0x0-1x1-1x1-0-NCHW-FP32-F
...
./bin/test_conv2d --float --cmode conv  --group-count 1 --input 1, 1, 3, 3 --weights 1, 1, 2, 2 --pads_strides_dilations 1 1 1 1 1 1 --pmode valid --disable-backward-data --disable-backward-weights
...
[SetValues] 1-3-3-2x2-1-2-2-1-0x0-1x1-1x1-0-NCHW-FP32-F
...

The former case (same padding mode) shows 0x0 padding but actual padding is [top 0, bottom 1] x [left 0, right 1]. So we need output size in the db key to distinguish these two different problem configs.

Perhaps we need to rework all this stuff within the library, but not right now.

@JehandadKhan Coul you please look at this.

Right now this may affect performance in corner cases (because only perf-db is probably missing necessary information).

[JehandadKhan]

That is a valid point, I was not aware of the consequence of this. Will open a PR to address this.

[atamazov]

@JehandadKhan Do we already have a fix for this in develop?

[JehandadKhan]

@atamazov Not yet, this is a pending issue.

[ppanchad-amd]

Hi Jehandad, Is this still an issue, if not, can we close it?

[atamazov]

@JehandadKhan @ppanchad-amd This issue is still relevant https://github.com/ROCm/MIOpen/blob/cee33a7aaa3dbbe850d2580a72fff8774ddbc131/src/include/miopen/conv/problem_description.hpp#L426-L450

[ppanchad-amd]

An internal ticket has been created and an engineer has been assigned to work on this.

[atamazov]

@ppanchad-amd Why do we need internal ticket? I am asking because this may lead to the duplication of information and does not comply the open-source development strategy. Or that ticket will only hold the minimal amount of information (e.g. link to this issue plus some really internal info)?

[nartmada]

Hi @atamazov, the internal ticket is for AMD internal only (e.g. tracking the progress/status, assignee, etc). We want to avoid this scenario where tickets have been opened for number of years without update or resolution. Thanks.

[JonathanLichtnerAMD]

Closing since MIOpen is being migrated to ROCm/rocm-libraries. Please re-open there if you believe this is still an issue.