Skip to content

Single-source the per-key scoring kernel across CUDA / OpenCL / CPU back-ends #38

Description

@felixx-sp

Priority: P1 · Confidence: high · Effort: medium

Problem

The per-key decode + scoring logic is duplicated across all three GPU/CPU back-ends:

  • src/bruteforce.cu (CUDA/HIP, __device__)
  • src/dmrcrack.cl (OpenCL kernel source)
  • src/bruteforce.c (portable CPU)

These are hand-kept in sync. A bug fixed in one is easily missed in the others. Concrete evidence: the Hytera EP keystream fix (kiv[i] = key5[i] ^ MI[i], 40-bit MI) was applied to bruteforce.cu and bruteforce.c but silently missed in dmrcrack.cl (it kept kiv[0]=key5[0] and a 32-bit MI) until a follow-up pass. The OpenCL backend would have produced wrong Hytera keys.

include/dmr_tables.h and include/hytera_ks.h already single-source parts of this (the de-interleave tables and the Hytera keystream). The rest of the scoring kernel (de-interleave → mbe demod → extract → pack → RC4 → inter-frame Hamming + bit-freq chi²) is still triplicated.

Suggested fix

Move the scoring kernel body into a shared header included by bruteforce.cu, dmrcrack.cl and bruteforce.c, with thin macro shims to bridge the dialects (__device__/inline/__kernel, __shared__/__local, uchar/unsigned char). One implementation, compiled per back-end. Guard with a cross-backend known-answer test.

Why it matters

Eliminates the "fixed in one backend, not the others" bug class that already bit the Hytera path. Prerequisite for the broader multi-backend architecture work.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions