Introduction

I've had hit or miss luck with igp's with this driver so far. Some work better than others.

For the moment I am trying to port DRM, to get 3d acceleration to work...

Must get 3d acceleration to work to get 2d acceleration to work with r600-evergreen card. You output 2d with 3d...

They have removed the 2d acceleration from r600 evergreen and beyond cards.

For the moment there only software rendering for r600 r700 card, some of the 2d functions does not work properly either.

Only implemented 2d acceleration for r5xx card, nearly the same functions as older card and has not tested it so good. There was some problem switching resolution with my Ati Radeon x1300 card.

But if you look on my Amiga 500 x86 project I am using the driver with my Ati Radeon x1300.

References

What I understand as a "driver" in your terms is something that sits on top of this module and allows interactions with only a single output?

A driver is a driver. It's a software module (like current nvidia.hidd, radeon.hidd, etc.). They almost will not change. They are HIDD classes, and will stay so. There's also an instance of the driver, an object of driver class. These things will really control different displays. So, if you for example have one ATI video card with two displays and one NVidia card with one more display, you'll have two drivers and three instances. Right now we always have only one instance of only one driver.

So an instance of the driver will represent a controllable output. I have another question then: how will the client (graphics.library?) create such instances. via OOP_NewObject as usual.

Currently creating an instance of the driver via OOP_NewObject is easy because you should only do it once and when created you know you control the correct output. With the new approach, create an instance of the driver will return an object that controls an output - but how will a client know which output it is? Also how will a client know how many outputs there can be - or put it differently how will the client know how to create driver objects for all outputs? (unless I'm mistake, the only thing a client can use at this stage is OOP_NewObject call)

This model doesn't make much sense to me. An instance of a "driver" should represent a single display adaptor, and expose separate objects to represent the ldp's - IMHO

Different outputs (or different cards - this doesn't matter) are different OOP objects. Each driver object (instance) is registered in the display mode DB with AddDisplayDriverA(). These drivers are assigned different display mode IDs:

0x0010xxyy - First display 0x0011xxyy - Second display 0x0012xxyy - Third display

etc.

xxyy is driver-dependent part of the ID, it encodes sync and pixelformat indexes, the same as before. Why starting at 0x0010 ? Because Amiga(tm) chipset uses fixed definitions that occupy range from 0x0000xxyy to 0x000Axxyy. And i decided to leave 0x000B - 0x000F as reserved, just in case. Anyway i believe a maximum of 65519 displays in the system are enough. :)

Every display driver already provides names for its display modes. Just the driver will have to pass different names for the user ("Radeon analog", "Radeon DVI", "Radeon N2 analog", "Radeon N2 DVI", etc.).

Also how will a client know how many outputs there can be - or put it differently how will the client know how to create driver objects for all outputs? (unless I'm mistake, the only thing a client can use at this stage is OOP_NewObject call)

The client won't do OOP_NewObject() call. The driver module will have a startup code that does it. The new model is very close to what is done at the moment. Only one thing is different:

Current model: When OOP_NewObject() is performed, a first capable PCI device is found and an object is created for it.

New model: a driver startup code enumerates all PCI devices and calls OOP_NewObject() for each of them. It uses private attributes to pass device base address etc. The driver classes even do not have to have public names. Yes, the driver does not have to be a library. It can be a plain executable laying in DEVS:Monitors, as on other systems. This way it can be launched at any time, and its display modes will be instantly added to the system.

See arch/all-mingw32/hidd/wingdi/startup.c as an example. Currently it creates only one object, in future it can be modified to create several objects for simulating several displays (there'll be a separate host window per display). Such approach even allows to use old drivers until they are rewritten. A very small loader program is needed for them. By this time i'm going to move on with the conversion, create DEVS:Monitors, and write such a loader.

There'll be no LoadMonDrvs in Startup-sequence. IMHO a better place for loading display drivers is dosboot resident, in inithidds.c

Next step, port most of the code of drm/radeon/ so I can compile it with the radeon-driver. http://www.kernel.org/ /drivers/gpu/drm/radeon/ /drivers/gpu/drm/

Now trying to set-up the GART table to get the ringbuffer working. The function r600_do_init_cp(... in file “r600_cp.c”. /drivers/gpu/drm/radeon/r600_cp.c

The codes in workbench/hidd/hidd.nouveau contain BOTH nouveau and generic drm code. You should be able to reuse a large portion of generic stuff in radeon driver. As for GART, what I basically need to do it provide to the driver memory allocated at 4k boundary simulating pages. The nouveau driver already has the necessary code to map this into cards address space. I would assume the same is true for radeon driver.