graphics drivers question, NVIDIA driver progress

@kas1e

amazing progress, welldone.

You are the man! :)

@All
Thanks :) But all based on the reconstructed Derf's boardinfo.h he put online with virtuigpu , and on docs Icomp written, and on Noveaui source code for linux. So that not like i did it all..

Anyway, current state is:

1). Basics works : logo showups (640x480x8 mode), workbench loads up in 1920x1080x32, other modes in all 8/16/32 bits works, all apps can be runs, windowss can be moved, etc.

2). EDID/DCC done too inside of driver, meaning that:
-- if there is no .info file present , it build own NVIDIA: named list of modes, all of the possible ones quered by EDID/DCC/etc.
-- if there are .info present, then this one taken and parsed, so modes/valus/mix-max/etc taken from there.

3). No 2D acceleration at all, no compositing, no screen dragging. gfxbench show awfull results in compare with radeond9250. I mean AWFULL :). But at least basics works.

So next step, is to understand what and how can be accelerated , i.e. hardware sprites, blitter, etc..

@joerg
Quote:

But they surely giving SDK (as well as Icom wrote "how to write gfx driver for p96") in hope driver will be written by 3d party devs ?

Quote:

Nope, not sure, and probably not support, but , there i have issue with understanding:

graphics.library (and p96 in), have now cross-platform EDID/DCC code. Which is used when one set DCCMODE in tooltypes. But then, akward part coming : to support that flag in tooltype, driver should give a EDID callback to _private_ structure on closed boardinfo.h parts.

So they expect that 3d party drivers with just public SDK, can't make driver which will handle DCCMODE, that correct ?

IComp's doc says about how to write driver, and never-ever mention edid/dcc/etc for the driver, which mean, that like you should not implement anything of that sort and graphics.library will deal with. But then what about this DCCMODE tooltype ?

Another thing i do not get: when there is no .info file for monitor, then graphics.library not only simple can fallback to VGA Productivity, etc, but, it also call EDID callback ! (private structure again) ,and, based on this driver's-edid-code, build list of modes, and create list of Board 0: xxxxx modes. And if no working EDID callback happens in case of no .info file, then it fallback to VGA productivity. But again i dind't get. They do not want driver to be able to build modes if there is no .info file present ? I mean that the preffered way of things ?

And in end of all, i didn't get why when i simple have Radeon9250.info , or NVIDIA.info, or whatever, the screen mode prefs anyway show me Board 0: , and not Radeon9250: or NVIDIA: , while i register all fine for sure for NVDIAI (and Radeon9250 writting by some one else having same issue).


So to make it short, from Hyperion's public SDK side it all looks like that "good gfx driver" is the driver which works only with .info files, and when there is none, gives only VGA PRoductivity 640x480x8. And which have no working DCCMODE tooltype (because how you can make it work, if you didn't know specific private offsets for EDID callback).

This might be a bit off-topic, but it could be helpful given the issue I ran into.
For example (and this is the case with all my graphics cards), I run the sm502 driver without the “sys:devs/monitor/sm501” file—in “default” mode.
AOS4 boots correctly in graphical mode.
I add “sys:devs/monitor/sm501” for the card, and in the “.info” file I have it as an executable
AOS4 boots correctly in graphics mode.

I remove the “executable” flag from “sys:devs/monitor/sm501” in the “.info” file
AOS4 starts with errors and 256 colors.

Why is the entire graphics mode startup being blocked by the fact that the executable mode isn’t set in the info file?
After all, this shouldn’t cause any problems. The graphics card should “always” initialize in default mode in such a case. This is just ridiculous

edit: test video - > https://youtu.be/em42m2I7Dmg

@smarkusg

The files in SYS:Devs/Monitors are tiny executables that load the chip/driver it needs, so if you remove the E flag then file is not an executable file, thus givin you such error.

Not sure, but maybe it juts loads a deafult VGA monitor if none found in SYS:Devs/Monitors, or this it show as sm502?

@kas1e
I think you should first finish pegasos2 ROM to the point you can publish sources before going elsewhere and leaving that unfinished.
AmigaOS4 does not have SDK for driver development. In P96 boardinfo.h is in PrivateIncludes and that is not part of AmigaOS4 SDK, only the client part for apps not drivers. The AmigaOS4 version seems to correspond to an older P96 version around 3.0 or before that but you also can't get those P96 CardDevelop.lha versions any more as they only publish the latest one. The extensions at the end of the board info struct are different as you've found.
I tried to help once on the OS4Welt forum but AI told me it knows better so I decided to let it find out alone. This is why I haven't yet published my ati-vga driver and because I don't want people to break it with AI faster than I can finish it. But I'll publish it at one point so you don't have to find it out again. Until then you can work on the pegasos2 and X1000 firmwares that you started. By the way there's also a discussion about that on MorphZone where somebody told he has the sources of both of these firmwares. Somebody could ask why he does not publish them? If he has no copyright to publish it (could be bPlan or AEon holds some copyright of the non-BSD licenced pards) then it does not matter if he does anything to fix it or not as the result could not be published anyway. If these have an open source licence and he just sits on them then it could help to publish these.

@jabirulo
Quote:
I now know why I don't need *.info.
It reads the data from here -> sys:Prefs/Env-Archive/sys/screenmode.prefs

@kas1e
It seems like you still didn't get it: AmigaOS 4.x p96 (driver API and PIP/overlay only) and IComp p96 have nothing in common, except for both being based on https://aminet.net/package/driver/video/Picasso96 (or maybe a newer version).

Quote:IComp: Yes.
Hyperion: No. No public gfx driver SDK available, only OS4 developers with access to the OS4 sources and internal includes can implement gfx drivers.

Quote:Wrong. The AmigaOS 4.x p96 .chip/.card API has EDID/DDC support, IComp's incompatible versions don't.

Quote:The DDCMODE ToolType is an AmigaOS 4.x extension of p96, it's extremely unlikely IComp's p96 has something similar.
In IComp's p96 the "P96Prefs" program has EDID/DDC support, not the .chip/.card drivers, creating screen modes from it (and probably storing them in some ENVARC: file like ancient p96 versions did, not in DEVS:Monitors ToolTypes like on AmigaOS 4.x).