Would you support a new Unified Opensource RTG standart?

[wawrzon]

since we have several ongoing projects involved with 68k gfx solutuions, i would just mention wazp3d by alain, warp3d voodoo/mediator hw optimization-fix by matthey, sdl by bernd r, graphics.library with planned gfx support by cosmos, not to mention some approach on aros that might come handy like gallium 3d by deadwood (am i right)... i think it is nothing wrong to call together an initiative to unify the graphic standard as open source.

whoever will pick up this subject - for what i see from last year experience - there will not be many people to attend. there will be an one leading dev. no questions asked. but there is a spirit of cooperative support already. the only chance is to improve something. if it goes  broken we will just have to stick to what we already have anyway. so : no risk, only gain possible.

i vote : yes-!

[wawrzon]

the developers need to support the new standard by programming it, on the other hand it will make their life easier in turn. they will be able stick to program for cgx or p96 whatever they like and know best, and it will still work under the new standartd till it wipes out the others anyway. isnt it a gain?

[wawrzon]

Whether users will really support it depends entirely on how well the result is, and how easy it is to test it without screwing up existing p96/cgx installations.

i could dedicate a few different setups for this sole task (but not the main machine of course)

what concerns this new graphics.library
on a1k and eab ratte warns that cosmos is circumnavigating jumptables to gain speed:

Zitat:
Zitat von Cosmos  
- Four 'jsr -$1B0(a6)' replaced by faster 'bsr.w R_LockLayerRom' (Cosmos)
- Four 'jsr -$1B6(a6)' replaced by faster 'bsr.w R_UnLockLayerRom' (Cosmos)
- Fourteen 'jsr -$2F4(a6)' replaced by faster 'bsr.w R_GetDisplayInfoData' (Cosmos)
- One 'jsr -$2E8(a6)' replaced by faster 'bsr.w R_AddDisplayInfoData' (Cosmos)
- Four 'jsr -$2EE(a6)' replaced by faster 'bsr.w R_SetDisplayInfoData' (Cosmos)
- Three 'jsr -$2DC(a6)' replaced by faster 'bsr.w R_NextDisplayInfo' (Cosmos)
- Ten 'jsr -$84(a6)' replaced by faster 'addq.b #1,$127(a6)' (Cosmos)
 

[wawrzon]

@kthunder: ok, and where is the place to gather and discuss such an idea if not on a forum? maybe it will get nowhere, but why do you get upset just when people discuss it?

[wawrzon]

@kthunder:so people who just want to brainstorm about if some idea is worth considering at all and what the way to take shall hide from you in the corner? concurrent projects have to be started by single visionary programmers. no right to coorinate effort is granted? its redicolous. there is a lot going on without that you probably are aware of anyway.

@gulliver: yeah, the title reads a little misleading, maybe you could adjust that.

[wawrzon]

once again, i think this thread is for what i see just to discuss if such a thing was needed at all. there are individual projects in this direction. however i think anything this scale isnt realistic to achieve all alone.

as for me even i actually cannot program im contributing in a way im able to a few projects, i dont need to justify myself though.

@gulliver: maybe just replace "will" by "would" otherwise it suggests something is already in the works.

[wawrzon]

perhaps the existing ahi drivers just work perfectly, dont recall who actually wrote the pci ones, but all in all i think soundcards are not that a problem atm and if they were a driver could be written.

but what concerns other things like rtg and especially warp3d there is an unnecessary amount of work people (i mean actually matthey) are forcred to invest in fixing it after disassembling. while if it was open maybe amiga might have working, as much as possible up to date, 3d accel solution and not a pile of rubbish what it is atm.

[wawrzon]

@golem: once again, what ahi drivers you immediately require that are missing? i think the ahi job has been done quite decently, what isnt true for rtg anymore. there is a lot of things that might be improved or fixed if the standards were open source. i dont say they would be fixed but they might. such an example is inexistant support for w3d on mediator radeon that pretty much rules this card out against voodoo, which drivers still have to be fixed. the best supported to date are i think b- and c- visions. how many years ago the drivers were written exactly. i dont recall.

and i think we seriously have to stop thinking of amiga software on profit basis. it is a hobby, so it is either open source or nothing. the consumer base is too small to generate income. not so hardware wise since it cant be done in the kitchen. i dont know exactly if this is sad , but it is the truth.

[wawrzon]

@bloodline: ok, ill notify him of the thread.;P
but he will not do the job.

who would probably be the right person is alain, but his projects, wazp and mesa, are keeping him busy enough already. i also have had a talk on subject like that with both already some time ago, and they regarded i too big a task to handle. (i believe i was thinking of w3d driver for radeons)

[wawrzon]

but gallium is not a replacement for an rtg system? i expect perhaps it could be used to replace or improve warp3d but not the rtg itself. besides from what i remember gallium doesnt support r200 only >r300 so radeon9xxx series is out of the question and that are exactly the pci graphic cards is that have decent driver support on all amiga(oid) brands. i recall there were lately some 5 v tolerant radeon pci cards. perhaps effort should concentrate on writing openpci driver for such a card to get gallium based mesa or warp3d based support later. although im not sure if this isnt pile of bs what i write.

[wawrzon]

Which existing graphics cards for the Amiga have chipsets that support the VESA standards (and which version thereof)?

obviously at least those pci:
voodoo3 - vesa 2/3 (would impy also voodoo 4/5)
radeon9xxx

http://www.geos-infobase.de/HWARE03.HTM#

@bernd: ok, then i misunderstood something about gallium, it then does rely only on a (gallium) hardware driver. in this case i suppose 2d graphics could be wrapped to be implemented by 3d means as you suggest.. maybe not all that heavy.

[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?

[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.

[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-

[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?