Who's Online |
58 user(s) are online ( 49 user(s) are browsing Forums)
Members: 1
Guests: 57
m3x,
more...
|
|
Headlines |
-
nvme_driver.lha - driver/storage
Mar 26, 2023
-
amiarcadia.lha - emulation/gamesystem
Mar 26, 2023
-
animwebconverter.lha - graphics/misc
Mar 27, 2023
-
vanillara.lha - game/strategy
Mar 25, 2023
-
vanillatd.lha - game/strategy
Mar 25, 2023
-
amitube.lha - video/play
Mar 25, 2023
-
amissl-sdk.lha - development/misc
Mar 23, 2023
-
unext.lha - game/platform
Mar 23, 2023
-
mce.lha - game/utility
Mar 23, 2023
-
amissl.lha - library/misc
Mar 23, 2023
|
|
|
|
|
Re: USB fail
|
Posted on: Yesterday 10:49
#1
|
Home away from home 
|
@kas1e Quote: That was happens only on x5000 and only with fat32 (so crossdos), and only with usb sticks Ah, that explains why I never encountered it. I already had ZitaFTP up and running before I got my X5000. Hans
|
|
|
|
|
|
Re: USB fail
|
Posted on: Yesterday 4:06
#2
|
Home away from home
|
@kas1e Quote: Is it crossdos (fat) filesystem you use for ? If so, then it's known that when you use crossdoss on usb sticks on os4, it can put some noise-junk-trash into the files while copy them in some conditions. Bug reports about created, test cases as well, etc, long ago.
But since some time i didn't have those issues anymore, maybe because of beta USB stack, dunno. Really? I don't think I've ever hit that problem, and I've copied a lot via USB in the past. Mind you, I haven't used USB sticks since I got ZitaFTP Server to a usable state. Hans
|
|
|
|
|
|
Re: I don't get ScreenMode prefs and monitors
|
|
Home away from home
|
@Deniil Quote: So even though the file sizes are not the same for both "monitors", they are the same. Do they load anything, or is someone just using their tooltypes? For the primary graphics card, only the tooltypes are read. That's because the graphics card was started before DOS was available, and DEVS:Monitors was, therefore, unavailable. It's different for the secondary card. In that case, DEVS:Monitors is a small executable that gets the graphics.library to start the *.card driver. Quote: And maybe my memory is a bit hazy about P96Mode but at least it allowed you to try out stuff on-the-fly. It did, but that didn't mean that the mode you created was added to the mode database and available for the rest of the system to use. Hans
|
|
|
|
|
|
Re: I don't get ScreenMode prefs and monitors
|
|
Home away from home
|
@Deniil Quote: - What's "Board 0"? Where does it get that from? Board 0 is the first graphics board in your system (in your case, the only board in the system). It's a generic name given to it, most likely because the NameInfo struct limits display mode names to 32 characters, meaning that "Radeon HD 6570: 1920x1080 ARGB32" won't fit. The ScreenMode prefs' monitors tab is basically a UI for editing the tool-types of the files in DEVS:Monitors. It's completely disconnected from the main screen mode prefs. It was bolted on to ScreenMode prefs Quote: - What's the difference between my "Radeon" and "Radeon HD 6570" monitors? They're two different monitor files in DEVS:Monitors/. In your case they're effectively for the same monitor, and it sounds like the "Radeon" file is actually being used. The AmigaOS installer probably created "Radeon HD 6570," and you may have created the "Radeon" one some other time. The "monitor" configuration loading is rather confusing. On boot up it'll look for a monitor file that matches the name of the detected graphics card up to CMPLENGTH characters (CMPLENGTH is a tooltype). To confuse things further, the BOARDNAME tooltype needs to match the card's name (up to CMPLENGTH characters). If you have a second graphics card, then you'll need a PCIGraphics monitor file. Why? Because all of our graphics drivers are loaded via the PCIGraphics.card driver. Yes, it's confusing... Quote: - What is a DEVS:Monitors/"monitor" anyway? The driver is a Kickstart/*.chip file. AFAIK pre-RTG the monitor file defined the timings for special monitors that could be connected to the Amiga's RGB output. The creators of Picasso96 decided to use DEVS:Monitors to store graphics card settings as "monitor files" (including monitor timings). It's a hack that probably made sense at the time, but doesn't make sense now. Quote: Why can't I add a resolution on-the-fly to test? Why a reboot?!? Because nobody wrote the code needed to dynamically update the screen-mode database without rebooting. Quote: This prefs just seems to very unintuitive, and I've been an active Amiga user since '92. Agreed. This is one area (of many) that could use a big update. Any change should be well thought through, though, or we'll end up with a bigger mess. If we're not careful then it'll become even messier with multiple monitors connected. IMHO, DEVS:Monitors should be for actual monitors as identified by their EDID (or graphics card & connector as backup if EDID fails). Graphics card configuration settings should be stored elsewhere. Quote: Picasso96Mode was clear and straight-forward. Technical, yes, but not fuzzy and unclear. I've also use CyberGfx and other tweak tools that could do realtime change to the frequencies etc. Interesting, I find Picasso96Mode confusing. I need to relearn how to use it every time. IIRC, it'll allow you to test out modes, but you still need to reboot the system to be able to use your new custom modes. Hans
|
|
|
|
|
|
Re: Amigans.net Game Competitions - Game Suggestions
|
|
Home away from home
|
@afxgroup
Looks nice. Does this mean that you've ported Raylib to OS4?
Hans
|
|
|
|
|
|
Re: power managment and gfx cards discussion
|
|
Home away from home
|
@kas1e
Yes, I know. It looks like the X5000 DMA enabled version hasn't been released yet (rjd324 clearly doesn't have it), and I have no idea when it'll be available to end-users.
Hans
|
|
|
|
|
|
Re: power managment and gfx cards discussion
|
|
Home away from home
|
@rjd324 Quote: Why do you think they're appalling? What's your reference point to compare? Quote: Having spent so much time, effort and money into these things and having even spent the money to convert the single RAM stick in the X5000 to two seperate ones etc, etc the score of the X5 seems particularly dissapointing.
Are they bad, and if so, how to improve them? Your X5000 is let down by the MemCopy scores. Compare them side-by-side, and you'll see that the X1000's WritePixelArray/ReadPixelArray are DMA accelerated, but the X5000's are not. That results in a very steep performance penalty (especially ReadPixelArray). This in turn hurts the random test, because each of the operations are run randomly, including WritePixelArray & ReadPixelArray. There's nothing you can do about it. I expect an updated graphics.library will be released at some point that will include DMA accelerated WritePixelArray() & ReadPixelArray() for the X5000. Semi-related: I noticed a few weird results at the top of the AmigaOS GfxBench2D charts. A Pegasos II with a (crappy) Silicon Motion SM502? I wasn't aware that the SM502 was available as a plug in card for the Pegasos II. It's sitting at the top due to unbelievably high MemCopy, FillRect, BlitRect & OverlappedBlitRect scores, and missing compositing scores (IIRC, the SM502 isn't capable of compositing). The MemCopy numbers efar exceeds AGP/PCI bandwidth, so I'm guessing that it's actually doing the MemCopy in RAM. FillRect may be higher due to using a 16-bit screen (which halves the bandwidth). EDIT: Actually, those MemCopy performance test results exceed the Pegasos II's RAM bandwidth as well. What's going on? EDIT2: Are these results from an emulated Pegasos II + SM502? The SM502 in the Sam460 is very slow ( link). Emulated hardware would make more sense, given the suspect details (e.g., "Unknown" processor). Hans
Edited by Hans on 2023/3/4 5:19:20
Edited by Hans on 2023/3/4 5:30:44
Edited by Hans on 2023/3/4 5:32:13
|
|
|
|
|
|
Re: power managment and gfx cards discussion
|
|
Home away from home
|
@Raziel Quote: Anything i need to perform so you might get a usable log?
Or is using the debug driver enough?
Should i let it run the gfx2d benchmark? Running the GfxBench2D benchmark might get some interesting power management info (don't upload the results, though). The rest of the info is printed during startup. Quote: Not part of the above, but i get a lot of these with the RX560
RadeonRX (0): Could not create a timer object, using ITimer->MicroDelay() instead What are you running that triggers that? I've only ever got that with AudioEvolution 4. That'll be gone with the next driver release... Hans
|
|
|
|
|
|
Re: power managment and gfx cards discussion
|
|
Home away from home
|
@Raziel
AMD's naming scheme has always been a bit weird and confusing. The high-end Polaris models are indeed Polaris10 (or 20/30),** and the low-end are Polaris 11 & 12. High-end cards are always released first because they want to show off the performance of the new GPU series. The low-end cards come later.
To confuse things more, the RX 590 came later. It appears to be a higher-clocked variant of the RX 580.
No idea why your RX 590 is performing so poorly. If you have the debug version of the driver, then you could record a log and send it to me (privately). I can have a look if there are any hints there.
Hans
** While wikipedia may list Polaris 10, 20, & 30, AMD's own drivers see them all as Polaris10. I'm guessing that they're all basically the same GPU series, but with slight differences (e.g., 12nm fabrication process vs 14nm).
|
|
|
|
|
|
Re: SDK 54.16 versus codebench
|
|
Home away from home
|
@geennaam
I remember occasionally encountering that years ago. Unfortunately, I could never figure out how to trigger it, and so couldn't submit a proper bug report. My suspicion was that something went wrong when switching between tabs.
Hans
|
|
|
|
|
|
Re: x5000 benchmarks / speed up
|
|
Home away from home
|
@geennaam Quote:
Unfortunately dcbtl opcode is not recognized by any of the gcc versions in the latest SDK. Unless I use the compiler switch -mcpu=G5.
But the generated code will crash immediately of course.
Even mcpu=e5500 doesn't recognize those 64bytes cacheline opcodes.
Try: -mcpu=G5 -mno-powerpc64 Quote: DCBA is actually still supported by the e5500 ( see e5500 rm). But, depending on a bit in the l1 cache control register, it works on half or full cache lines. The new opcode e5500 dcbal opcode works always on full cachelines. But again not recognized by gcc. Interesting. One annoying thing about the cache hint instructions, is the varying behaviour on different PowerPC CPUs. BTW, these days achieving maximum memory copy speeds often seems to require using multiple cores. Hans
|
|
|
|
|
|
Re: x5000 benchmarks / speed up
|
|
Home away from home
|
@geennaam
For 64-bit CPUs such as the P50x0, you should use dcbzl. Dcbz may (or may not) zero only half a cache line so that it's behaviour is consistent with older PowerPC CPUs. This forces it to fetch the remaining 32 bytes which isn't what you want.
The dcba instruction may also be very slow, just like with the G5. It's an illegal instruction on the G5, and is emulated by doing nothing (but with the overhead of an illegal instruction trap).
Hans
P.S., You can query the cache line size via the exec.library'S GetCPUInfo() function (GCIT_CacheLineSize).
|
|
|
|
|
|
Re: RadeonHD V.5 driver
|
|
Home away from home
|
@joerg Quote: Maybe instead of disabling the caches completely using write-through instead of copy-back mode for the caches could help? Unfortunately, no. Hans
|
|
|
|
|
|
Re: My AmigaOne X5000 twins - I need some help and advice.
|
|
Home away from home
|
@daveyw
Yes, work on multi-core support has been going on for some time.
Hans
|
|
|
|
|
|
Re: RadeonHD V.5 driver
|
|
Home away from home
|
@PixelHi Quote: Is there any hope to fix issues with v. 5 Radeon HD and 3d functionality on Sam460 with r7 240/7750? Or I need to do something to make it work? The fixes I mentioned days ago should make it all work. Hans
|
|
|
|
|
|
Re: RadeonHD V.5 driver
|
|
Home away from home
|
@joerg Quote: Are you using the exec functions, or dcbf/dcbi and msync+isync manually? I'm using the IExec->Cache*() and IExec->*DMA() functions. It's also possible that the PCIe controller may have a cache that goes stale. PCIe appears to have some form of snooping capability (there's a "no-snoop" configuration bit). This reminds me a bit of a problem I had with putting the command buffers in VRAM. There was a chance that the data wouldn't arrive in VRAM in time before the GPU started reading it. AMD's engineers said that was why they don't put the command buffers in VRAM; there's no mechanism to delay the GPU read until the data is in. I managed to get it working by waiting for the GPU to be idle before committing the next buffer. Hans
|
|
|
|
|
|
Re: RadeonHD V.5 driver
|
|
Home away from home
|
@Spectre660 Quote: Depending on which GPU series, that may be due to lack of endinness conversion. IIRC, the SI series is the last one where the command processor can be programmed to handle big-endian. AMD had already started removing bi-endianness at that stage, and some things already needed to be manually byte-swapped. @geennaaam Quote: As long as the driver flushes the cache after a cpu write to a DMA buffer and invalidates the cache before reading from a DMA buffer. On a cache coherent system like the X5000, you don't have to worry about this. The bussnooping mechanism makes sure that caches are up to date. That's the correct procedure. Amiga computers only recently started getting cache coherency. I don't understand why manual cache flushing isn't working for GART. I flush/invalidate the cache everywhere where I think it's necessary followed by a sync instruction. Yet, it'll still locking up. The sync instruction should wait until the flush/invalidate is done. Maybe there are other problems (e.g., a cache in the PCIe controller). Or maybe I'm doing something incorrectly in the driver. Hans
|
|
|
|
|
|
Re: RadeonHD V.5 driver
|
|
Home away from home
|
@Hypex Quote: That makes me wonder if Linux cannot use HW acceleration on the Sam graphic drivers? The A1/XE had the same limitation so Linux was slower to use. I actually did enable it to test and it ran well and was fluent on screen. Unfortunately it only lasted a few moments until a system freeze. Said to be related to ring buffer and issues with DMA engine I also recall. The ring buffer is likely the first place where you'd hit problems with lack of cache coherency. However, if you're using an SI card or newer, then the problem could also be that their drivers can't handle big-endian. IIRC, ACube did have a Linux driver that worked with GART enabled. I don't know for which cards, or how it worked. I can think of one way to get GART working, and that's to mark all memory used for GART as non-cacheable (or disable the data cache entirely). The L2 cache might need to be disabled too. Needless to say, doing so would come with a serious performance penalty. Hans
|
|
|
|
|
|
Re: RadeonHD V.5 driver
|
|
Home away from home
|
@PixelHi Quote: Ok. So, I disabled Compositing and now system will boot, however when I'm trying to turn on Compositing computer with freeze ðŸ˜.
EDIT: I disabled Synchronization with vertical refresh. NOW IT WORKS!
And there is power management and my R7 240 is passively cooled NICE.
EDIT: Not so nice. Candi doesn't work (freeze) and CroMagRally the same, freeze. This is with the Radeon R7 240? If so, there's a fix coming. I still have a bit of work to do before the beta testers can do their final testing. Hans
|
|
|
|
|
|
Re: RadeonHD V.5 driver
|
|
Home away from home
|
@joerg Quote: Using an endian-swapping version of GCC might help, like the one which was used for building native x86/x64 Amithlon software. Only if all software is compiled the same way. Otherwise the drivers would still have to endian-convert all data coming from (or going to) apps and the rest of the system. @PixelHi Quote:
Is lack GART support for Sam460 (whatever that is) limitation of Sam460 or its just not easy to implement for it comparing x1000/5000?
In other words will it ever work for Sam460 for RadeonHD/RX?
It's a Sam460 limitation. The Sam460 doesn't have cache coherency. I tried doing manual cache flushing everywhere where it's needed, but couldn't get it working. It would always lock up. It's unlikely that we'll get it working. EDIT: That said, it may still be possible to get a performance boost. We've hit some kind of performance wall, even with GART support. When we finally figure out what's going on, there's a chance we'll get a boost even without GART. Hans
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TuneNet forum
Unsatisfactory Software forum
