Browsing this Thread:
1 Anonymous Users
|
Re: fix up gfx hidd loading
|
||||
|---|---|---|---|---|
|
Home away from home
 
|
Quote:
The video drivers are fairly small. We're not talking the latest ATI Suite here (~60MB) - we're talking maybe a meg or two. Quote: as for the amount of work needed - you should check how much code is involved in the first place, and how much redundancy is in it.. i dont want 1 mamoth 2mb monster gl library "sans all" The redundancy would be in Mesa.library. The HIDDs would only have the HW parts. If the HIDD doesn't have a hw method, Mesa.library falls back to the software version, not the HIDD. Quote: it wouldnt cause any more dependancy problems than upgrading any hidd now would - you think apps need recompiled everytime pci.hidd changes? The changes would be adding to the HIDD, not changing what already exists, so you shouldn't need to recompile the programs using the HIDD. Especially as the changes (if any) would be in Warp3D.library and Mesa.library, not the application. At worst, you download a new Warp3D.library, Mesa.library, and video driver HIDD. Should be less than 5M, and most of that would be MESA.
Posted on: 2005/2/7 8:24
|
|||
|
||||
|
Anonymous
|
Re: fix up gfx hidd loading
|
|||
|---|---|---|---|---|
|
What I am saying Kal is.... My personal experence is that things like this tend to break eaisly.. When that happens..belive me as a user I notice. I really have no care how the Devs go about solving technical issues. Just, please keep in mind...what ever solutions is used...it should be as hard for it to get acitdently broken possiable.... By this, botched upgrades..acidently overwritten files....incompatiable libs...things like this are bound to happen and probably can not be completly ovoided. If no 'fail safe' system can handle things like this, it tends to get bad. When bad things happen, it should be as easy as possiable to set correct again....
Things like ".dll hell" and ".lib hell" should be avoided....... I am sure no Dev in the world want's a user to have to go through those previously mentioned places. But it does happen...and the more graceful a system deals with those issues...the better.... This is where my example got me to post in the first place. The system (which shall remain nameless) was just working fine. Then new major update. Devs decided to change things and sub divided the workload among all the necessary pieces...result...lots more files....end result....many a bad days in support land.....and user land.... If this were an actuall meeting for this discussion...I would be the guy way in the back going "hmmm, what if the user did ???" Solve the issues they best way for Aros... Just remeber there is someone at the other end waiting to see if they can "opps" mess it up on you... |
||||
|
||||
|
Re: fix up gfx hidd loading
|
||||
|---|---|---|---|---|
|
Home away from home
|
As a user what will you care? your app will open using gl.hidd and get whatever acceleration is available..
if your missing something needed youll get prompted just like amigaos aros and all the other flavours currently do.. if your driver overides the shader class and you dont have it - that functionality just isnt available - and/or it can prompt the class isnt there .. should something that only over rides a set of the functionality cause a performance hit on everything else since it will all be in one lst for your "all in one" class? where 3d gfx etc are concerned im not bothered about keeping it simple (we arent talking about user issues here - but design issues that affect driver development and how the system will perform) i want it to work well and fast with whatever it can that will improve performance
Posted on: 2005/2/7 5:14
|
|||
|
||||
|
Re: fix up gfx hidd loading
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
And you would only over ride the classes that you actually accelerate as a driver... or replace them .. the rest fall back to the base software implementation (as it is with gfx.hidd) Quote:
some parts change far less than you think ... so what if upgrading your gl implenetation means adding a new class rather than replacing the whole lot? at last your downloading less for a starter ;) as for the amount of work needed - you should check how much code is involved in the first place, and how much redundancy is in it.. i dont want 1 mamoth 2mb monster gl library "sans all" if i could update the shader support by replacing a shader.hidd that would appeal more to me Quote:
you would still have the same methods over all - just implemeted in a more modular fashion. it wouldnt cause any more dependancy problems than upgrading any hidd now would - you think apps need recompiled everytime pci.hidd changes? if you change a method name sure it would break, just like your monolithic hidd. however i would be able to use the other components of mine for other things (such as the matrix/vector hidd) or even only uses the necessary ones for my "task" ..
Posted on: 2005/2/7 5:09
|
|||
|
||||
|
Anonymous
|
Re: fix up gfx hidd loading
|
|||
|---|---|---|---|---|
|
I may not be the best person to interject something here. That and everyone else might not be interested.
Please KISS, Keep It Simple Stupid.... Please, please, please.... While not directly concering dirvers. I have had to support a system where things were broken down into very small subsets. This made things nice for the devlopers but a complete nightmare for support and even worse for users.. While I know that there is the word "research" in the name of this OS. Please...please keep us poor people out here who someday hope to be able to use Aros in mind... In my opinion, and that is all it is an opinion. The more files it takes to keep one basic thing going, "dispaly" in this case, the more prone to problems in the real world. That does not mean that breaking it down as is being discused is "bad" just remember. Try to make it as hard to compleatly "break" as possiable. Remeber there WILL be an Idiot at the other end of the keyboard.... |
||||
|
||||
|
Re: fix up gfx hidd loading
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
The main gfx hidd would be contolling all the resource access in any case (unless you want global variables), so these separate hidds would just be calling the main hidd. That's acceptable I suppose. New methods in main gfx hidd would be things like video memory management, interrupt and status handling, and command dma. Stuff like that. Then the matrix hidd would use those methods to do the actual matrix operations. It's making things more complicated in one manner. The trade off would be that updates to the matrix hidd would change only the matrix hidd. I still think it's more work than needed, though. I like the idea of one driver. Say we split things up - now we are stuck making sure we have the proper version of hidds for 2D, 3D, T&L, pixel shading, video overlay, etc., etc., etc.... OOPS! You fogot to update nvidiagl.hidd when you updated nvidiatnl.hidd. Now your video doesn't work.  See? I think it's better to keep it all together and just keep adding methods than to split it all up, but I'll go along with the group consensus.
Posted on: 2005/2/7 2:33
|
|||
|
||||
|
Re: fix up gfx hidd loading
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
I would even be in favour of further subdividing the classes if suitable main classes can be suggested... The main point is to make it as componantised as possible with each being its own entity in its own right, useable for other things, and possibly hardware accelerateable
Posted on: 2005/2/7 1:38
|
|||
|
||||
|
Re: fix up gfx hidd loading
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
This is in particular what i dont like the sound of. If it where the only probing option - i would rather manually install my devices. After a clean install something perhaps could do that yes to set up the devices in the system _the first time_ but certainly not ever boot. We use prefs files to store the screenmode etc currently anyhow, so im suggesting when that is read, it should also have the device used , and cause it to be brought up. if it fails fall back to the generally supported one .. if that also fails - we can assume no display hardware and use some dumb virtual device.. Quote:
Quote:
I would prefer a different / seperate class or classes for an opengl implementation. a driver could robably encapsulate the class in the single hidd but i would think it would be better a seperate entity i.e * matrix.hidd - implements matrix operations (used by gl.hidd) * gl.hidd - implements the main gl "implementation" and the software "rasterizer" then you would also have * nvidia.hidd - basic 2d/overlay driver for nvidia cards * nvidiagl.hidd - accelerated resterizer functions and whatever else it can override from gl. there may even be a situation where the matrix.hidd could be accelerated (think systems with dsps etc) so the system could also have that externally accelerated using the matrix base class.
Posted on: 2005/2/7 1:30
|
|||
|
||||
|
Re: fix up gfx hidd loading
|
||||
|---|---|---|---|---|
|
Home away from home
|
If you don't want PCI.HIDD probing, just make a hardware manager library (part of resource.library maybe?) and let it do the probing at bootstrap time. Just make it one of the last resident structures to init. No big deal.
You don't want config files or similar things specifying the hardware. Then you wind up with people specifying non-existent drivers (maybe due to spelling error) or non-working drivers. Drivers should always be handled separately. For example, AHI should only have ONE driver to access sound hardware - that driver would look for the currently selected sound HIDD, and use it. Then you would have a bunch of sound HIDDs for all the different sound hardware supported. All available sound devices would be probed and initialized at boot time, and the user would select one of them in a preference. This makes it easier on everyone, including AHI. This sort of how graphics works right now. The libraries call the graphics HIDD. They don't care which, just whichever gfx hidd is currently active gets used. We just don't probe for the gfx hidd on startup yet - it's specified in the GRUB boot command line args. 3D should be added to the methods for gfx hidds. Then you can have just one Warp3D.library and one Mesa library that uses the gfx hidd (if the methods exist) for hw acceleration, and fall back on software routines when needed (Mesa currently just uses software). We don't need lots of 3D drivers, just two using new methods added to existing gfx hidds.
Posted on: 2005/2/7 1:14
|
|||
|
||||
|
Re: fix up gfx hidd loading
|
||||
|---|---|---|---|---|
|
Home away from home
|
I would also be for re housing the display hidds under DEVS:Display or similar.. (and putting 3d drivers there if we ever get them)
Posted on: 2005/2/6 20:12
|
|||
|
||||
You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.
You cannot use topic type.
You cannot use HTML syntax.
You cannot use signature.
You cannot create PDF files.
You cannot get print page.
