cuda warp size and control divergence - cuda

I have query about following question:
Suppose, we have a 9*7 picture (7 pixels in the x direction and 9 pixels in the y direction), how many warps will have control divergence assuming block of 4*4 threads and 8 threads per warp?
How will the blocks and warps be organized here?
for x or horizontal direction, i can assume 2 blocks per row.Similarly,
for vertical direction, 3 blocks per column.
But, How will the warps are organized? Can someone point out the thread ids of the warps , and the cases where control divergence happens(Thread ids etc for those).
thanks

Suppose, we have a 9*7 picture (7 pixels in the x direction and 9 pixels in the y direction), how many warps will have control divergence assuming block of 4*4 threads and 8 threads per warp?
Divergence is a property of the program (the code), not of the block/warp layout itself. If your algorithm operates identically across all pixels in the image then there will be no divergence whatsoever, irrespective of the number of threads and their organization. If your algorithm branches on warp boundaries, there will be no divergence either. Therefore, without seeing your code, your question is technically unanswerable.
If you're running with a block of 16 threads and 8 threads per warp (which is not physically possible on CUDA hardware: warps are made of 32 threads and their size is not configurable) then you might as well run without a GPU at all. These numbers are way too small to benefit from any hardware acceleration.
How will the blocks and warps be organized here? for x or horizontal direction, i can assume 2 blocks per row.Similarly, for vertical direction, 3 blocks per column. But, How will the warps are organized?
I'll stick to your example and try to provide a schema of the thread IDs, block IDs, warp IDs. Keep in mind that this layout is, in practice, impossible on CUDA hardware.
Image Global Thread IDs Block IDs Local Thread IDs
□□□□□□□ | 00 01 02 03 04 05 06 | 00 00 00 00 00 00 00 | 00 01 02 03 04 05 06
□□□□□□□ | 07 08 09 10 11 12 13 | 00 00 00 00 00 00 00 | 07 08 09 10 11 12 13
□□□□□□□ | 14 15 16 17 18 19 20 | 00 00 01 01 01 01 01 | 14 15 00 01 02 03 04
□□□□□□□ | 21 22 23 24 25 26 27 | 01 01 01 01 01 01 01 | 05 06 07 08 09 10 11
□□□□□□□ | 28 29 30 31 32 33 34 | 01 01 01 01 02 02 02 | 12 13 14 15 00 01 02
□□□□□□□ | 35 36 37 38 39 40 41 | 02 02 02 02 02 02 02 | 03 04 05 06 07 08 09
□□□□□□□ | 42 43 44 45 46 47 48 | 02 02 02 02 02 02 03 | 10 11 12 13 14 15 00
□□□□□□□ | 49 50 51 52 53 54 55 | 03 03 03 03 03 03 03 | 01 02 03 04 05 06 07
□□□□□□□ | 56 57 58 59 60 61 62 | 03 03 03 03 03 03 03 | 08 09 10 11 12 13 14
----------------------------------------------------------------------------
Image Global Warp IDs Block IDs Local Warp IDs
□□□□□□□ | 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00
□□□□□□□ | 00 01 01 01 01 01 01 | 00 00 00 00 00 00 00 | 00 01 01 01 01 01 01
□□□□□□□ | 01 01 02 02 02 02 02 | 00 00 01 01 01 01 01 | 01 01 00 00 00 00 00
□□□□□□□ | 02 02 02 03 03 03 03 | 01 01 01 01 01 01 01 | 00 00 00 01 01 01 01
□□□□□□□ | 03 03 03 03 04 04 04 | 01 01 01 01 02 02 02 | 01 01 01 01 00 00 00
□□□□□□□ | 04 04 04 04 04 05 05 | 02 02 02 02 02 02 02 | 00 00 00 00 00 01 01
□□□□□□□ | 05 05 05 05 05 05 06 | 02 02 02 02 02 02 03 | 01 01 01 01 01 01 00
□□□□□□□ | 06 06 06 06 06 06 06 | 03 03 03 03 03 03 03 | 00 00 00 00 00 00 00
□□□□□□□ | 07 07 07 07 07 07 07 | 03 03 03 03 03 03 03 | 01 01 01 01 01 01 01
----------------------------------------------------------------------------
and the cases where control divergence happens(Thread ids etc for those)
As mentioned above, divergence being a property of the code and not the thread layout, this question cannot be answered without code.

Related

Reverse CRC16 calculation

I'm trying to understand how is calculated the CRC at the end of a radio packet.
Here are a few examples:
11 00 01 0D 30 10 05 1F 11 ED 7E 01 00 01 B9 33
11 00 01 0D 30 10 05 1F 11 ED 7E 01 00 00 B9 32
11 00 01 1D 30 10 05 1F 11 ED 7E 01 00 00 EA CC
11 00 01 2D 30 10 05 1F 11 ED 7E 01 00 00 1E CE
The 4th byte is a sequence number. All other bytes are constant. The last 2 bytes definitely look like a CRC16, as these are the only ones changing when the sequence byte increases. The last 2 bytes are not related to the time, as I can reproduce that exact same sequence anytime.
Here are a few more examples, from the same device but with a different command:
16 00 01 60 20 10 05 1F 11 ED 7E 01 02 00 04 00 02 00 65 32 CC
16 00 01 CB 20 10 31 53 11 ED 7E 01 42 00 04 00 02 00 65 B4 B9
This time again, the last 2 bytes look like a CRC16.
I've tried many CRC calculations, using online calculators like crccalc.com.
I've also used the RevEng tool, but got no results.
I can't figure out the method of calculation, so I must be missing something.
Any help to determine the calculation would be welcome.
Thanks!
It is the CRC-16/XMODEM, computed on your examples with the first three bytes and the last two bytes before the CRC removed, and then, oddly, that CRC exclusive-or'ed with the two bytes that precede it (those that were excluded from the CRC calculation). The resulting 16-bit value is appended in big-endian order.

Converting a hexdump back to a rar

I have a plaintext file that I wish to convert to something I can extract.
00000000 52 61 72 21 1a 07 01 00 f3 e1 82 eb 0b 01 05 07 |Rar!............|
00000010 00 06 01 01 80 80 80 00 3b fd 42 9f 51 02 03 31 |........;.B.Q..1|
00000020 a0 02 06 82 03 80 83 02 20 15 d4 6e 5b 46 b6 57 |........ ..n[F.W|
00000030 80 03 01 09 69 6e 73 74 72 2e 74 78 74 30 01 00 |....instr.txt0..|
00000040 03 0f 44 a5 ce af b3 09 b9 96 44 22 f4 99 ef 04 |..D.......D"....|
This is part of the file which made me believe it is a rar file. I tried using xxd with the -r option to no avail.
I tried the solution from here but it also didn't work.
Any ideas?
To solve my own question, and for future reference.
Use vim's visual block select to copy just the hex values into 'justhexvalues.txt'.
Then use xxd:
xxd -r -p justhexvalues.txt answer.rar
That was it.

How to determine endianness of this hexadecimal code

I have this code in hexadecimal bytes:
01 00 08 20 00 00 09 20 05 00 02 20 0c 00 00 00 03 00 02 11 20 48 09 01
01 00 08 21 03 00 00 08 1a 00 22 01 12 20 00 00 0c 00 00 00
How can I tell the endianmess of this?
When I plug it into here: https://onlinedisassembler.com/odaweb/, I get this code:
Where does the first line in binary 20080001 come from in the hexadecimal?
This is in little endianness. When I change it to big endianness, I get:
Is the above code wrong?

MasterCard Generate AC

I tried to process payment with MasterCard / MIR.
I do read data from VISA successfully after send PDOL, but MS does not requires PDOL.
1st step in transaction:
Select 2PAY.SYS
[SEND] : 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
[READ] : 6F 23 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 11
BF 0C 0E 61 0C 4F 07 A0 00 00 00 04 10 10 87 01 01 90 00
2nd step:
[SEND] : 00 A4 04 00 07 A0 00 00 00 04 10 10 00
F
[READ] : 6F 44 84 07 A0 00 00 00 04 10 10 A5 39 50 0A 4D 41 53 54 45 52 43 41 52 44 5F 2D 04 72 75 65 6E 87 01 01 9F 11 01 01 9F 12 0A 4D 41 53 54 45 52 43 41 52 44 BF 0C 0F 9F 4D 02 0B 0A 9F 6E 07 06 43 00 00 30 30 00 90 00
Card does not requres PDOL
3rd step:
[SEND] : 80 A8 00 00 02 83 00 00
[READ] : 77 16 82 02 19 80 94 10 08 01 01 00 10 01 01 01 18 01 02 00 20 01 02 00 90 00
Recieved Application File Locator (AFL)
Step 4:
Read all available data.
[SEND] : 00 B2 01 0C 00
and other sectors
I red all sectors. But there are not tags requires for payment: 9F26 - Application Cryptogram, 9F37 - Unpredictable Number, 9F36 - Transatcion Counter.
To get this tags I could make command Generate AC with CDOL, but how to generate CDOL?
Card says about CDOL1 and CDOL2. And CDOL1 requires tags that card generate itself.
Card answers, contains CDOL1 and CDOL2:
70 81 A0 57 13 55 45 46 77 77 25 42 79 D2 01 12 01 58 11 10 00 00 79 0F 5A 08 55 45 46 77 77 25 42 79 5F 24 03 20 11 30 5F 25 03 17 11 01 5F 28 02 06 43 5F 34 01 01 8C 21 9F 02 06 9F 03 06 9F 1A 02 95 05 5F 2A 02 9A 03 9C 01 9F 37 04 9F 35 01 9F 45 02 9F 4C 08 9F 34 03 8D 0C 91 0A 8A 02 95 05 9F 37 04 9F 4C 08 8E 0E 00 00 00 00 00 00 00 00 42 03 1E 03 1F 03 9F 07 02 3D 00 9F 08 02 00 02 9F 0D 05 B4 50 84 00 00 9F 0E 05 00 00 00 00 00 9F 0F 05 B4 70 84 80 00 9F 42 02 06 43 9F 4A 01 82 90 00
How generate offline limit transaction using paypass? How to do Generate AC?
Thank you!
CDOL1 and CDOL2 splits like below. Tag and its lengths. You are supposed to provide the data alone in the same order and size as you would for PDOL. In the below case, apart from two towards the bottom, rest all are available in the terminal ready to use.
CDOL1
9F02 06 //transaction amount
9F03 06 //other amount, cashback
9F1A 02 //termial country
95 05 //TVR terminal has arrived after terminal risk management
5F2A 02 //currency code
9A 03 //Transaction date
9C 01 //transaction type
9F37 04 //unpredictable number
9F35 01 //terminal type
9F45 02 //data Authentication code from Transaction Related Data ODA
9F4C 08 //icc dynamic number from Transaction Related Data ODA
9F34 03 //cvm results
CDOL2
91 0A //issuer authentication data
8A 02 //ARC
95 05 //TVR
9F37 04 //unpredictable number
9F4C 08 //icc dynamic number
9F26 and 9F36 will be returned by the card in response to your GEN AC.
9F37 is generated by the terminal.

How to merge[union] one column[field] data in MySQL!

E.g: DISTINCT file_sn and got the merge[union,unique] all_files result:
user_id file_sn all_files[char]
1 1 01 02 05
2 1 02 05
3 1 05 06 07 08
4 1 10 11 12 15
So,I want to merge[union] the column: all_files so I could get the unique all_files data like:
01 02 05 06 07 08 10 11 12 15
Thank you very much~~
[UPDATE]
My query to get the all all_files query:
SELECT file_sn, GROUP_CONCAT(DISTINCT all_files SEPARATOR ' ')
FROM `myTable`
GROUP BY file_sn
It will return:
01 02 05 02 05 05 06 07 08 05 06 07 08