Recherche avancée

Sur d’autres sites (6898)

• Cortex-A7 instruction cycle timings

  15 mai 2014, par Mans — ARM

  The Cortex-A7 ARM core is a popular choice in low-power and low-cost designs. Unfortunately, the public TRM does not include instruction timing information. It does reveal that execution is in-order which makes measuring the throughput and latency for individual instructions relatively straight-forward.

  The table below lists the measured issue cycles (inverse throughput) and result latency of some commonly used instructions.

  It should be noted that in some cases, the perceived latency depends on the instruction consuming the result. Most of the values were measured with the result used as input to the same instruction. For instructions with multiple outputs, the latencies of the result registers may also differ.

  Finally, although instruction issue is in-order, completion is out of order, allowing independent instructions to issue and complete unimpeded while a multi-cycle instruction is executing in another unit. For example, a 3-cycle MUL instruction does not block ADD instructions following it in program order.

  ALU instructions	Issue cycles	Result latency
  MOV Rd, Rm	1/2	1
  ADD Rd, Rn, #imm	1/2	1
  ADD Rd, Rn, Rm	1	1
  ADD Rd, Rn, Rm, LSL #imm	1	1
  ADD Rd, Rn, Rm, LSL Rs	1	1
  LSL Rd, Rn, #imm	1	2
  LSL Rd, Rn, Rs	1	2
  QADD Rd, Rn, Rm	1	2
  QADD8 Rd, Rn, Rm	1	2
  QADD16 Rd, Rn, Rm	1	2
  CLZ Rd, Rm	1	1
  RBIT Rd, Rm	1	2
  REV Rd, Rm	1	2
  SBFX Rd, Rn	1	2
  BFC Rd, #lsb, #width	1	2
  BFI Rd, Rn, #lsb, #width	1	2
  NOTE : Shifted operands and shift amounts needed one cycle early.
  Multiply instructions	Issue cycles	Result latency
  MUL Rd, Rn, Rm	1	3
  MLA Rd, Rn, Rm, Ra	1	31
  SMULL Rd, RdHi, Rn, Rm	1	3
  SMLAL Rd, RdHi, Rn, Rm	1	31
  SMMUL Rd, Rn, Rm	1	3
  SMMLA Rd, Rn, Rm, Ra	1	31
  SMULBB Rd, Rn, Rm	1	3
  SMLABB Rd, Rn, Rm, Ra	1	31
  SMULWB Rd, Rn, Rm	1	3
  SMLAWB Rd, Rn, Rm, Ra	1	31
  SMUAD Rd, Rn, Rm	1	3
  1 Accumulator forwarding allows back to back MLA instructions without delay.
  Divide instructions	Issue cycles	Result latency
  SDIV Rd, Rn, Rm	4-20	6-22
  UDIV Rd, Rn, Rm	3-19	5-21
  Load/store instructions	Issue cycles	Result latency
  LDR Rt, [Rn]	1	3
  LDR Rt, [Rn, #imm]	1	3
  LDR Rt, [Rn, Rm]	1	3
  LDR Rt, [Rn, Rm, lsl #imm]	1	3
  LDRD Rt, Rt2, [Rn]	1	3-4
  LDM Rn, regs	1-8	3-10
  STR Rt, [Rn]	1	2
  STRD Rt, Rt2, [Rn]	1	2
  STM Rn, regs	1-10	2-12
  NOTE : Load results are forwarded to dependent stores without delay.
  VFP instructions	Issue cycles	Result latency
  VMOV.F32 Sd, Sm	1	4
  VMOV.F64 Dd, Dm	1	4
  VNEG.F32 Sd, Sm	1	4
  VNEG.F64 Dd, Dm	1	4
  VABS.F32 Sd, Sm	1	4
  VABS.F64 Dd, Dm	1	4
  VADD.F32 Sd, Sn, Sm	1	4
  VADD.F64 Dd, Dn, Dm	1	4
  VMUL.F32 Sd, Sn, Sm	1	4
  VMUL.F64 Dd, Dn, Dm	4	7
  VMLA.F32 Sd, Sn, Sm	1	81
  VMLA.F64 Dd, Dn, Dm	4	112
  VFMA.F32 Sd, Sn, Sm	1	81
  VFMA.F64 Dd, Dn, Dm	5	82
  VDIV.F32 Sd, Sn, Sm	15	18
  VDIV.F64 Dd, Dn, Dm	29	32
  VSQRT.F32 Sd, Sm	14	17
  VSQRT.F64 Dd, Dm	28	31
  VCVT.F32.F64 Sd, Dm	1	4
  VCVT.F64.F32 Dd, Sm	1	4
  VCVT.F32.S32 Sd, Sm	1	4
  VCVT.F64.S32 Dd, Sm	1	4
  VCVT.S32.F32 Sd, Sm	1	4
  VCVT.S32.F64 Sd, Dm	1	4
  VCVT.F32.S32 Sd, Sd, #fbits	1	4
  VCVT.F64.S32 Dd, Dd, #fbits	1	4
  VCVT.S32.F32 Sd, Sd, #fbits	1	4
  VCVT.S32.F64 Dd, Dd, #fbits	1	4
  1 5 cycles with dependency only on accumulator. 2 8 cycles with dependency only on accumulator.
  NEON integer instructions	Issue cycles	Result latency
  VADD.I8 Dd, Dn, Dm	1	4
  VADDL.S8 Qd, Dn, Dm	2	4
  VADD.I8 Qd, Qn, Qm	2	4
  VMUL.I8 Dd, Dn, Dm	2	4
  VMULL.S8 Qd, Dn, Dm	2	4
  VMUL.I8 Qd, Qn, Qm	4	4
  VMLA.I8 Dd, Dn, Dm	2	4
  VMLAL.S8 Qd, Dn, Dm	2	4
  VMLA.I8 Qd, Qn, Qm	4	4
  VADD.I16 Dd, Dn, Dm	1	4
  VADDL.S16 Qd, Dn, Dm	2	4
  VADD.I16 Qd, Qn, Qm	2	4
  VMUL.I16 Dd, Dn, Dm	1	4
  VMULL.S16 Qd, Dn, Dm	2	4
  VMUL.I16 Qd, Qn, Qm	2	4
  VMLA.I16 Dd, Dn, Dm	1	4
  VMLAL.S16 Qd, Dn, Dm	2	4
  VMLA.I16 Qd, Qn, Qm	2	4
  VADD.I32 Dd, Dn, Dm	1	4
  VADDL.S32 Qd, Dn, Dm	2	4
  VADD.I32 Qd, Qn, Qm	2	4
  VMUL.I32 Dd, Dn, Dm	2	4
  VMULL.S32 Qd, Dn, Dm	2	4
  VMUL.I32 Qd, Qn, Qm	4	4
  VMLA.I32 Dd, Dn, Dm	2	4
  VMLAL.S32 Qd, Dn, Dm	2	4
  VMLA.I32 Qd, Qn, Qm	4	4
  NEON floating-point instructions	Issue cycles	Result latency
  VADD.F32 Dd, Dn, Dm	2	4
  VADD.F32 Qd, Qn, Qm	4	4
  VMUL.F32 Dd, Dn, Dm	2	4
  VMUL.F32 Qd, Qn, Qm	4	4
  VMLA.F32 Dd, Dn, Dm	2	81
  VMLA.F32 Qd, Qn, Qm	4	81
  1 5 cycles with dependency only on accumulator.
  NEON permute instructions	Issue cycles	Result latency
  VEXT.n Dd, Dn, Dm, #imm	1	4
  VEXT.n Qd, Qn, Qm, #imm	2	5
  VTRN.n Dd, Dn, Dm	2	5
  VTRN.n Qd, Qn, Qm	4	5
  VUZP.n Dd, Dn, Dm	2	5
  VUZP.n Qd, Qn, Qm	4	6
  VZIP.n Dd, Dn, Dm	2	5
  VZIP.n Qd, Qn, Qm	4	6
  VTBL.8 Dd, Dn, Dm	1	4
  VTBL.8 Dd, Dn-Dn+1, Dm	1	4
  VTBL.8 Dd, Dn-Dn+2, Dm	2	5
  VTBL.8 Dd, Dn-Dn+3, Dm	2	5

• avcodec_decode_video2 fails to decode after frame resolution change

  10 avril 2021, par Krzysztof Kansy

  I'm using ffmpeg in Android project via JNI to decode real-time H264 video stream. On the Java side I'm only sending the the byte arrays into native module. Native code is running a loop and checking data buffers for new data to decode. Each data chunk is processed with :
  

  



  int bytesLeft = data->GetSize();
int paserLength = 0;
int decodeDataLength = 0;
int gotPicture = 0;
const uint8_t* buffer = data->GetData();
while (bytesLeft > 0) {
    AVPacket packet;
    av_init_packet(&packet);
    paserLength = av_parser_parse2(_codecPaser, _codecCtx, &packet.data, &packet.size, buffer, bytesLeft, AV_NOPTS_VALUE, AV_NOPTS_VALUE, AV_NOPTS_VALUE);
    bytesLeft -= paserLength;
    buffer += paserLength;

    if (packet.size > 0) {
        decodeDataLength = avcodec_decode_video2(_codecCtx, _frame, &gotPicture, &packet);
    }
    else {
        break;
    }
    av_free_packet(&packet);
}

if (gotPicture) {
// pass the frame to rendering
}


  



  The system works pretty well until incoming video's resolution changes. I need to handle transition between 4:3 and 16:9 aspect ratios. While having AVCodecContext configured as follows :

  



  _codecCtx->flags2|=CODEC_FLAG2_FAST;
_codecCtx->thread_count = 2;
_codecCtx->thread_type = FF_THREAD_FRAME;

if(_codec->capabilities&CODEC_FLAG_LOW_DELAY){
    _codecCtx->flags|=CODEC_FLAG_LOW_DELAY;
}


  



  I wasn't able to continue decoding new frames after video resolution change. The got_picture_ptr flag that avcodec_decode_video2 enables when whole frame is available was never true after that.
  
This ticket made me wonder if the issue isn't connected with multithreading. Only useful thing I've noticed is that when I change thread_type to FF_THREAD_SLICE the decoder is not always blocked after resolution change, about half of my attempts were successfull. Switching to single-threaded processing is not possible, I need more computing power. Setting up the context to one thread does not solve the problem and makes the decoder not keeping up with processing incoming data.
  
Everything work well after app restart.
  

  



  I can only think of one workoround (it doesn't really solve the problem) : unloading and loading the whole library after stream resolution change (e.g as mentioned in here). I don't think it's good tho, it will propably introduce other bugs and take a lot of time (from user's viewpoint).

  



  Is it possible to fix this issue ?

  



  EDIT :
  
I've dumped the stream data that is passed to decoding pipeline. I've changed the resolution few times while stream was being captured. Playing it with ffplay showed that in moment when resolution changed and preview in application froze, ffplay managed to continue, but preview is glitchy for a second or so. You can see full ffplay log here. In this case video preview stopped when I changed resolution to 960x720 for the second time. (Reinit context to 960x720, pix_fmt: yuv420p in log).

  


• OpenCV 4.5.2 takes a long time (>100ms) to retrieve a single frame from a webcam, C++ on Windows 10

  9 juin 2021, par Mustard Tiger

  I've been having a tough time getting my webcam working quickly with opencv. Frames take a very long time to read, (a recorded average of 124ms across 500 frames) I've tried on three different computers (running Windows 10) with a logitech C922 webcam. The most recent machine I tested on has a Ryzen 9 3950X, with 32gbs of ram ; no lack of power.

  


  Here is the code :

  


  cv::VideoCapture cap = cv::VideoCapture(m_cameraNum);&#xA;&#xA;// Check if camera opened successfully&#xA;if (!cap.isOpened())&#xA;{&#xA;    m_logger->critical("Error opening video stream or file\n\r");&#xA;    return -1;&#xA;}&#xA;&#xA;bool result = true;&#xA;result &amp;= cap.set(cv::CAP_PROP_FRAME_WIDTH, 1280);&#xA;result &amp;= cap.set(cv::CAP_PROP_FRAME_HEIGHT, 720);&#xA;&#xA;bool ready = false;&#xA;std::vector<string> timeLog;&#xA;timeLog.reserve(50000);&#xA;int i = 0;&#xA;&#xA;while (i &lt; 500)&#xA;{&#xA;    auto start = std::chrono::system_clock::now();&#xA;    &#xA;    cv::Mat img;&#xA;    ready = cap.read(img);&#xA;&#xA;    // If the frame is empty, break immediately&#xA;    if (!ready)&#xA;    {&#xA;        timeLog.push_back("continue");&#xA;        continue;&#xA;    }&#xA;&#xA;    i&#x2B;&#x2B;;&#xA;    auto end = std::chrono::system_clock::now();&#xA;    timeLog.push_back(std::to_string(std::chrono::duration_cast(end - start).count()));&#xA;}&#xA;&#xA;for (auto&amp; entry : timeLog)&#xA;    m_logger->info(entry);&#xA;&#xA;cap.release();&#xA;return 0;&#xA;</string>

  


  Notice that I write the elapsed time to a log file at the end of execution. The average time is 124ms for debug and release, and not one instance of "continue" after half a dozen runs.

  


  It doesn't matter if I use USB 2 or USB 3 ports (the camera is USB2) or if I run a debug build or a release build, the log file will show anywhere from 110ms to 130ms of time for each frame. The camera works fine in other app, OBS can get a smooth 1080@30fps or 720@60fps.

  


  Stepping through the debugger and doing a lot of Googling, I've learned the following about my system :

  


  

  • The backend chosen by default is DSHOW. GStreamer and FFMPEG are also available.

  


  • DSHOW uses FFMPEG somehow (it needs the FFMPEG dll) but I cannot use FFMPEG directly through opencv. Attempting to use cv::VideoCapture(m_cameraNum, cv::CAP_FFMPEG) always fails. It seems like Opencv's interface to FFMPEG is only capable of opening video files.

  


  • Microsoft really screwed up camera devices in Windows a few years back, not sure if this is related to my problem.

  


  


  Here's a short list of the fixes I have tried, most taken from older SO posts :

  


  

  • result &= cap.set(cv::CAP_PROP_FRAME_COUNT, 30) ; // Returns false, does nothing

  


  • result &= cap.set(cv::CAP_PROP_CONVERT_RGB, 0) ; // Returns true, does nothing

  


  • result &= cap.set(cv::CAP_PROP_MODE, cv::VideoWriter::fourcc('M', 'J', 'P', 'G')) ; // Returns false, does nothing

  


  • Set registry key from http://alax.info/blog/1693 that should disable the new Windows camera server.

  


  • Updated from 4.5.0 to 4.5.2, no change.

  


  • Asked device manager to find a newer driver, no newer driver found.

  


  


  I'm out of ideas. Any help ?