Would you support a new Unified Opensource RTG standart?

[wawrzon]

@karlos:
but if we are going for vesa pci cards anyway, do we really need one already supported by amigaos drivers if gallium interfaces directly to the hw via vesa if i understood you right?

edit: would amithlon vesa2 drivers be of any help? i dont know how it is done on amithlon, nor on linux for that matter, does the kernel contains them or what?

[Karlos]

@karlos:
but if we are going for vesa pci cards anyway, do we really need one already supported by amigaos drivers if gallium interfaces directly to the hw via vesa if i understood you right?

I was just asking, not steering. I just was thinking about where I'd begin if I had to start out from scratch. VESA has been around a long time and I suspect even the older cards (read Cirrus Logic based) may support it.

[arnljot]

VESA Modes is something in the VESA Bios extention I think (VBE), so I think it's mostly on PCI, PCI-e and AGP cards. Amiga native cards can support VESA modes, but doesn't have a VBE to query for them (API).

--

A little dig around shows driver code for the following in x.org

GLINT (Permedia2 driver, + others). Such as in the CyberVisionPPC
http://ftp.x.org/pub/individual/driver/xf86-video-glint-1.2.4.tar.gz

Cirrus (Cirrus Logic GD5446). Such as the PicassoIV
http://ftp.x.org/pub/individual/driver/xf86-video-cirrus-1.3.2.tar.gz

cl64xx is a driver for Cirrus Logic GD5426 and GD5428. Such as the PicassoII and II+
I haven't found it's sources

s3virge is the linux driver for the S3 Virge chip. Such as the CyberVision64/3d
http://ftp.x.org/pub/individual/driver/xf86-video-s3virge-1.10.4.tar.gz

The s3virge driver should also work with the S3 86C764 Trio64 which is in the CyberVision64 card.

And the RetinaZ3 is supported under m68k linux (chipset NCR 77C32BLT) so code should exist somewhere for that too.

Amiga cards are identified by autoconfig id's, pci cards with vendor id's.

Seems like it should be possible to make a driver structure where the driver lists which autoconfigs ids it supports and which vendor id's it supports.

[wawrzon]

yeah, but since i guess karlos asks about vesa support because of gallium relays on it, these cards are out of question because they lack 3d support. if the new gfx system i to be 3d based (on gallium) that is. might be good solution for classics at least with their slow bus.

[arnljot]

Here is the databook on the CL-GD5446 which is in the PicassoIV.

It even has programming examples:
http://www.tjd.phlegethon.org/gd5446trm.pdf.gz

[Ratte]

talking about a dead horse

7 pages about: galium, cgfx5, p96, aros, vesa ...
but not a single posting from a well known coder saying .. it could be (easily) done

.. a dead horse

[arnljot]

yeah, but since i guess karlos asks about vesa support because of gallium relays on it, these cards are out of question because they lack 3d support. if the new gfx system i to be 3d based (on gallium) that is. might be good solution for classics at least with their slow bus.

I don't think it's a good solution for classic systems, as I think most users would like to retain support for PicassoIV, II, II+, Retinas and other non 3d graphic cards.

[arnljot]

talking about a dead horse

7 pages about: galium, cgfx5, p96, aros, vesa ...
but not a single posting from a well known coder saying .. it could be (easily) done

.. a dead horse

Piru and others have said it'll be a lot of work. I think we all understand that. The point of the discussion is, what should it be like. And do we want it?

[woof]

I agree with Bernd " gallium is a 3D driver with most parts similar to warp3d , some parts are upper level (use more recents cards so accept more parameters) some part
are more low-level and works very close to the gpu so allowing to do 2D opérations on surfaces/textures looking much to cleararray/writepixelarray
so making a wrapper p96->gallium is certainly possible
badly gallium exists only for more recent cards
so it is not a solution for older cards.....

Alain Thellier - Wazp3D author

[SamuraiCrow]

How does AROS and RTG relate?
Enquiring minds want to now.

CyberGraphics.library under AROS is supposed to be somewhat if not fully compatible with GyberGraphX3.  If it is already set to support Gallium drivers for modern hardware then I'm all for it.  Gallium looks like a plausible solution.

If we need backward compatibility in hardware, FPGA-based solutions will make the grade whether we're talking about Natami or some future solution based on MiniMig's cores.  In order to make drivers for them, we won't be able to depend on the MorphOS team or OS 4 team to backport their APIs to OS 3.x or AROS.  We need something new.

As a developer, I support the open-source solution so if one developer gets fed up with it someone else can take over without having to beg, borrow or steal the other person's code.  That's what open-source is all about whether we're talking about the AROS Public License or LGPL.

I voted YES!

[wawrzon]

talking about a dead horse

7 pages about: galium, cgfx5, p96, aros, vesa ...
but not a single posting from a well known coder saying .. it could be (easily) done

.. a dead horse

it is just discussing the outline, where also contributing users might have something to say. but then your opinion is more than welcome. so you do not deem it realistic-

[unusedunused]

badly gallium exists only for more recent cards
so it is not a solution for older cards.....

Alain Thellier - Wazp3D author

I think it take so long that the Radeon drivers > 9200 for OS4/MOS  need so long time or other drivers(for mac) need so long times because its closed source.so they cant just copy and paste a driver and it must develop from 0 and the Users of course must pay this additional effort.

but as can see there are drivers for Linux here, so i dont see a big problem wy a copy and paste not work.

also for 68k there are good low level debuggers here(winuae debugger, hrtmon), so a function during interrupt or layerlock can single step and look how it work.

I think a 2d GFX driver source have always this functions as can see on the P96 driver API

open a display with a resolution and depth and return a bitmap address
close the display
alloc mem on gfx card
freemem on gfx card
set a Hardware pointer image on GFX Card
move the Hardware cursor
blit a rectangle
rectfill a rectangle.

Thats the most important things that need on hardware for 2D.

But because i miss lots of programs and features on all AOS, i better add this to 68k AOS, because its the easiest way to get features because of the good debuggers here that help to find every Problem, i dont have the time and fun to spend on low Level stuff.because with a new display driver i cant use more programs.
 
but i think a opensource Driver API is a big step to make driver that exist on Linux easy working on 68k too, so change a old Linux driver that it can work in Gallium is maybe not the biggest work, but there need somebody who want do that.

[wawrzon]

@bernd: you dont want to debug hardware drivers under uae i suppose?

so what do you propose, i dont get it besides that you like 68k, to port linux drivers over?
to establish vesa as standard on amiga to prepare it to accomodate gallium? im losing the grip on that. can someone outline an overall concept?

[unusedunused]

>to establish vesa as standard on amiga to prepare it to accomodate gallium? im losing the >grip on that. can someone outline an overall concept?

Vesa is only a function set to open/close  a screen on a specific resolution.I guess to use it you need a X86 CPU.
but to give usefull speed you need a bitblit command for the GFX Card, that can copy blocks on the GFX Card fast and also a rectfill command.

maybe to make live easy in a driver you can open the display in Vesa and then use the function from Linux that do blitblit and rectfill.

so this avoid handling with hardware registers to open screen

But i dont know if when a screen is open in Vesa mode the GFX Card work in linear mode and not work in 64 kb mode andif VESA work on non X86 CPU

when work in 64 k mode all is slow.

[unusedunused]

>A little dig around shows driver code for the following in x.org

If you want search, you need look for drivers for Big Endian Systems.maybe PPC or so.
i look on a link and it include X86 files.

[arnljot]

>A little dig around shows driver code for the following in x.org

If you want search, you need look for drivers for Big Endian Systems.maybe PPC or so.
i look on a link and it include X86 files.

The GD5446 code(PicassoIV) seems like it will compile for ppc linux too. Look in the configure file.

xfree86 (xf86 or x86) is the name of the system regardless of cpu platform.