> > Compressed textures also seem to be broken, since they'll raise a FPE:
> > Program received signal SIGFPE, Arithmetic exception.
> > [Switching to Thread -1480239424 (LWP 11180)]
> > 0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48, t=0x9909e80,
> > target=3553, firstLevel=0,
> > lastL
Also removes the (now unnecessary) waitForVideoSync call.
diff --git a/src/display.c b/src/display.c
index 23b0ba1..134f69e 100644
--- a/src/display.c
+++ b/src/display.c
@@ -1608,7 +1608,7 @@ eventLoop (void)
timeDiff = 0;
makeScreenCurrent (s
Fixed it up a bit: we now fall back correctly if pageflipping fails or can't
be done. Also use the new ioctl in the do_pageflip code and check for shadow
framebuffers.
diff --git a/src/i830.h b/src/i830.h
index bfd78dc..607037f 100644
--- a/src/i830.h
+++ b/src/i830.h
@@ -452,6 +452,7 @@ typedef
Support the new protocol requests, and expose the DRI2Drawable to drivers, so
they can poke at it for SwapBuffers requests.
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 4e76c71..892d07f 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -131,10 +131,27 @@ __glXDRIdrawableCopySubBuffer(__GLXdraw
Add a new SwapBuffers request, and an additional driver callback to allow low
level drivers to update their renderbuffers based on the returned results.
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 27cc1be..5a60426 100644
--- a/include/GL/internal/d
Just in case you're not using kernel headers.
diff --git a/shared-core/i915_drm.h b/shared-core/i915_drm.h
index 5456e91..443aa4b 100644
--- a/shared-core/i915_drm.h
+++ b/shared-core/i915_drm.h
@@ -205,6 +205,7 @@ typedef struct drm_i915_sarea {
#define DRM_I915_GEM_GET_TILING0x22
#defi
This adds a new ioctl for queueing a page flip with GEM objects. There's a
completion per private object, that we use at execbuf time to wait for any
pending flips; it's cleared at vblank interrupt time when the flip occurs.
The kernel will figure out the pitch of the new frontbuffer automatically
Again, in the interest of getting a non-broken (i.e. non-tearing) GL stack
w/DRI2 I've been working on making SwapBuffers use page flipping for full
screen clients (like compositing managers). This saves a full screen blit so
should be a little faster than the current code. There's a big downs
http://bugs.freedesktop.org/show_bug.cgi?id=20085
Eric Anholt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
From: Dave Airlie
Date: Thu, 12 Feb 2009 21:26:51 +1000
> On Thu, Feb 12, 2009 at 8:15 PM, David Miller wrote:
> >
> > David, this work is against your drm-next branch.
> >
> > Here are a collection of bug fixes for the Radeon DRM support. Most
> > of them have to do with trying to access kerne
From: Dave Airlie
Date: Thu, 12 Feb 2009 21:23:13 +1000
> are you on a PCI or PCIE card, I've no idea what buses you have on sparc64.
>
> On the PCI cards the GART table will always be in main memory.
> PCIE always in VRAM.
PCI-E
On Fri, 2009-02-13 at 08:26 +1100, Benjamin Herrenschmidt wrote:
> > 1) The kernel radeon framebuffer driver doesn't mess with
> >the framebuffer endianness setting.
> >
> > 2) On >= R300 (which my chip is), Xorg leaves it alone too.
>
> They leave alone the swapper of the engine, not the fb
> 1) The kernel radeon framebuffer driver doesn't mess with
>the framebuffer endianness setting.
>
> 2) On >= R300 (which my chip is), Xorg leaves it alone too.
They leave alone the swapper of the engine, not the fb one
(SURFACE_CNTL) afaik.
I dbl checked the other day and it seems that we
Am Donnerstag 12 Februar 2009 15:10:11 schrieb Roland Scheidegger:
> Compressed textures also seem to be broken, since they'll raise a FPE:
> Program received signal SIGFPE, Arithmetic exception.
> [Switching to Thread -1480239424 (LWP 11180)]
> 0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48,
Avoids leaking fbs and associated buffers on release.
Signed-off-by: Kristian Høgsberg
---
drivers/gpu/drm/drm_crtc.c |3 +--
drivers/gpu/drm/drm_fops.c |3 +++
include/drm/drm_crtc.h |2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c
On Thursday, February 12, 2009 2:11 am Michel Dänzer wrote:
> On Wed, 2009-02-11 at 14:29 -0800, Jesse Barnes wrote:
> > Michel may want to change this a bit (make the check smaller), but I'd
> > still like something like this to go in.
>
> Yeah, as I've explained before, if we're changing this, we
http://bugs.freedesktop.org/show_bug.cgi?id=20085
--- Comment #1 from Jan Krcmar 2009-02-12 09:08:46 PST ---
whoops, i've mixed up the version of GE
right version is google earth 5.0.11337.1968_beta
sorry
fous
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
-
http://bugs.freedesktop.org/show_bug.cgi?id=20085
Summary: i915_program_error: Can't (yet) swizzle TEX
Product: Mesa
Version: 6.5
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: m
On 12.02.2009 15:10, Roland Scheidegger wrote:
> On 12.02.2009 13:48, Roland Scheidegger wrote:
>> On 12.02.2009 06:29, Dave Airlie wrote:
>>> Hi,
>>>
>>> So I have a goal to get a radeon driver that works on a bufmgr and that
>>> then can be used on non-mm/mm, and also where I can make DRI2 and F
Intel's 945G chipset which has GTT and gart, What is the relationship between
them?
They are obscure for me. In my Opinion, The gart is use by AGP to remap gpu's
address to system memory address,
and how is the GTT used?
_
News, e
On 12.02.2009 13:48, Roland Scheidegger wrote:
> On 12.02.2009 06:29, Dave Airlie wrote:
>> Hi,
>>
>> So I have a goal to get a radeon driver that works on a bufmgr and that
>> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
>> work.
>>
>> So with that in mind and not wanti
On 12.02.2009 06:29, Dave Airlie wrote:
> Hi,
>
> So I have a goal to get a radeon driver that works on a bufmgr and that
> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
> work.
>
> So with that in mind and not wanting to write this 3 times, I've done a
> major refacto
On Thu, Feb 12, 2009 at 8:15 PM, David Miller wrote:
>
> David, this work is against your drm-next branch.
>
> Here are a collection of bug fixes for the Radeon DRM support. Most
> of them have to do with trying to access kernel virtual addresses
> using DRM_READ32() and DRM_WRITE32().
>
> With t
On Thu, Feb 12, 2009 at 9:09 PM, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Thu, 12 Feb 2009 21:35:59 +1100
>
>> Oh BTW something else to be careful with, though I suppose it's working
>> some what by accident right now... when the GART is in the frame buffer
>> it gets applied th
http://bugzilla.kernel.org/show_bug.cgi?id=12678
[email protected] changed:
What|Removed |Added
Status|NEW |CLOSED
Resolution|
From: Benjamin Herrenschmidt
Date: Thu, 12 Feb 2009 21:35:59 +1100
> Oh BTW something else to be careful with, though I suppose it's working
> some what by accident right now... when the GART is in the frame buffer
> it gets applied the current fb swapper setting... ouch !
>
> So it might be a g
On Thu, 2009-02-12 at 21:37 +1100, Benjamin Herrenschmidt wrote:
> Similar comment about potential swapper setting when accessing the RPTR
> via the framebuffer. David (Airlied), what's the current status with
> that stuff ? I know you work on cleaning that shit up in kms, right now,
> we'll hit t
On Thu, 2009-02-12 at 02:15 -0800, David Miller wrote:
> The memory behind ring_rptr can either be in ioremapped memory
> or a vmalloc() normal kernel memory buffer.
>
> However, the code unconditionally uses DRM_{READ,WRITE}32() (and thus
> readl() and writel()) to access it.
>
> Basically, if R
On Thu, 2009-02-12 at 02:15 -0800, David Miller wrote:
> The PCI GART table initialization code treats the GART table mapping
> unconditionally as a kernel virtual address.
>
> But it could be in the framebuffer, for example, and thus we're
> dealing with a PCI MEM space ioremap() cookie. Treatin
These are not supposed to be booleans, they are
supposed to be bit masks.
Signed-off-by: David S. Miller
---
drivers/gpu/drm/radeon/radeon_drv.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h
b/drivers/gpu/drm/radeon/radeon_drv.h
The address needs to be a GART relative address, rather than a PCI
DMA address.
Signed-off-by: David S. Miller
---
drivers/gpu/drm/radeon/radeon_cp.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/rad
The memory behind ring_rptr can either be in ioremapped memory
or a vmalloc() normal kernel memory buffer.
However, the code unconditionally uses DRM_{READ,WRITE}32() (and thus
readl() and writel()) to access it.
Basically, if RADEON_IS_AGP then it's ioremap()'d memory else it's
vmalloc'd memory
The buffers mapped by the PCI GART can be written to by the device,
not just read.
For example, this happens via the RB_RPTR writeback on Radeon.
So we can't use PCI_DMA_TODEVICE else we'll get protection faults
on IOMMU platforms.
Signed-off-by: David S. Miller
---
drivers/gpu/drm/ati_pcigar
David, this work is against your drm-next branch.
Here are a collection of bug fixes for the Radeon DRM support. Most
of them have to do with trying to access kernel virtual addresses
using DRM_READ32() and DRM_WRITE32().
With these patches at least the writeback test works on sparc64 and
the C
The PCI GART table initialization code treats the GART table mapping
unconditionally as a kernel virtual address.
But it could be in the framebuffer, for example, and thus we're
dealing with a PCI MEM space ioremap() cookie. Treating that as a
virtual address is illegal and will crash some syste
On Wed, 2009-02-11 at 14:29 -0800, Jesse Barnes wrote:
> Michel may want to change this a bit (make the check smaller), but I'd still
> like something like this to go in.
Yeah, as I've explained before, if we're changing this, we might as well
go all the way and make it match the 3s timeout as cl
On Thu, 2009-02-12 at 05:29 +, Dave Airlie wrote:
>
> So I have a goal to get a radeon driver that works on a bufmgr and that
> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
> work.
>
> So with that in mind and not wanting to write this 3 times, I've done a
> major
37 matches
Mail list logo
