[haiku-development] Re: AGP changes broke NVidia display.
- From: "Euan Kirkhope" <euan.kirkhope@xxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 2 Feb 2008 21:55:21 +0000
On 02/02/2008, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
> Bruno Albuquerque <bga@xxxxxxxxxxxxx> wrote:
> > Axel Dörfler escreveu:
> > > The new AGP bus manager does not support a settings file at all at
> > > this
> > > point; I'm no friend of settings files for kernel drivers if they
> > > aren't strictly necessary (and they usually aren't).
> > Well, the usual solution to settings file is to make the driver aware
> > of
> > all probblems in chipsets and disable features or enable workarounds
> > when needed. As we probably don't have enough hardware to test every
> > possible combination, settings files are a good workaround.
>
> Sure, but only if your aim is to fix all those bugs before deployment :
> -)
> It's always interesting to see how other platforms deal with these
> issues, and what work-arounds they have in their code. Now you can add
> a work-around for your hardware, yay ;-))
> If you know some options are problematic, it's better to only enable it
> on certain (tested) hardware by default. AGP fast writes seem to be
> such a case.
>
> > > But since it does not hang as before, I guess there might have been
> > > a
> > > bug in the old AGP bus manager that caused this hang? Does it
> > > report
> > > AGP 2x or 4x for you now?
> > Correction, now it started to hang (the drawing engine hangs and do
> > not
> > come back anymore). Sometimes it hangs but come bacl after 5 or 6
> > seconds.
> >
> > I tried to figure out if it was using AGP 4X or 2X but funny enough
> > there was no debug output whatsoever from the nvidia driver or
> > agp_gart
> > driver to the syslog. Looking at the code it seems you are matching
> > chipset and graphics card capabilities and, in this case, it would
> > enable AGP 4X (as both report it).
>
> The nvidia driver should have some debug output in it. I might have
> forgotten about it in the AGP driver (update: confirmed, fixed in r).
>
> > I have dma_acc set to false in the nevidia settings file. So I guess
> > it
> > is not enabled. Funny enough, DMA works if AGP is disabled but the
> > graphics operations seem to be slower than using PIO mode.
>
> Strange, it should always be faster than with PIO. But I guess Rudolf
> could tell us more about it.
> Maybe you should always disable DMA for that card in the driver.
> Or is anyone out there who hasn't got any problems with that one?
>
> > > You could try to disable fast-writes and see if that helps. To do
> > > that,
> > > just remove the AGP_FAST_WRITE bit in the set_agp_mode() function
> > > call
> > > in the nVidia driver.
> > I disabled fastwrites on the BIOS and now it seems to work. In fact,
> > even DMA seems to be working. Some interesting stuff:
> >
> > 1 - I tried GLTeapot. It seems it is drawing outside of its window
> > when
> > you move the window around.
>
> That's more or less what happens on other systems, too, at least there
> seem to be some problems left in that code (I only looked shortly at
> that, but I couldn't even find any code that would stop all direct
> windows when moving a window).
>
> > 2 - If DMA acc is enabled, not only it will draw outside its windows
> > as
> > it will also crash GLTeapot somewhere in
> > MesaSoftwareRenderer::SwapBuffers().
>
> That shouldn't really have any impact on that, sounds strange.
>
> > Having this in minda, any ideas? How much of a performance boost is
> > fatswrites?
>
> I have no idea, I just know that the Radeon driver always disables it.
> I guess Rudolf has some numbers somewhere (maybe in his blog or the
> update/read-me files of his nVidia/AGP releases).
> I don't think it'll be a huge problem.
>
> Bye,
> Axel.
>
>
Most older radeon cards have historically disliked fastwrites so it's
normal for fastwrites to be disabled there. Nvidia cards prefer it
enabled however.
Just my 2 cents.
Other related posts:
