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