On Tue, 2007-10-30 at 02:33 +, Jose Rodriguez wrote:
>
> I´m not sure what do you mean by "ddx" [...]
The X driver. For 3D, usually only the Mesa driver is relevant.
> I installed the xserver-xorg-video-ati-dbg and libc6-dbg packages [...]
You need to install libgl1-mesa-dri-dbg or build
--- Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Arg, eventually I'll send this mail correctly (last one was rejected
> since my @intel.com address isn't a subscriber).
>
> How does this one look?
Well, it compiles and doesn't crash... ;-)
Cheers,
Chris
__
On Mon, 29 Oct 2007 22:50:06 +0100
Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> Jose Rodriguez wrote:
> > Hi
> >
> > I can't run Gtkradiant
> > (http://www.qeradiant.com/cgi-bin/trac.cgi) with the radeon
> > driver and the following hardware/software:
> >
> > 01:00.0 VGA compatible controller
Hi,
So currently the TTM interface allows the user specify a cacheable
allocation, and on Intel hardware this gets conflated with using the intel
snooped memory type in the GART. This is bad as the intel snooped memory
type comes with its own set of special rules and sucks for lots of things.
http://bugs.freedesktop.org/show_bug.cgi?id=12877
--- Comment #7 from [EMAIL PROTECTED] 2007-10-29 17:35 PST ---
(In reply to comment #6)
> And no, switching to a console and back doesn't reset the problem. I actually
> need to restart X to do that.
Hmm, to clarify: restarting X does
http://bugs.freedesktop.org/show_bug.cgi?id=12877
--- Comment #6 from [EMAIL PROTECTED] 2007-10-29 16:53 PST ---
It is not a new issue; I first noticed it a while ago, but it has been getting
steadily worse recently.
And no, switching to a console and back doesn't reset the problem.
http://bugs.freedesktop.org/show_bug.cgi?id=12877
--- Comment #5 from [EMAIL PROTECTED] 2007-10-29 16:20 PST ---
(In reply to comment #4)
> I was wondering - could this bug be the result of heap corruption within Mesa
> that slowly kills the X server?
since dri clients have their own
http://bugs.freedesktop.org/show_bug.cgi?id=12877
--- Comment #4 from [EMAIL PROTECTED] 2007-10-29 16:02 PST ---
I was wondering - could this bug be the result of heap corruption within Mesa
that slowly kills the X server?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs
Arg, eventually I'll send this mail correctly (last one was rejected
since my @intel.com address isn't a subscriber).
How does this one look?
Thanks,
Jesse
On Monday, October 29, 2007 2:17 pm Chris Rankin wrote:
> Hi,
>
> A NULL pointer is killing OpenGL for my Radeon 9200; here's a quick
> fix
Jose Rodriguez wrote:
> Hi
>
> I can't run Gtkradiant
> (http://www.qeradiant.com/cgi-bin/trac.cgi) with the radeon
> driver and the following hardware/software:
>
> 01:00.0 VGA compatible controller: ATI Technologies Inc RV350
> [Mobility Radeon 9600 M10]
>
> Libraries and driver from Debian te
On Monday, October 29, 2007 12:52 pm Dave Airlie wrote:
> > In this case, we're performing basically a
> > dma_sync*(...DMA_TO_DEVICE) right? Can we be sure that a single
> > flush is sufficient? Is there any window between when we flush and
> > when we start accessing memory with the device that
On Monday, October 29, 2007 1:12 pm Keith Packard wrote:
> On Mon, 2007-10-29 at 12:47 -0700, Jesse Barnes wrote:
> > In this case, we're performing basically a
> > dma_sync*(...DMA_TO_DEVICE) right?
>
> But this is just for the GPU; every other DMA device in the system is
> cache-coherent.
Right.
On Mon, 2007-10-29 at 12:47 -0700, Jesse Barnes wrote:
> In this case, we're performing basically a dma_sync*(...DMA_TO_DEVICE)
> right?
But this is just for the GPU; every other DMA device in the system is
cache-coherent.
> Can we be sure that a single flush is sufficient? Is there any
>
Hi
I can't run Gtkradiant
(http://www.qeradiant.com/cgi-bin/trac.cgi) with the radeon
driver and the following hardware/software:
01:00.0 VGA compatible controller: ATI Technologies Inc RV350
[Mobility Radeon 9600 M10]
Libraries and driver from Debian testing (6.6.193-3 driver's
version)
Librari
>
> In this case, we're performing basically a dma_sync*(...DMA_TO_DEVICE)
> right? Can we be sure that a single flush is sufficient? Is there any
> window between when we flush and when we start accessing memory with
> the device that we could get into more caching trouble?
Not that I can
On Monday, October 29, 2007 1:15 am Dave Airlie wrote:
> Hi,
>
> We've uncovered a need when using the new memory manager to flush the
> chipset global write buffers on certain intel chipset due to a lack
> of coherency..
>
> The attached patches add a new AGP interface for this purpose and
> impl
On 10/29/07, Michel Dänzer <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-10-26 at 10:59 -0700, Jesse Barnes wrote:
> >
> > diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
> > index 707e398..25eaccc 100644
> > --- a/src/glx/x11/glxcmds.c
> > +++ b/src/glx/x11/glxcmds.c
> > @@ -2919,8 +2928,
Sorry about that, a piece of code snuck into that commit that shouldn't
have. Fixed in 6342e0507be177be309774aff0c31746beab73f6.
Jesse
On Monday, October 29, 2007 1:49 am Wu, Nian wrote:
> Hi, Jesse,
>
> When compiled drm module against kernel 2.6.21, it complaint that :
>
> WARNING: "__you_can
On Mon, 2007-10-29 at 08:15 +, Dave Airlie wrote:
> The attached patches add a new AGP interface for this purpose and
> implements this in the Intel AGP driver. This stuff is based of some
> guesswork in the 915 case from comments in the documentation :).
The relevant register lives in de
On Fri, 2007-10-26 at 10:59 -0700, Jesse Barnes wrote:
>
> diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
> index 707e398..25eaccc 100644
> --- a/src/glx/x11/glxcmds.c
> +++ b/src/glx/x11/glxcmds.c
> @@ -2919,8 +2928,10 @@ int __glXGetInternalVersion(void)
> *any DRI
Hi, Jesse,
When compiled drm module against kernel 2.6.21, it complaint that :
WARNING: "__you_cannot_kmalloc_that_much"
[/GFX/build/component/Drm/drm/linux-core/i915.ko] undefined!
And when started up XOrg, it reported below error and DRI was disabled:
FATAL: Error inserting i915
(/lib/module
Hi,
We've uncovered a need when using the new memory manager to flush the
chipset global write buffers on certain intel chipset due to a lack of
coherency..
The attached patches add a new AGP interface for this purpose and
implements this in the Intel AGP driver. This stuff is based of some
22 matches
Mail list logo
