Intel OpenCL Access Violation

Pagina: 1
Acties:

Vraag


Acties:
  • 0 Henk 'm!

  • diondokter
  • Registratie: Augustus 2011
  • Laatst online: 10-07 23:17

diondokter

Dum spiro, spero

Topicstarter
Hallo!

Ik heb een raar probleem met OpenCL wanneer het gecompileerd wordt voor Intel CPU's (zowel die van mijn desktop (i7 3770K) als laptop (i5 4210M)).

Ik heb een struct gedeclareerd met daarin 7 floats.
Ook heb ik een function die zo'n struct returnt.
Het probleem is dat wanneer ik *iets* met de gereturnde waarde doe, ik een Access violation krijg, maar dat alleen op 1 specifieke plek.

Een beetje code:
C:
1
2
3
4
5
6
7
8
9
10
11
12
// Take the source pixel by sampling the image based on the calculated UV
struct PixelData sourcePixel = SampleImage(myUV, sourceCamera, imagePixels);

// Sample logica
for (samples)
    ...
    for (cameras)
        ...
        // Get the pixel
        struct PixelData samplePixel = SampleImage(sampleUV, cameras + i, imagePixels);

        confidence += PixelData_Compare(&sourcePixel, &samplePixel) / (cameraCount - 1);

De functie SampleImage wordt hier twee keer gebruikt. Wanneer sourcePixel wordt gebruikt, dan komt die access violation, maar bij samplePixel niet. Als ik in de functie PixelData_Compare de sourcePixel pointer overschrijf met de pointer van samplePixel, dan gaat het weer goed (al is het resultaat fout natuurlijk). Ook als ik sourcePixel alleen maar declareer en de functie wegcomment gaat alles goed.

Ik heb van alles geprobeerd te wijzigen zoals alles met pointers doen en ook alle pointers weghalen. Niks helpt.

Access violation.
De exacte message die Visual Studio me geeft is:
Exception thrown at 0x00000129353B2A06 in Cli.exe: 0xC0000005: Access violation reading location 0x000001293C186D04.

Maar die location is erg raar. Ik ben namelijk ook de disassembly in gedoken en heb het volgende gezien:

De instructie waar de violation gebeurt doet dit:
00000129353B2A06 vmovss xmm1,dword ptr [r12+r9+4]
Het is een AVX instructie dat (in dit geval) de 32-bit waarde in de 128-bit xmm1 register plaatst.

De waarden zijn als volgt:
r12 0x000001293c190000
r9 0xffffffffffff6d00

Als we de FF waarden niet mee tellen, dan zou de pointer in de instructie moeten wijzen naar:
0x000001293c196d04

Dit is niet dezelfde locatie als de access violation!
Er zit exact 0x10000 tussen. Dit gebeurt altijd.

Ik weet dus niet meer waar ik moet zoeken, want het lijkt wel alsof de instructies verkeerd uitgevoerd worden. :P Ik hoop dat iemand hier me op weg kan helpen, want na 8 uur zonder enkele vooruitgang zijn mijn ideeën op.

Relevante info:
Visual Studio 2017
C++ project
Intel OpenCL SDK
Gecompileerd op 64-bit (maar gebeurt ook met 32-bit)

Hopelijk is dit verhaal niet te wazig.
Bedankt voor het lezen.

Beste antwoord (via diondokter op 26-10-2018 16:08)


  • farlane
  • Registratie: Maart 2000
  • Laatst online: 12-07 11:40
Heb wel een wild guess: ergens wordt er buiten de PixelData struct geschreven, maar omdat samplePixel ergens verder op de stack staat levert het daar geen probleem op en bij sourcePixel wel. (Of misschien wel een andere fout waarmee je de stack trashed)

Snelle test : declareer een (dummy) array (die niet weggeoptimaliseerd mag worden) op de stack zodat sourcePixel ook verder op de stack komt te staan.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

Alle reacties


Acties:
  • Beste antwoord
  • +1 Henk 'm!

  • farlane
  • Registratie: Maart 2000
  • Laatst online: 12-07 11:40
Heb wel een wild guess: ergens wordt er buiten de PixelData struct geschreven, maar omdat samplePixel ergens verder op de stack staat levert het daar geen probleem op en bij sourcePixel wel. (Of misschien wel een andere fout waarmee je de stack trashed)

Snelle test : declareer een (dummy) array (die niet weggeoptimaliseerd mag worden) op de stack zodat sourcePixel ook verder op de stack komt te staan.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


Acties:
  • +1 Henk 'm!

  • diondokter
  • Registratie: Augustus 2011
  • Laatst online: 10-07 23:17

diondokter

Dum spiro, spero

Topicstarter
Bedankt voor het reageren!

Hoewel extra arrays toevoegen niks veranderde, deed je suggestie me wel denken aan de volgorde waarop alle code wordt uitgevoerd.
De sourcePixel wordt in de code voor de loop uitgerekend. Maar omdat alles zo geöptimaliseerd wordt, kan ik me voorstellen dat de daadwerkelijke calculatie bij de eerste access van het resultaat gebeurt. Als dat zo is, dan zou het misschien niet de access zelf zijn die verkeerd gaat, maar de functie die de waarde uitrekent.

En zo ging ik kijken of daar de fout lag, en dat was zo!
Blijkbaar ging de code niet goed om met negatieve uv waarden waardoor een pixel buiten de array aangesproken werd.