http://bugs.freedesktop.org/show_bug.cgi?id=19496
Matt kewlka...@gmail.com changed:
What|Removed |Added
CC||kewlka...@gmail.com
---
http://bugzilla.kernel.org/show_bug.cgi?id=13180
Petri Kaukasoina kaukasoina907m57...@sci.fi changed:
What|Removed |Added
CC|
http://bugzilla.kernel.org/show_bug.cgi?id=13180
--- Comment #11 from Petri Kaukasoina kaukasoina907m57...@sci.fi 2009-08-31
08:26:16 ---
Created an attachment (id=22921)
-- (http://bugzilla.kernel.org/attachment.cgi?id=22921)
another i915_gem_idle warning
--
Configure bugmail:
Jerome and other Radeon developers.
You're probably aware of this, but I'd thought I'd mention it before the
Radeon user-space interface is set in stone.
There is a slight problem with the radeon bo wait idle ioctl if there
are multiple threads or processes rendering to the same buffer without
Open issues:
- Flickering. But when the frame is not changed, this stabilizes
after a few seconds (at most). This is in a 855GM and a 865G, other
chipset variants are untested.
- Runs in sync with the gpu, i.e. unnecessary waiting. Unfortunately
changes in this area tend to hang the hw, so
Daniel Vetter wrote:
Open issues:
- Flickering. But when the frame is not changed, this stabilizes
after a few seconds (at most). This is in a 855GM and a 865G, other
chipset variants are untested.
- Runs in sync with the gpu, i.e. unnecessary waiting. Unfortunately
changes in this
Hi Thomas,
On Mon, Aug 31, 2009 at 11:34:00AM +0200, Thomas Hellström wrote:
Hi,
Is there any way we can try and put together a generic drm interface for
this instead of an Intel-specific one?
I've tried to make the ioctl somewhat generic. That's the reason for the
generic buffer format flags
Daniel Vetter wrote:
...
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the kernel side is certainly possible, if
someone implements overlay support for another chipset. But I don't really
count on that, because at least radeon has textured
On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote:
2009/8/31 Thomas Hellström tho...@shipmail.org:
Daniel Vetter wrote:
...
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the kernel side is certainly possible, if
2009/8/31 Thomas Hellström tho...@shipmail.org:
Daniel Vetter wrote:
...
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the kernel side is certainly possible, if
someone implements overlay support for another chipset. But I don't really
On Mon, Aug 31, 2009 at 01:57:55PM +0200, Thomas Hellström wrote:
Daniel Vetter wrote:
...
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the kernel side is certainly possible, if
someone implements overlay support for another chipset.
Daniel Vetter wrote:
On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote:
2009/8/31 Thomas Hellström tho...@shipmail.org:
Daniel Vetter wrote:
...
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the kernel
2009/8/31 Thomas Hellström tho...@shipmail.org:
The problem I see with Xv-API-in-kernel is that of the various hw
constrains on the buffer layout. IMHO this has two solutions:
a) complicated to communicate the constrains to userspace. This is either
to generic or not suitable for everything.
On Mon, Aug 31, 2009 at 5:15 AM, Dave Airlieairl...@linux.ie wrote:
KMS support by Dave Airlie airl...@redhat.com.
For Radeon 100- to 500-series, firmware blobs look like:
struct {
__be32 datah;
__be32 datal;
} cp_ucode[256];
For Radeon 600-series, there are two
Thomas,
What you describe sounds reasonable and I'll look into updating the
patch. I'm not too keen on the driver specific flag you suggest,
since it makes it hard to use the ioctl in generic code. Maybe
drivers that can do pageflip from one of several fifos can expose a
driver specific ioctl
On Mon, 2009-08-31 at 10:40 +0200, Thomas Hellström wrote:
Jerome and other Radeon developers.
You're probably aware of this, but I'd thought I'd mention it before the
Radeon user-space interface is set in stone.
There is a slight problem with the radeon bo wait idle ioctl if there
are
Jerome Glisse wrote:
On Mon, 2009-08-31 at 10:40 +0200, Thomas Hellström wrote:
Jerome and other Radeon developers.
You're probably aware of this, but I'd thought I'd mention it before the
Radeon user-space interface is set in stone.
There is a slight problem with the radeon bo wait
Kristian Høgsberg wrote:
Thomas,
What you describe sounds reasonable and I'll look into updating the
patch. I'm not too keen on the driver specific flag you suggest,
since it makes it hard to use the ioctl in generic code. Maybe
drivers that can do pageflip from one of several fifos can
http://bugs.freedesktop.org/show_bug.cgi?id=23585
--- Comment #2 from Alex Deucher ag...@yahoo.com 2009-08-31 16:02:07 PST ---
Weird. I built the tests and the icons render fine on my rs780 (I'll test with
other chips later). Richard did some investigating and found:
The glapi level
In preparation for our Plumbers session on this topic, Kristian, Ian
and myself have had several discussions about how to handle the various
GL swap sync extensions in a DRI2 composited environment.
Today after some discussion I put together this page:
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/drm_crtc_helper.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 205349e..e3d78e6 100644
---
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/drm_crtc_helper.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 205349e..e3d78e6 100644
---
This problem only exists in drm-next, sorry for not spotting this the
first time.
Maarten.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration
This problem only exists in drm-next, sorry for not spotting this the
first time.
Maarten.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration
From: Dave Airlie airl...@redhat.com
This could be used to bypass CS checks.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/reg_srcs/r300 |1 -
drivers/gpu/drm/radeon/reg_srcs/rs600 |1 -
drivers/gpu/drm/radeon/reg_srcs/rv515 |1 -
3 files changed, 0
25 matches
Mail list logo
