Re: AGP busmanager: removed blocking options?

Hi Axel,

It's a bit hard to shut that off, since the problems only arise on
_combinations_ of hardware. One might argue if it's the gfx driver or the
busmanager that should turn these features off..

I agree wholeheartedly about (not) having settings files, and that it
should 'just' always work.
In practice however, this cannot be accompliced due to the enourmous
diversity in hardware that exists in this world.

So, my personal take is: have a settings file, but preset fail-safe
defaults so that it indeed always 'just works'.
Having the settings file in place makes it possible to 'finetune' your
system to run at maximum performance which might differ big_time in speed
compared to the failsafe defaults.

Take fastwrites for example: the failsafe I setup was "disable". But, it
could have been "disable if non-nvidia gfx found" or "enable, unless ATI
gart is found".
Unfortunately, I can think of numerous other combinations in theory
possible that (thus) will exist.

(enable, if nvidia gfx, but disable if gart=ATI chipset (if such a thing
exists, but fill in any brand you like).

I'm just talking about the fastwrite options here. Every other aspect in
the AGP specification (remember: AGP is 'just a tweaked/tuned up' PCI
thingy) might be a source for trouble on some hardware.

--

Hmm, another (bad) example of the 'shit' in this world comes to mind :-)
Take the CF cards. These can run in PIO mode and DMA mode. unfortunately
these days there's a problem with PIO mode in these cards, I would think
this has come to be since Microsoft is running them in DMA mode in
practice.
The CF standard also describes PIO mode but since microsoft doesn't use it
anymore, no-one fixes or implements correctly the PIO mode.

So: if you once built a PIO mode interface for these cards, it would have
worked just fine. It would still work fine in the beginning that DMA mode
existed. However, these days you have to search a lot to find a card that
correctly implements PIO mode.
There's no problem in the interface, but still: it doesn't work anymore.

OK, true, this is no problem by itself that justifies having a settings
file in place here, since you can simply use DMA, unless it's not
available and then use PIO. IF you run on DMA capable interface hardware
that is.
If you run on PIO mode hardware you'd need to just block every DMA capable
card from use since it's probably broke for PIO mode.

Ah, a settings file after all? Or just tell everyone to buy new host
hardware? You tell me what's correct. I don't know. (I just hate this
practice).

These are my two cents on the settings file subject. Do with it what you
want (since I understand the downside of these settings files as well :-)


Kind regards,

Rudolf.

(still searching for that nvidia bug BTW)






Op Ma, 26 mei, 2008 11:06 am schreef Axel Dörfler:
> Hi Rudolf,
>
>
> [email protected] wrote:
>
>> Am I correct in assuming that the agp.settings file is nolonger read?
>> Why
>> is that?
>>
>> Personally I must confess I'm a bit dissapointed I have to recompile
>> this manager every time I have to test something with enabling/disabling
>> (troublesome) features.. :-/
>>
>>
>> Don't know if there's another (better) way of having these options
>> back?
>
> It's just that I didn't think it was necessary to have a settings file
> for it. In general, I'm not a friend of settings files for drivers, as I
> think it should always just work for everyone - if someone needs to change
> a setting file to make something work, I would even consider this a bug. It
> might be helpful for you during debugging, of course, but I didn't have
> any problems back then in my limited hardware park :-) I think it's okay
> for testing and figuring out problems some user might run into, but in the
> end, the driver should automatically turn off the troublesome features on
> that hardware by itself.
>
> Bye,
> Axel.
>
>
>
> -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Open-beos-kernel-devel mailing list
> Open-beos-kernel-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/open-beos-kernel-devel
>
>



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/