Hi @alalek, can you check how much memory is reduced by this PR? Thx.

$ /usr/bin/time ./bin/opencv_test_dnn --test_threads=4 --gtest_filter=Test_Darknet.read_yolo_voc_stream
...
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from Test_Darknet
[ RUN      ] Test_Darknet.read_yolo_voc_stream
[       OK ] Test_Darknet.read_yolo_voc_stream (1397 ms)
[----------] 1 test from Test_Darknet (1397 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (1397 ms total)
[  PASSED  ] 1 test.
1.48user 0.98system 0:01.56elapsed 157%CPU (0avgtext+0avgdata 2144812maxresident)k
40848inputs+0outputs (70major+965499minor)pagefaults 0swaps

Up to ~2.1 GB is used.

Thanks for the testing, @alalek. Looks like we reduce some memory but not much 2336348 -> 2144812.

I just take a look at the detail of read_yolo_voc_stream. It consists of conv 3x3s1, which will be run in the Winograd branch.
Since our implementation of Winograd needs to extend every [3x3] kernel (or weight) to [8x8], that means we need about (8*8)/(3*3) = 7.1 times the memory size than the general convolution implementation. To some extent, Winograd is a strategy of trading space for time.

My solution for these specific test cases is: to disable the Winograd branch.

I suggest not to disable Winograd, but rather disable certain tests if they take too much memory. 2.1Gb of memory is nothing by today's standards. If we have a system that has little memory, users should not just use heavy models on such systems.

Secondly, I hope, at some point we will finally add FP16 compute path into DNN. In this case on ARM systems with FP16 arithmetics Winograd weights will take 2x less space, i.e. roughly 1.1Gb.

I suggest not to disable Winograd, but rather disable certain tests if they take too much memory.

Hi @vpisarev, this is what I have done in this PR. I have disabled some high memory consumption test cases.

2 problems with YOLOv3 / YOLOv4 tests left: http://pullrequest.opencv.org/buildbot/builders/precommit_windows32/builds/100094

If you want to disable them, then add 2GB "skip" tags.

2.1Gb of memory is nothing by today's standards.

This is not true for smartphones and IOT devices. This is always a problem on 32-bit platforms.

Also limited memory bandwidth is an actual gap of modern multi-core processors/SoC, so we should to avoid 3-7 times exploding of the memory consumption.

Hi @alalek, I have added the "CV_TEST_TAG_MEMORY_2GB" for corresponding test cases. But cases were not skipped by Win32 CI as expected. Can you give me more details advice on how to skip these cases? Thx.

Hi @alalek, can you describe in more detail how to skip expected test cases in CI? CV_TEST_TAG_MEMORY_2GB does not work.

I have added the "CV_TEST_TAG_MEMORY_2GB" for corresponding test cases.

Where?
There are no commits with changes in performance tests.

My fault, I add the tag to the accuracy test, instead of the performance test. Thanks for your reply.

Update: Dec.1.
Pass all CI, and there are some warning at Win32 CI which is irrelevant to this PR.

@alalek
I'm getting a crash with OPENCV backend and CPU target and I suspect this appeared with that PR.
I will revert it and confirm, do you guys see anything suspicious?
In my case I think H=W=64 so I should pass the test inputShape[2] >= 12 && inputShape[3] >= 12

Hi @JulienMaille, thanks for your feedback. Can you attach your crashed model?
BTW, clean up the CMake cache maybe fix this issue.

@zihaomu my bad, reverting that commit did not fix the issue.
However forcing winograd to false removes the problem. When was that enabled for non NEON architectures?
(I'm working on a clean project without Cmake cache)
I can invite you to a repository with a model that reproduce the problem

Hi @JulienMaille, I just debug your model. And everything works fine on my site.
Even with Winograd ON, the model can run correctly with AVX2 or NEON or SIMD128 supported machine.

@zihaomu where would that come from? Which input image size are you inferring on?
I'm running it on an Intel i9-10900X, win11 x64, openCV compiled from commit

103212f - Merge pull request #22940 from alalek:build_warnings_msvc - 10 December 2022
you can see my compile flags in the ps1 script from the repository I shared with you

@JulienMaille, the input shape is [1,1,256,256] whis is model expacted.
Test at M1 chip (ARM) and AMD 5600X (X86).

Could you share a zip with compiled dlls so I can test on my Intel cpu?

@zihaomu ok so, I tried in Release mode and the inference works as expected, so it might just be an issue with the debug exception level of msvc

#if _CONTAINER_DEBUG_LEVEL > 0
        _STL_VERIFY(
            _Pos < static_cast<size_type>(_My_data._Mylast - _My_data._Myfirst), "vector subscript out of range");
#endif // _CONTAINER_DEBUG_LEVEL > 0

Are you compiling with mingw?

I compile with msvc 2022.