Jump to content

Photo

GPU with mutiple interrupts


44 replies to this topic

#26 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • 2,550 posts
  • Location:Manchester UK

Posted Sat Jul 21, 2018 6:44 PM

It does seem weird (but not unbelievable) that the GPU core would be buggy around interrupts but not the DSP, they're not identical, but I'd have expected them to be mostly similar.

 

What do you have running in the main loop whilst the interrupts are being fired?  Perhaps try it with as minimal a main loop as possible?  just a bunch of nops and a back to the start?



#27 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 138 posts
  • Location:Germany

Posted Mon Jul 23, 2018 12:42 AM

I checked it. And yepp, in an idle loop (only reading joypad ports) no issue.

Added then some blitter code, still no issue.

It happens only during gameplay. There is a lot more stuff happening with the blitter.

Currently all happens redrawing happens in the VBL (not the interrupt, it just sets a flag).

 

I still suspect my code but it is getting very unlikely.

 

This really bugs me ;-) I do not like workarounds, they bite back someday.



#28 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • 2,550 posts
  • Location:Manchester UK

Posted Mon Jul 23, 2018 3:29 AM

Perhaps try moving the game logic/pad reading etc, to the DSP and save the GPU for single fire stuff triggered from the DSP? 

Wonder if maybe there is a particular instruction that an interrupt happening when it's processing causes the issue (like MOVEI), and as you say your code is just being unlucky.



#29 Zerosquare OFFLINE  

Zerosquare

    River Patroller

  • 2,695 posts
  • Location:France

Posted Mon Jul 23, 2018 9:04 AM

It happens only during gameplay.

You could remove the gameplay. After all, you're writing a Jaguar game. :)

#30 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 138 posts
  • Location:Germany

Posted Wed Jul 25, 2018 6:10 AM

You could remove the gameplay. After all, you're writing a Jaguar game. :)

I will push this comment and pop it when I found the bug. Then I laugh :-|



#31 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 138 posts
  • Location:Germany

Posted Wed Jul 25, 2018 6:15 AM

Perhaps try moving the game logic/pad reading etc, to the DSP and save the GPU for single fire stuff triggered from the DSP? 

Wonder if maybe there is a particular instruction that an interrupt happening when it's processing causes the issue (like MOVEI), and as you say your code is just being unlucky.

I come closer. If I run my loop with VBL sync, no crash. If I remove the VBL sync and call my debug printhex (no blitter, plain GPU), it crashes. If I add some nop to my OBL interrupt code. It doesn't.

I guess the reason is that I delay the timer interrupt. VBL every 20ms, timer every 1ms.

I have to say: I am so happy I could buy a SKUNK board. Doing this with BJL only would be a hard thing.



#32 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • 2,550 posts
  • Location:Manchester UK

Posted Wed Jul 25, 2018 7:15 AM

Ah, so it could be that the 2nd interrupt is trying to fire whilst the first is still being serviced?

 

When you say you add some nops, how many?  I have had issues with alignment in my code before and had to add in extra nop or force alignment.  I am trying to remember exactly what the cause was as obviously all opcodes are 16bit..

 

Ah I *think* it was I was trying to load from a non long aligned address (jump table), which it turns out the JRISC isn't a huge fan of doing IIRC.  I had the jump tables within the text section, so if I added a nop or single instruction then it would knock the table out of alignment and BOOM.

Skunks are nice, but I still think BJL has its place :)  I am sure with a bit of work, some similar bi-directional comms for debug signalling could be achieved with BJL too (I too love having the ability to output hexdumps of registers/stacks etc from my debug libraries :D )



#33 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 138 posts
  • Location:Germany

Posted Wed Jul 25, 2018 7:29 AM

Ah, so it could be that the 2nd interrupt is trying to fire whilst the first is still being serviced?

 

When you say you add some nops, how many?  I have had issues with alignment in my code before and had to add in extra nop or force alignment.  I am trying to remember exactly what the cause was as obviously all opcodes are 16bit..

 

Ah I *think* it was I was trying to load from a non long aligned address (jump table), which it turns out the JRISC isn't a huge fan of doing IIRC.  I had the jump tables within the text section, so if I added a nop or single instruction then it would knock the table out of alignment and BOOM.

Skunks are nice, but I still think BJL has its place :)  I am sure with a bit of work, some similar bi-directional comms for debug signalling could be achieved with BJL too (I too love having the ability to output hexdumps of registers/stacks etc from my debug libraries :D )

 

I added 5 nops. But it is no alignment issue (I think). Because if I put the nopS outside the execution path, the same crash happens.

Yes, the GPU can only read 32bit aligned from internal RAM. I need to add a warning in lyxass as I fell into this trap as well.

 

Regarding BJL, it is actually bi-directional. On the ST I wrote debjag (a bugaboo clone). You could dump registers, memory, single-step, disassemble and even had a line-assembler.

But it is 68k so I never ported it to PC. BJL was planned as complete development tool-set. Well, the end of Atari came to early :(


Edited by 42bs, Wed Jul 25, 2018 7:30 AM.


#34 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • 2,550 posts
  • Location:Manchester UK

Posted Wed Jul 25, 2018 8:27 AM

The nops wouldn't have to be in the execution path, anywhere in text would shift the rest of the code on by 2-bytes.  (which is how I first twigged the issue as changing non-called code broke or fixed the issue).

Yup exactly what I was meaning :)  Update lo.exe to have a debug/console mode like skunk and some lib to run on the jag and bingo. 

Atari will never die whilst we hack around with it! (well real Atari, not the sham that currently wields the name!)



#35 Zerosquare OFFLINE  

Zerosquare

    River Patroller

  • 2,695 posts
  • Location:France

Posted Thu Jul 26, 2018 1:43 PM

SCPCD wrote a debugger that works over BJL. But I don't think he released it publicly.

#36 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 138 posts
  • Location:Germany

Posted Fri Jul 27, 2018 12:00 AM

Matthias gave me the hint to look into the DOOM sources. That's what they do:

    bclr    #3,r29              ; clear IMASK
    bset    #12,r29              ; and interrupt latch

    load    (r31),r28           ; get last instruction address
    move    R0_INTSTACK,r31        ; reset stack

So, they do not increment the stack pointer. Rather reset it. Which is what I do in my workaround.

I guess a clearer sign for a silicon bug is not possible. :-)

 

We should spread this as warning in the f0rum.



#37 CyranoJ OFFLINE  

CyranoJ

    Quadrunner

  • 5,455 posts
  • RAPTOR in LOCAL
  • Location:Adelaide, SA

Posted Fri Jul 27, 2018 12:14 AM

I guess it's only a problem with multiple interrupts. Weird how the DSP isn't affected, though.



#38 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 138 posts
  • Location:Germany

Posted Fri Jul 27, 2018 12:43 AM

I guess it's only a problem with multiple interrupts. Weird how the DSP isn't affected, though.

 

At least the DOOM source does the same for the DSP.



#39 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • 2,550 posts
  • Location:Manchester UK

Posted Fri Jul 27, 2018 4:44 AM

I guess they hit the problem on the GPU and just assumed it would be the same on the DSP.  I am so glad it doesn't seem to be!

 

I wonder if the bug is the same on the different GPU versions.

 

Perhaps (in my instance anyway), as all the interrupts are timer based there is no issue, perhaps the external interrupts are the cause?



#40 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 138 posts
  • Location:Germany

Posted Fri Jul 27, 2018 5:07 AM

I guess they hit the problem on the GPU and just assumed it would be the same on the DSP.  I am so glad it doesn't seem to be!

 

I wonder if the bug is the same on the different GPU versions.

 

Perhaps (in my instance anyway), as all the interrupts are timer based there is no issue, perhaps the external interrupts are the cause?

 

Since the bug happens on high-frequency interrupts it should happen on the DSP early as the playback uses a 22kHz or 44kHz interrupt, right?
But I think even though the ISA is quiet equal, the DSP is different in so many parts, that it is likely the bug is only in the GPU.

If you just think of the bus width, memory size etc. . So I doubt they used the same RTL for both chips.



#41 swapd0 OFFLINE  

swapd0

    Moonsweeper

  • 257 posts

Posted Fri Jul 27, 2018 6:53 AM

off topic 

I also wrote a BJL debugger (for 68000, GPU & DPS), with a BeOS client. Maybe some day I'll procrastinate less and port it to OS-X.



#42 CyranoJ OFFLINE  

CyranoJ

    Quadrunner

  • 5,455 posts
  • RAPTOR in LOCAL
  • Location:Adelaide, SA

Posted Fri Jul 27, 2018 7:00 AM

off topic 

I also wrote a BJL debugger (for 68000, GPU & DPS), with a BeOS client.

 

It was you! You were the single user! :D



#43 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 138 posts
  • Location:Germany

Posted Fri Jul 27, 2018 7:09 AM

off topic 

I also wrote a BJL debugger (for 68000, GPU & DPS), with a BeOS client. Maybe some day I'll procrastinate less and port it to OS-X.

BeOS? Well, isn't programming the Jaguar pain enough *rotfl*



#44 JagMod OFFLINE  

JagMod

    Chopper Commander

  • 202 posts
  • Location:Texas

Posted Sat Jul 28, 2018 2:22 AM

 

Since the bug happens on high-frequency interrupts it should happen on the DSP early as the playback uses a 22kHz or 44kHz interrupt, right?
But I think even though the ISA is quiet equal, the DSP is different in so many parts, that it is likely the bug is only in the GPU.

If you just think of the bus width, memory size etc. . So I doubt they used the same RTL for both chips.

I've been following this thread.

I checked my code and I am doing what you were, not what DOOM is.

 

I have two interrupts turned on in the GPU, one from the OP, the other from the Blitter.

The OP interrupts once per vblank, the blitter interrupts ~10,000 times in a vblank.

 

So maybe it isn't a frequency problem as much as it is which interrupts are being used.

 

I've never used the timer interrupt with the GPU.

You said you were doing 1ms timer interrupts. (1000 times a second)

The Blitter is interrupting in the 60k to 80k times a second, and I've never seen this bug.



#45 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 138 posts
  • Location:Germany

Posted Sat Jul 28, 2018 2:59 AM

I've been following this thread.

I checked my code and I am doing what you were, not what DOOM is.

 

I have two interrupts turned on in the GPU, one from the OP, the other from the Blitter.

The OP interrupts once per vblank, the blitter interrupts ~10,000 times in a vblank.

 

So maybe it isn't a frequency problem as much as it is which interrupts are being used.

 

I've never used the timer interrupt with the GPU.

You said you were doing 1ms timer interrupts. (1000 times a second)

The Blitter is interrupting in the 60k to 80k times a second, and I've never seen this bug.

 

Wow, I never found a use case for the blitter interrupt. I guess you are setting up a kind of task list and on every interrupt you setup another blitter job from this list?

 

And, yes, it is only a 1000 times :(

But good to know, that it should work.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users