Re: [Intel-gfx] [PATCH 6/7] KMS: Keep screen pixmap devPrivate.ptr NULL during init and resize
On Fri, 2009-07-10 at 17:25 -0700, Eric Anholt wrote: > This one and #3 seem to be in disagreement. Perhaps some squashing? This one is KMS, where we never need the screen pixmap to hold a pointer. #3 was for UMS, where we do. > Other than that, it looks fine to me. Ok, I'll go ahead and push then. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 6/7] KMS: Keep screen pixmap devPrivate.ptr NULL during init and resize
On Fri, 2009-07-10 at 17:14 -0700, Keith Packard wrote:
> The frame buffer only has a valid address between prepare_access and
> finish_access calls, so remove all other attempts to compute an address from
> the driver.
>
> Signed-off-by: Keith Packard
> ---
> src/drmmode_display.c |3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> index 7cfdc5b..df10fb5 100644
> --- a/src/drmmode_display.c
> +++ b/src/drmmode_display.c
> @@ -1056,12 +1056,9 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width,
> int height)
> goto fail;
>
> i830_set_pixmap_bo(screen->GetScreenPixmap(screen),
> pI830->front_buffer->bo);
> - scrn->fbOffset = pI830->front_buffer->offset;
>
> screen->ModifyPixmapHeader(screen->GetScreenPixmap(screen),
> width, height, -1, -1, pitch * pI830->cpp,
> NULL);
> - xf86DrvMsg(scrn->scrnIndex, X_INFO, "New front buffer at 0x%lx\n",
> -pI830->front_buffer->offset);
>
> for (i = 0; i < xf86_config->num_crtc; i++) {
> xf86CrtcPtr crtc = xf86_config->crtc[i];
This one and #3 seem to be in disagreement. Perhaps some squashing?
Other than that, it looks fine to me.
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 4/6] KMS: Map frame buffer at alloc time when running without UXA
On Fri, 2009-07-10 at 12:35 -0700, Ian Romanick wrote: > > + pointer *data; > > Is 'pointer *' actually what you wanted here? Either 'pointer' or plain > old 'void *' should be fine. heh. yeah, pointer would be correct. Note that the updated patch sequence doesn't use a temporary variable for this. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22625] glDrawBuffer(GL_FRONT) rendering broken in UXA intel i915
http://bugs.freedesktop.org/show_bug.cgi?id=22625 --- Comment #2 from Ian Hutchinson 2009-07-10 17:42:20 PST --- Well, update to xf86-video-intel 2.7.x on its own does not fix it. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/7] Remove NoAccel support
This removes yet another 'debugging' option that hasn't seen real use in a
long time, and wasn't supported under KMS in any case.
Signed-off-by: Keith Packard
---
src/drmmode_display.c | 16 --
src/i830.h| 15 +
src/i830_accel.c | 11 +---
src/i830_dri.c|5 --
src/i830_driver.c | 142 +++-
src/i830_memory.c | 22
src/i830_uxa.c| 27 +++---
7 files changed, 54 insertions(+), 184 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index e9296dc..7cfdc5b 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -329,8 +329,6 @@ drmmode_crtc_shadow_allocate(xf86CrtcPtr crtc, int width,
int height)
return NULL;
}
- drm_intel_gem_bo_map_gtt(drmmode_crtc->rotate_bo);
-
ret = drmModeAddFB(drmmode->fd, width, height, crtc->scrn->depth,
crtc->scrn->bitsPerPixel, rotate_pitch,
drmmode_crtc->rotate_bo->handle,
@@ -341,7 +339,7 @@ drmmode_crtc_shadow_allocate(xf86CrtcPtr crtc, int width,
int height)
return NULL;
}
- return drmmode_crtc->rotate_bo->virtual;
+ return drmmode_crtc->rotate_bo;
}
static PixmapPtr
@@ -353,8 +351,14 @@ drmmode_crtc_shadow_create(xf86CrtcPtr crtc, void *data,
int width, int height)
unsigned long rotate_pitch;
PixmapPtr rotate_pixmap;
- if (!data)
+ if (!data) {
data = drmmode_crtc_shadow_allocate (crtc, width, height);
+ if (!data) {
+ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "Couldn't allocate shadow pixmap for rotated
CRTC\n");
+ return NULL;
+ }
+ }
rotate_pitch =
i830_pad_drawable_width(width, drmmode->cpp) * drmmode->cpp;
@@ -363,11 +367,12 @@ drmmode_crtc_shadow_create(xf86CrtcPtr crtc, void *data,
int width, int height)
pScrn->depth,
pScrn->bitsPerPixel,
rotate_pitch,
- data);
+ NULL);
if (rotate_pixmap == NULL) {
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
"Couldn't allocate shadow pixmap for rotated
CRTC\n");
+ return NULL;
}
if (drmmode_crtc->rotate_bo)
@@ -393,7 +398,6 @@ drmmode_crtc_shadow_destroy(xf86CrtcPtr crtc, PixmapPtr
rotate_pixmap, void *dat
* unbound. */
drmModeRmFB(drmmode->fd, drmmode_crtc->rotate_fb_id);
drmmode_crtc->rotate_fb_id = 0;
- drm_intel_gem_bo_unmap_gtt(drmmode_crtc->rotate_bo);
dri_bo_unreference(drmmode_crtc->rotate_bo);
drmmode_crtc->rotate_bo = NULL;
}
diff --git a/src/i830.h b/src/i830.h
index dc5e0c8..f7ca687 100644
--- a/src/i830.h
+++ b/src/i830.h
@@ -317,12 +317,6 @@ enum backlight_control {
BCM_KERNEL,
};
-typedef enum accel_method {
-ACCEL_UNINIT = 0,
-ACCEL_NONE,
-ACCEL_UXA
-} accel_method_t;
-
enum dri_type {
DRI_DISABLED,
DRI_NONE,
@@ -431,7 +425,6 @@ typedef struct _I830Rec {
Bool fence_used[FENCE_NEW_NR];
- accel_method_t accel;
CloseScreenProcPtr CloseScreen;
void (*batch_flush_notify)(ScrnInfoPtr pScrn);
@@ -827,8 +820,7 @@ i830_wait_ring_idle(ScrnInfoPtr pScrn)
{
I830Ptr pI830 = I830PTR(pScrn);
- if (pI830->accel != ACCEL_NONE)
- I830WaitLpRing(pScrn, pI830->ring.mem->size - 8, 0);
+ I830WaitLpRing(pScrn, pI830->ring.mem->size - 8, 0);
}
static inline int i830_fb_compression_supported(I830Ptr pI830)
@@ -841,10 +833,9 @@ static inline int i830_fb_compression_supported(I830Ptr
pI830)
return FALSE;
if (IS_IGDNG(pI830))
return FALSE;
-/* fbc depends on tiled surface. And we don't support tiled
- * front buffer with unaccelerated.
+/* fbc depends on tiled surface.
*/
-if (!pI830->tiling || (IS_I965G(pI830) && pI830->accel == ACCEL_NONE))
+if (!pI830->tiling)
return FALSE;
/* We have not gotten FBC to work consistently on 965GM. Our best
* working theory right now is that FBC simply isn't reliable on
diff --git a/src/i830_accel.c b/src/i830_accel.c
index b365e3f..96a7bde 100644
--- a/src/i830_accel.c
+++ b/src/i830_accel.c
@@ -136,7 +136,7 @@ I830Sync(ScrnInfoPtr pScrn)
if (I810_DEBUG & (DEBUG_VERBOSE_ACCEL | DEBUG_VERBOSE_SYNC))
ErrorF("I830Sync\n");
- if (pI830->accel == ACCEL_NONE || !pScrn->vtSema || !pI830->batch_bo)
+ if (!pScrn->vtSema || !pI830->batch_bo)
return;
I830EmitFlush(pScrn);
@@ -236,12 +236,5 @@ I830AccelInit(ScreenPtr pScreen)
if (pI830->directRenderingType >= DRI_DRI2)
pI8
[PATCH 2/7] Make xorg.conf DRI option work under KMS. Fix name of I830AccelMethodInit
KMS mode does not call I830AccelMethodInit as that does the user
modesetting initialization (yes, it was misnamed), but that means that the DRI
option
was ignored. Create a new i830_check_dri_option function to do the option
detection, then remove that from I830AccelMethodInit, which is renamed
i830_user_modesetting_init to reflect what it actually does.
Signed-off-by: Keith Packard
---
src/i830_driver.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/i830_driver.c b/src/i830_driver.c
index cc0a1f6..ee39a1b 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -1301,12 +1301,10 @@ I830PreInitCrtcConfig(ScrnInfoPtr pScrn)
xf86CrtcSetSizeRange (pScrn, 320, 200, max_width, max_height);
}
-static Bool
-I830AccelMethodInit(ScrnInfoPtr pScrn)
+static void
+i830_check_dri_option(ScrnInfoPtr pScrn)
{
I830Ptr pI830 = I830PTR(pScrn);
-int i, num_pipe;
-
pI830->directRenderingType = DRI_NONE;
if (!xf86ReturnOptValBool(pI830->Options, OPTION_DRI, TRUE))
pI830->directRenderingType = DRI_DISABLED;
@@ -1316,6 +1314,13 @@ I830AccelMethodInit(ScrnInfoPtr pScrn)
"runs only at depths 16 and 24.\n");
pI830->directRenderingType = DRI_DISABLED;
}
+}
+
+static Bool
+i830_user_modesetting_init(ScrnInfoPtr pScrn)
+{
+I830Ptr pI830 = I830PTR(pScrn);
+int i, num_pipe;
I830MapMMIO(pScrn);
@@ -1442,7 +1447,6 @@ I830DrmModeInit(ScrnInfoPtr pScrn)
return FALSE;
}
-pI830->directRenderingType = DRI_NONE;
pI830->have_gem = TRUE;
i830_init_bufmgr(pScrn);
@@ -1587,6 +1591,8 @@ I830PreInit(ScrnInfoPtr pScrn, int flags)
if (!i830_detect_chipset(pScrn))
return FALSE;
+ i830_check_dri_option(pScrn);
+
if (pI830->use_drm_mode) {
if (!I830DrmModeInit(pScrn))
return FALSE;
@@ -1595,7 +1601,7 @@ I830PreInit(ScrnInfoPtr pScrn, int flags)
xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
"VBIOS initialization failed.\n");
I830PreInitCrtcConfig(pScrn);
- if (!I830AccelMethodInit(pScrn))
+ if (!i830_user_modesetting_init(pScrn))
return FALSE;
}
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 5/7] i830_bind_memory: Under UMS: Bind GEM bos with dri_bo_pin, else through the GART
We only need to get static offsets for objects when not running KMS,
otherwise the kernel will manage those as needed for us.
Binding objects is done in one of two ways. For GEM buffer objects, we use
dri_bo_pin. For GART allocated memory, we bind that to the GART.
---
src/i830_memory.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/src/i830_memory.c b/src/i830_memory.c
index 556b511..f2f3966 100644
--- a/src/i830_memory.c
+++ b/src/i830_memory.c
@@ -199,10 +199,11 @@ i830_bind_memory(ScrnInfoPtr pScrn, i830_memory *mem)
{
I830Ptr pI830 = I830PTR(pScrn);
-if (mem == NULL || mem->bound)
+if (mem == NULL || mem->bound || pI830->use_drm_mode)
return TRUE;
-if (mem->bo != NULL && !pI830->use_drm_mode) {
+if (pI830->have_gem && mem->bo != NULL) {
+
if (dri_bo_pin(mem->bo, mem->alignment) != 0) {
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
"Failed to pin %s: %s\n",
@@ -213,9 +214,7 @@ i830_bind_memory(ScrnInfoPtr pScrn, i830_memory *mem)
mem->bound = TRUE;
mem->offset = mem->bo->offset;
mem->end = mem->offset + mem->size;
-}
-
-if (!mem->bound) {
+} else {
if (!pI830->gtt_acquired)
return TRUE;
@@ -228,8 +227,7 @@ i830_bind_memory(ScrnInfoPtr pScrn, i830_memory *mem)
mem->bound = TRUE;
}
-if (mem->tiling != TILE_NONE && !pI830->use_drm_mode &&
- !pI830->kernel_exec_fencing) {
+if (mem->tiling != TILE_NONE && !pI830->kernel_exec_fencing) {
mem->fence_nr = i830_set_tiling(pScrn, mem->offset, mem->pitch,
mem->allocated_size, mem->tiling);
}
@@ -1114,7 +1112,7 @@ i830_allocate_framebuffer(ScrnInfoPtr pScrn)
return NULL;
}
-if (!pI830->use_drm_mode && pI830->FbBase && front_buffer->bound)
+if (pI830->FbBase && front_buffer->bound)
memset (pI830->FbBase + front_buffer->offset, 0, size);
i830_set_max_gtt_map_size(pScrn);
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 7/7] i830_uxa_prepare_access: Flush and wait for idle for non-bo pixmaps
Without kernel support and explicit knowledge about where in the ring the
last rendering operation for a specific pixmap was, we must synchronize with
any outstanding rendering before accessing a pixmap which does not have a
buffer object.
Signed-off-by: Keith Packard
---
src/i830_uxa.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/i830_uxa.c b/src/i830_uxa.c
index 75142ed..46d9397 100644
--- a/src/i830_uxa.c
+++ b/src/i830_uxa.c
@@ -477,13 +477,12 @@ static Bool
i830_uxa_prepare_access (PixmapPtr pixmap, uxa_access_t access)
{
dri_bo *bo = i830_get_pixmap_bo (pixmap);
+ScrnInfoPtr scrn = xf86Screens[pixmap->drawable.pScreen->myNum];
+
+intel_batch_flush(scrn, FALSE);
if (bo) {
- ScreenPtr screen = pixmap->drawable.pScreen;
- ScrnInfoPtr scrn = xf86Screens[screen->myNum];
I830Ptr i830 = I830PTR(scrn);
-
- intel_batch_flush(scrn, FALSE);
/* No VT sema or GEM? No GTT mapping. */
if (!scrn->vtSema || !i830->have_gem) {
@@ -517,7 +516,9 @@ i830_uxa_prepare_access (PixmapPtr pixmap, uxa_access_t
access)
drm_intel_gem_bo_start_gtt_access(bo, access == UXA_ACCESS_RW);
pixmap->devPrivate.ptr = i830->FbBase + bo->offset;
}
-}
+} else
+ i830_wait_ring_idle(scrn);
+
return TRUE;
}
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 6/7] KMS: Keep screen pixmap devPrivate.ptr NULL during init and resize
The frame buffer only has a valid address between prepare_access and
finish_access calls, so remove all other attempts to compute an address from
the driver.
Signed-off-by: Keith Packard
---
src/drmmode_display.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 7cfdc5b..df10fb5 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1056,12 +1056,9 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width,
int height)
goto fail;
i830_set_pixmap_bo(screen->GetScreenPixmap(screen),
pI830->front_buffer->bo);
- scrn->fbOffset = pI830->front_buffer->offset;
screen->ModifyPixmapHeader(screen->GetScreenPixmap(screen),
width, height, -1, -1, pitch * pI830->cpp,
NULL);
- xf86DrvMsg(scrn->scrnIndex, X_INFO, "New front buffer at 0x%lx\n",
- pI830->front_buffer->offset);
for (i = 0; i < xf86_config->num_crtc; i++) {
xf86CrtcPtr crtc = xf86_config->crtc[i];
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/7] Always set screen pixmap data pointer at init and resize times
For non-DRM environments, the screen pixmap will be GART allocated memory and not a libdrm buffer object and so uxa will only use devPrivate.ptr to find the associated memory. Make sure devPrivate.ptr is set each time the framebuffer is allocated so that uxa will be able to draw to it. Signed-off-by: Keith Packard --- src/i830_driver.c | 15 ++- 1 files changed, 10 insertions(+), 5 deletions(-) diff --git a/src/i830_driver.c b/src/i830_driver.c index ee39a1b..e5e5fd7 100644 --- a/src/i830_driver.c +++ b/src/i830_driver.c @@ -880,7 +880,6 @@ i830_xf86crtc_resize (ScrnInfoPtr scrn, int width, int height) i830_memory *new_front, *old_front; Booltiled; ScreenPtr screen = screenInfo.screens[scrn->scrnIndex]; - pointer data = NULL; scrn->displayWidth = i830_pad_drawable_width(width, i830->cpp); tiled = i830_tiled_width(i830, &scrn->displayWidth, i830->cpp); @@ -900,15 +899,15 @@ i830_xf86crtc_resize (ScrnInfoPtr scrn, int width, int height) i830_set_pixmap_bo(screen->GetScreenPixmap(screen), new_front->bo); scrn->fbOffset = i830->front_buffer->offset; - if (!new_front->bo) - data = i830->FbBase + scrn->fbOffset; + screen->ModifyPixmapHeader(screen->GetScreenPixmap(screen), width, height, -1, -1, scrn->displayWidth * i830->cpp, - data); + i830->FbBase + scrn->fbOffset); + /* ick. xf86EnableDisableFBAccess smashes the screen pixmap devPrivate, * so update the value it uses */ - scrn->pixmapPrivate.ptr = data; + scrn->pixmapPrivate.ptr = i830->FbBase + scrn->fbOffset; xf86DrvMsg(scrn->scrnIndex, X_INFO, "New front buffer at 0x%lx\n", i830->front_buffer->offset); i830_set_new_crtc_bo(scrn); @@ -2719,6 +2718,12 @@ I830ScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv) if (pScrn->virtualX > pScrn->displayWidth) pScrn->displayWidth = pScrn->virtualX; + /* If the front buffer is not a BO, we need to +* set the initial framebuffer pixmap to point at +* it +*/ + pScrn->fbOffset = pI830->front_buffer->offset; + DPRINTF(PFX, "assert( if(!fbScreenInit(pScreen, ...) )\n"); if (!fbScreenInit(pScreen, pI830->FbBase + pScrn->fbOffset, pScrn->virtualX, pScrn->virtualY, -- 1.6.3.3 -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/7] Allocate GTT space for GEM only under UMS
GEM requires GTT space to map objects. Under KMS, the kernel driver has
already provided all available GTT space to GEM, so the X server need not do
anything.
Signed-off-by: Keith Packard
---
src/i830_driver.c |8 +--
src/i830_memory.c | 135 +++-
2 files changed, 72 insertions(+), 71 deletions(-)
diff --git a/src/i830_driver.c b/src/i830_driver.c
index e5e5fd7..fe2565c 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -2674,8 +2674,8 @@ I830ScreenInit(int scrnIndex, ScreenPtr pScreen, int
argc, char **argv)
if (!pI830->use_drm_mode)
I830MapMMIO(pScrn);
- /* Need FB mapped to set up the fake bufmgr if we end up doing that
-* in i830_memory_init() -> i830_allocator_init().
+ /* Need FB mapped to access non-GEM objects like
+* a UMS frame buffer, or the fake bufmgr.
*/
if (!pI830->use_drm_mode) {
if (!I830MapMem(pScrn))
@@ -2701,10 +2701,6 @@ I830ScreenInit(int scrnIndex, ScreenPtr pScreen, int
argc, char **argv)
if (!miSetPixmapDepths())
return FALSE;
- i830_init_bufmgr(pScrn);
-
- pScrn->fbOffset = pI830->front_buffer->offset;
-
if (!pI830->use_drm_mode) {
vgaHWSetMmioFuncs(hwp, pI830->MMIOBase, 0);
vgaHWGetIOBase(hwp);
diff --git a/src/i830_memory.c b/src/i830_memory.c
index 2953f3b..556b511 100644
--- a/src/i830_memory.c
+++ b/src/i830_memory.c
@@ -334,10 +334,8 @@ i830_reset_allocations(ScrnInfoPtr pScrn)
}
/* Free any allocations in buffer objects */
-if (pI830->memory_manager) {
- while (pI830->bo_list != NULL)
- i830_free_memory(pScrn, pI830->bo_list);
-}
+while (pI830->bo_list != NULL)
+i830_free_memory(pScrn, pI830->bo_list);
/* Null out the pointers for all the allocations we just freed. This is
* kind of gross, but at least it's just one place now.
@@ -405,12 +403,14 @@ i830_allocator_init(ScrnInfoPtr pScrn, unsigned long size)
pI830->memory_list = start;
-/* Now that we have our manager set up, initialize the kernel MM if
- * possible, covering almost all of the aperture. We need libdri interface
- * 5.4 or newer so we can rely on the lock being held after DRIScreenInit,
- * rather than after DRIFinishScreenInit.
+/* Now that we have our manager set up, give the kernel a piece of the
+ * aperture for GEM buffer object mapping. This is only needed for UXA
+ * and/or DRI2 when the kernel hasn't already managed this itself under
+ * KMS. We need libdri interface5.4 or newer so we can rely on the lock
+ * being held after DRIScreenInit, rather than after DRIFinishScreenInit.
*/
-if (pI830->directRenderingType == DRI_DRI2) {
+
+if (!pI830->use_drm_mode) {
int mmsize;
/* Take over all of the graphics aperture minus enough to for
@@ -426,53 +426,49 @@ i830_allocator_init(ScrnInfoPtr pScrn, unsigned long size)
}
if (pI830->CursorNeedsPhysical) {
mmsize -= 2 * (ROUND_TO(HWCURSOR_SIZE, GTT_PAGE_SIZE) +
- ROUND_TO(HWCURSOR_SIZE_ARGB, GTT_PAGE_SIZE));
+ ROUND_TO(HWCURSOR_SIZE_ARGB, GTT_PAGE_SIZE));
}
if (pI830->fb_compression)
mmsize -= MB(6) + ROUND_TO_PAGE(FBC_LL_SIZE + FBC_LL_PAD);
+
/* Can't do GEM on stolen memory */
mmsize -= pI830->stolen_size;
/* Create the aperture allocation */
pI830->memory_manager =
- i830_allocate_aperture(pScrn, "DRI memory manager",
- mmsize, 0, GTT_PAGE_SIZE,
- ALIGN_BOTH_ENDS | NEED_NON_STOLEN,
- TILE_NONE);
+ i830_allocate_aperture(pScrn, "DRI memory manager",
+ mmsize, 0, GTT_PAGE_SIZE,
+ ALIGN_BOTH_ENDS | NEED_NON_STOLEN,
+ TILE_NONE);
if (pI830->memory_manager != NULL) {
- if (!pI830->use_drm_mode) {
- struct drm_i915_gem_init init;
- int ret;
-
- sp.param = I915_SETPARAM_NUM_USED_FENCES;
- sp.value = 0; /* kernel gets them all */
-
- ret = drmCommandWrite(pI830->drmSubFD, DRM_I915_SETPARAM,
- &sp, sizeof(sp));
- if (ret == 0)
- pI830->kernel_exec_fencing = TRUE;
-
- init.gtt_start = pI830->memory_manager->offset;
- init.gtt_end = pI830->memory_manager->offset +
- pI830->memory_manager->size;
-
- /* Tell the kernel to manage it */
- ret = ioctl(pI830->drmSubFD, DRM_IOCTL_I915_GEM_INIT, &init);
- if (ret != 0) {
- xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
- "Failed to initialize kernel memory manager\n");
- i830_free_memory(pScr
[Bug 9379] drmCommandNone( fd, DRM_R128_CCE_IDLE ) - gives errno 22
http://bugs.freedesktop.org/show_bug.cgi?id=9379 --- Comment #16 from Andrew Péteri 2009-07-10 15:03:43 PST --- Created an attachment (id=27576) --> (http://bugs.freedesktop.org/attachment.cgi?id=27576) patch to add support for projective textures Enables hardware-accelerated rendering of primitives that have vertices with 'q' texture coordinates used in projective texture mapping. It must be applied after attachment 24949. The patch is generally based on the "ptex hack" found in the S3 Savage sources (which uses the standard vertex format, then shuffles values around to their correct position just before sending the vertices to the DMA buffer), modified to support two sets of texture coordinates; the vertex layout used by the r128, along with the additional vertex format flag needed, were obtained from earlier Mesa/DRI sources (eg. [1][2]). The performed calculations are essentially the same in both cases (savage & r128). Both patches apply against the mesa_7.4-0ubuntu3.1 source package and git commit eb33c0ab8b3594f0b1d58534a13a26e3fb050cff, however only the former has been tested. (ps. I'm unsure which vertex size the SAREA structure should store, but I also couldn't find any piece of code where that member gets referenced, so it may not matter either way.) [1] http://www.koders.com/c/fid0D7829772F2499BEA37AC17768976CD64AD3459C.aspx?s=rhw2#L62 [2] http://www.koders.com/c/fidDF4ACA3257B4F85D79E4E734EA089EC50D1DBB7F.aspx#L79 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 4/6] KMS: Map frame buffer at alloc time when running without UXA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
> Under KMS, the whole frame buffer is never allocated to the X server, and so
> accessing the frame buffer must be done by directly mapping it using
> drm_intel_gem_bo_map_gtt when it is created.
>
> Signed-off-by: Keith Packard
> ---
> src/drmmode_display.c | 16 ++--
> 1 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> index e9296dc..6681e7e 100644
> --- a/src/drmmode_display.c
> +++ b/src/drmmode_display.c
> @@ -1021,6 +1021,7 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width,
> int height)
> ScreenPtr screen = screenInfo.screens[scrn->scrnIndex];
> uint32_told_fb_id;
> int i, pitch, old_width, old_height, old_pitch;
> + pointer *data;
Is 'pointer *' actually what you wanted here? Either 'pointer' or plain
old 'void *' should be fine.
>
> if (scrn->virtualX == width && scrn->virtualY == height)
> return TRUE;
> @@ -1052,10 +1053,21 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width,
> int height)
> goto fail;
>
> i830_set_pixmap_bo(screen->GetScreenPixmap(screen),
> pI830->front_buffer->bo);
> - scrn->fbOffset = pI830->front_buffer->offset;
> + if (pI830->accel == ACCEL_UXA)
> + data = NULL;
> + else {
> + drm_intel_gem_bo_map_gtt(pI830->front_buffer->bo);
> + data = pI830->front_buffer->bo->virtual;
> + }
>
> screen->ModifyPixmapHeader(screen->GetScreenPixmap(screen),
> -width, height, -1, -1, pitch * pI830->cpp,
> NULL);
> +width, height, -1, -1, pitch * pI830->cpp,
> +data);
> +
> + /* ick. xf86EnableDisableFBAccess smashes the screen pixmap devPrivate,
> + * so update the value it uses
> + */
> + scrn->pixmapPrivate.ptr = data;
> xf86DrvMsg(scrn->scrnIndex, X_INFO, "New front buffer at 0x%lx\n",
> pI830->front_buffer->offset);
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpXmAgACgkQX1gOwKyEAw9j0ACglW0VmnJ725qmXObfbv3P6+jk
yXAAn24JH0BmJa54bSVBSPjyHuzlp/8V
=NHaM
-END PGP SIGNATURE-
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/6] Enable UXA for all screen sizes as UXA deals with oversize pixmaps already
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
> There's no reason to disable UXA because the initial frame buffer allocation
> is too large -- UXA deals with fallbacks for oversize pixmaps internally on
> a case-by-case basis. This allows large frame buffers to have simple
> fill/blt acceleration while only falling back to software for operations
> involving the 3D engine.
>
> Signed-off-by: Keith Packard
Reviewed-by: Ian Romanick
> ---
> src/i830_driver.c |5 -
> 1 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/src/i830_driver.c b/src/i830_driver.c
> index db00af8..067a098 100644
> --- a/src/i830_driver.c
> +++ b/src/i830_driver.c
> @@ -1691,11 +1691,6 @@ I830PreInit(ScrnInfoPtr pScrn, int flags)
> }
> pScrn->currentMode = pScrn->modes;
>
> - if (!IS_I965G(pI830) && pScrn->virtualY > 2048) {
> - xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "Cannot support > 2048 vertical
> lines. disabling acceleration.\n");
> - pI830->accel = ACCEL_NONE;
> - }
> -
> /* Set display resolution */
> xf86SetDpi(pScrn, 0, 0);
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpXlxQACgkQX1gOwKyEAw9ljQCePZUCuH+shEeEOlnoqnGOacnC
i1QAnji16xxjV+ksYe1XQBKR6YZUyVq+
=D2Wk
-END PGP SIGNATURE-
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm: previous pull req + 1.
On Mon, 2009-06-29 at 08:57 +0100, Chris Wilson wrote:
> On Mon, 2009-06-22 at 21:09 +0300, Maxim Levitsky wrote:
> > Nope, same thing.
> >
> > I use commit 87ef92092fd092936535ba057ee19b97bb6a709a + this patch
> > Note that GE doesn't hang the system when maximizing it.
> >
> > It is for sure tiled textures accessed incorrectly, same behavior
> > observed in many games (they still run though)
>
> Sorry for the delay, I was travelling last week and was sure I had
> nailed the problem. Aside from the missing flush on i965 when a batch
> buffer might be using fenced commands, the only other issue I found was
> that we did not zap the mapping range on clear - which could also cause
> tiling errors if textures were being written via a GTT mmap.
>
> So please can you try this patch:
>
> >From 20b7c9322914213bb589035afbbc03faf1ae3bf0 Mon Sep 17 00:00:00 2001
> From: Chris Wilson
> Date: Mon, 29 Jun 2009 08:45:31 +0100
> Subject: [PATCH] drm/i915: Remove mappings on clearing fence register
>
> As the fence register is not locked whilst the user has mmaped the buffer
> through the GTT, in order for the buffer to reacquire a fence register we
> need to cause a fresh page-fault on the next user access. In order to
> cause the page fault, we zap the current mapping on clearing the register.
> We also ensure that all potential outstanding access via the fence
> register is flushed before release as well.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem.c | 41 ++
> 1 files changed, 19 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 685a876..6dc74c8 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1946,12 +1946,6 @@ i915_gem_object_unbind(struct drm_gem_object *obj)
> obj_priv->agp_mem = NULL;
> }
>
> -
> - /* blow away mappings if mapped through GTT */
> - if (obj_priv->mmap_offset && dev->dev_mapping)
> - unmap_mapping_range(dev->dev_mapping,
> - obj_priv->mmap_offset, obj->size, 1);
> -
Err, so now untiled things wouldn't fault to rebind? Seems wrong.
> @@ -2456,6 +2451,11 @@ i915_gem_clear_fence_reg(struct drm_gem_object *obj)
>
> dev_priv->fence_regs[obj_priv->fence_reg].obj = NULL;
> obj_priv->fence_reg = I915_FENCE_REG_NONE;
> +
> + /* blow away mappings if mapped through GTT */
> + if (obj_priv->mmap_offset && dev->dev_mapping)
> + unmap_mapping_range(dev->dev_mapping,
> + obj_priv->mmap_offset, obj->size, 1);
> }
This part seems good.
>
> /**
> @@ -2469,27 +2469,24 @@ i915_gem_clear_fence_reg(struct drm_gem_object *obj)
> int
> i915_gem_object_put_fence_reg(struct drm_gem_object *obj)
> {
> - struct drm_device *dev = obj->dev;
> struct drm_i915_gem_object *obj_priv = obj->driver_private;
> + int ret;
>
> if (obj_priv->fence_reg == I915_FENCE_REG_NONE)
> return 0;
>
> - /* On the i915, GPU access to tiled buffers is via a fence,
> - * therefore we must wait for any outstanding access to complete
> - * before clearing the fence.
> + /* If there is outstanding activity on the buffer whilst it holds
> + * a fence register we must assume that it requires that fence for
> + * correct operation. Therefore we must wait for any outstanding
> + * access to complete before clearing the fence.
>*/
> - if (!IS_I965G(dev)) {
> - int ret;
> -
> - i915_gem_object_flush_gpu_write_domain(obj);
> - i915_gem_object_flush_gtt_write_domain(obj);
> - ret = i915_gem_object_wait_rendering(obj);
> - if (ret != 0)
> - return ret;
> - }
> + i915_gem_object_flush_gpu_write_domain(obj);
> + i915_gem_object_flush_gtt_write_domain(obj);
> + ret = i915_gem_object_wait_rendering(obj);
> + if (ret != 0)
> + return ret;
>
> - i915_gem_clear_fence_reg (obj);
> + i915_gem_clear_fence_reg(obj);
>
> return 0;
> }
This part doesn't make sense to me. There should be nothing in the 965
rendering path that's using fences. Did you identify something that
was?
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.s
[Bug 22696] Compiling Problem
http://bugs.freedesktop.org/show_bug.cgi?id=22696 --- Comment #6 from Michel Dänzer 2009-07-10 05:58:34 PST --- There's no non-Gallium nouveau driver anymore. I've removed the stale reference from configure.ac in mesa_7_5_branch, it'll be gone from master as well on the next merge. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22696] Compiling Problem
http://bugs.freedesktop.org/show_bug.cgi?id=22696 --- Comment #5 from Steven Ward 2009-07-10 05:08:50 PST --- Hi, Thanks for the info,here's what I did. I ran a make realclean and then used my configure options with --with-dri-drivers=swrast at the end.Gmake worked and did a gmake install. However I'm a bit curious,when I used ./configure --help,the option came up with this: --with-dri-drivers[=DIRS...] comma delimited DRI drivers list, e.g. "swrast,i965,radeon,nouveau" [default=auto] When I used --with-dri-drivers=swrast,nouveau,./configure compilained it couldn't find nouveau.According to configure.ac,it uses that option to look for the folders and Makfile.template in /src/mesa/drivers/dri and sure enough the nouveau folder was missing from there.There two other nouveau folders in /src/gallium/drivers and /src/gallium/drivers/winsys/drm.Which nouveau folder would be best to copy over into /src/mesa/drivers/dri and edit the Makfile.template so I can use --with-dri-drivers=swrast,nouveau at the end of my ./configure options? Regards, STEVE555 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] DRM: Fix VBlank IRQ on VIA hardware.
via_enable_vblank wasn't setting the VBlank enable bit - instead, it
was masking out the rest of the register.
At the same time, fix via_disable_vblank to clear the VBlank enable
bit.
---
drivers/gpu/drm/via/via_irq.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index c248c1d..5935b88 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -183,7 +183,7 @@ int via_enable_vblank(struct drm_device *dev, int crtc)
}
status = VIA_READ(VIA_REG_INTERRUPT);
- VIA_WRITE(VIA_REG_INTERRUPT, status & VIA_IRQ_VBLANK_ENABLE);
+ VIA_WRITE(VIA_REG_INTERRUPT, status | VIA_IRQ_VBLANK_ENABLE);
VIA_WRITE8(0x83d4, 0x11);
VIA_WRITE8(0x83d5, VIA_READ8(0x83d5) | 0x30);
@@ -194,6 +194,10 @@ int via_enable_vblank(struct drm_device *dev, int crtc)
void via_disable_vblank(struct drm_device *dev, int crtc)
{
drm_via_private_t *dev_priv = dev->dev_private;
+ u32 status;
+
+ status = VIA_READ(VIA_REG_INTERRUPT);
+ VIA_WRITE(VIA_REG_INTERRUPT, status & ~VIA_IRQ_VBLANK_ENABLE);
VIA_WRITE8(0x83d4, 0x11);
VIA_WRITE8(0x83d5, VIA_READ8(0x83d5) & ~0x30);
--
1.5.4.1
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: openGL: libGL error: failed to open drm device: Permission denied althought Mode 0666 is set
On Thu, 2009-07-09 at 18:52 +0200, Marc Elser wrote: > Hi, > > I'm trying to use the new intel,mesa,libdrm from the git repository with > xorg-server-1.6.1.902_r1. > > Although in Xorg.0.log the driver loads ok (here an excerpt from the log): > (II) AIGLX: enabled GLX_MESA_copy_sub_buffer > (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control > (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects > (II) AIGLX: Loaded and initialized /usr/lib/dri/i915_dri.so > (II) GLX: Initialized DRI2 GL provider for screen 0 > (II) intel(0): Setting screen physical size to 304 x 228 > > "LIBGL_DEBUG=verbose glxinfo" reports: > libGL: OpenDriver: trying /usr/lib/dri/tls/i915_dri.so > libGL: OpenDriver: trying /usr/lib/dri/i915_dri.so > libGL error: failed to open drm device: Permission denied > libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so > libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so > > but in Xorg.conf I have the needed DRI section like this: > Section "DRI" > Mode 0666 > EndSection > > So, what do I have to do, to have to correct permissions in opengl? Is > there a new section needed for DRI2 or do I need a newer xorg-server > version? What does ls -l /dev/dri/card0 say when the problem happens? Maybe it's being set up by udev for you, not X/libdrm. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22696] Compiling Problem
http://bugs.freedesktop.org/show_bug.cgi?id=22696 --- Comment #4 from Michel Dänzer 2009-07-10 02:44:33 PST --- The traditional DRI driver build is configured independently from Gallium and enabled by default. Try adding something like --with-dri-drivers=swrast . -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Nouveau] When will nouveau kernel tree be merged into master
On Thu, 2009-07-09 at 21:51 +0200, Eric Valette wrote: > Pekka Paalanen wrote: > > Sorry for causing that much trouble. > > > > On Thu, 09 Jul 2009 19:20:54 +0200 > > Eric Valette wrote: > > > >> Well I would suggest you to look at GALLIUM3D because using gi to clone > >> mesa master is not even working and even if you get a git snapshot it > >> does not build. > > > > http://nouveau.freedesktop.org/wiki/GalliumHowto > > Is there something unclear here? > > The command > git clone git://anongit.freedesktop.org/git/mesa/mesa > > Does not work for me while others do. It hangs indefinitely (I let it > run once half a day, doing strace to see that I was waiting to a read on > a socket). Maybe there's a firewall between you and anongit.freedesktop.org which is filtering the Git port (9418/tcp). -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Nouveau] When will nouveau kernel tree be merged into master
Sean Estabrooks wrote: > On Thu, 09 Jul 2009 21:51:23 +0200 > Eric Valette wrote: > > >> The command >> git clone git://anongit.freedesktop.org/git/mesa/mesa >> >> Does not work for me while others do. It hangs indefinitely (I let it >> run once half a day, doing strace to see that I was waiting to a read on >> a socket). >> >> BTW: looking at http://cgit.freedesktop.org/mesa/mesa/, the lats commit date look rather strange (-481 min). Negative time! -- eric -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: openGL: libGL error: failed to open drm device: Permission denied althought Mode 0666 is set
On Thursday 09 July 2009 18:52:24 Marc Elser wrote: > Hi, > > I'm trying to use the new intel,mesa,libdrm from the git repository with > xorg-server-1.6.1.902_r1. > > Although in Xorg.0.log the driver loads ok (here an excerpt from the log): > (II) AIGLX: enabled GLX_MESA_copy_sub_buffer > (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control > (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects > (II) AIGLX: Loaded and initialized /usr/lib/dri/i915_dri.so > (II) GLX: Initialized DRI2 GL provider for screen 0 > (II) intel(0): Setting screen physical size to 304 x 228 > > "LIBGL_DEBUG=verbose glxinfo" reports: > libGL: OpenDriver: trying /usr/lib/dri/tls/i915_dri.so > libGL: OpenDriver: trying /usr/lib/dri/i915_dri.so > libGL error: failed to open drm device: Permission denied > libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so > libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so > > but in Xorg.conf I have the needed DRI section like this: > Section "DRI" > Mode 0666 > EndSection > > So, what do I have to do, to have to correct permissions in opengl? Is > there a new section needed for DRI2 or do I need a newer xorg-server > version? > > I'm using kernel 2.6.28-r3 without kms (but enabling kms does not solve > the problem I already tried that). > > Thanks for any help with enabling opengl. Hi, try and see who owns /dev/dri/cardX. I had to add myself to the video group (on Debian). Hope this helps, Stefano > > Marc > > --- >--- Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22696] Compiling Problem
http://bugs.freedesktop.org/show_bug.cgi?id=22696 --- Comment #3 from Steven Ward 2009-07-10 01:27:43 PST --- (In reply to comment #2) > Hi there, > I certainly don't build the Radeon drivers for nouveau,I explicitly > use > --disable-gallium-radeon and --disable-gallium-intel in my ./configure options > before I run gmake to make sure I don't build them,but gmake seems to build > the > code for them anyway.I suspect (it's only my guess,I don't know) that gmake > links up with either linux,linux-dri,or linux-dri-x86 in the configs folder > when I run gmake,but since using --enbale-gallium-nouveau in ./configure > should > bypass that and using the old the old method. > > Regards, >STEVE555 > Sorry, The last sentence should read using --enable-gallium-nouveau in ./configure should bypass the old method of just using make linux-xxx -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22696] Compiling Problem
http://bugs.freedesktop.org/show_bug.cgi?id=22696 --- Comment #2 from Steven Ward 2009-07-10 01:19:34 PST --- Hi there, I certainly don't build the Radeon drivers for nouveau,I explicitly use --disable-gallium-radeon and --disable-gallium-intel in my ./configure options before I run gmake to make sure I don't build them,but gmake seems to build the code for them anyway.I suspect (it's only my guess,I don't know) that gmake links up with either linux,linux-dri,or linux-dri-x86 in the configs folder when I run gmake,but since using --enbale-gallium-nouveau in ./configure should bypass that and using the old the old method. Regards, STEVE555 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Nouveau] When will nouveau kernel tree be merged into master
Sean Estabrooks wrote: > On Thu, 09 Jul 2009 21:51:23 +0200 > Eric Valette wrote: > > >> The command >> git clone git://anongit.freedesktop.org/git/mesa/mesa >> >> Does not work for me while others do. It hangs indefinitely (I let it >> run once half a day, doing strace to see that I was waiting to a read on >> a socket). >> >> >>> Also, I'd recommend studying git, you only ever have to 'clone' once. >>> >> If the full clone requires a day on 1Mbit sped, I guess you will have >> few volunteers. >> > > Eric, > > Tried the clone of Mesa just now here and it took a little over 5 minutes > to complete. So, something is wrong for you locally or a server problem > has been fixed since you last tried the clone. If it a local problem, I dunno why because I access nearly all other git tree on the planet including one located on the same IP address drm git versus mesa git (git://anongit.freedesktop.org/mesa/mesa vs git://anongit.freedesktop.org/mesa/mesa/drm) > Either way, this isn't > a fundamental problem with Git. > Good. Will try today again. BTW: I managed to build a mixed kernel (master 2.6.31-rc2-git4 + 2 DRM directory from nouveau kernel git). It compiled and worked as long as I relaunched the X kernel to use again the nouveau driver instead of nv (and access the nouveau module). I then got a sync out of range on the monitor. Removing the KMS mode fixed this but I'm not sure if it is not due to the left over vesa framebuffer option or wrong computation of monitor capabilities and bad video mode settings. I need to remove the vesa framebuffer, put the KMS option gain and report. It was just too late last night to try this. -- eric -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22696] Compiling Problem
http://bugs.freedesktop.org/show_bug.cgi?id=22696 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #1 from Michel Dänzer 2009-07-10 00:55:54 PST --- Looks like a mismatch between mesa and libdrm_radeon. You don't need to build any of the Radeon drivers anyway for nouveau. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Nouveau] When will nouveau kernel tree be merged into master
On Thu, 09 Jul 2009 21:51:23 +0200 Eric Valette wrote: > The command > git clone git://anongit.freedesktop.org/git/mesa/mesa > > Does not work for me while others do. It hangs indefinitely (I let it > run once half a day, doing strace to see that I was waiting to a read on > a socket). > > > Also, I'd recommend studying git, you only ever have to 'clone' once. > > If the full clone requires a day on 1Mbit sped, I guess you will have > few volunteers. Eric, Tried the clone of Mesa just now here and it took a little over 5 minutes to complete. So, something is wrong for you locally or a server problem has been fixed since you last tried the clone. Either way, this isn't a fundamental problem with Git. Cheers, Sean -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix VRAM sizing like DDX does it.
From: Dave Airlie
Doing this like the DDX seems like the most sure fire way to avoid
having to reinvent it slowly and painfully. At the moment we keep
getting things wrong with aper vs vram, so we know the DDX does it right.
booted on PCI r100, PCIE rv370, IGP rs400.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/r100.c | 65 +++-
drivers/gpu/drm/radeon/r300.c |4 +-
drivers/gpu/drm/radeon/r520.c |4 +-
drivers/gpu/drm/radeon/radeon.h|2 +
drivers/gpu/drm/radeon/radeon_device.c |7 +---
drivers/gpu/drm/radeon/rs400.c | 14 +--
drivers/gpu/drm/radeon/rv515.c |6 +--
7 files changed, 71 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 154648a..97c9229 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1360,9 +1360,50 @@ static void r100_vram_get_type(struct radeon_device
*rdev)
}
}
-void r100_vram_info(struct radeon_device *rdev)
+static u32 r100_get_accessible_vram(struct radeon_device *rdev)
{
- r100_vram_get_type(rdev);
+ u32 aper_size;
+ u8 byte;
+
+ aper_size = RREG32(RADEON_CONFIG_APER_SIZE);
+
+ /* Set HDP_APER_CNTL only on cards that are known not to be broken,
+* that is has the 2nd generation multifunction PCI interface
+*/
+ if (rdev->family == CHIP_RV280 ||
+ rdev->family >= CHIP_RV350) {
+ WREG32_P(RADEON_HOST_PATH_CNTL, RADEON_HDP_APER_CNTL,
+ ~RADEON_HDP_APER_CNTL);
+ DRM_INFO("Generation 2 PCI interface, using max accessible
memory\n");
+ return aper_size * 2;
+ }
+
+ /* Older cards have all sorts of funny issues to deal with. First
+* check if it's a multifunction card by reading the PCI config
+* header type... Limit those to one aperture size
+*/
+ pci_read_config_byte(rdev->pdev, 0xe, &byte);
+ if (byte & 0x80) {
+ DRM_INFO("Generation 1 PCI interface in multifunction mode\n");
+ DRM_INFO("Limiting VRAM to one aperture\n");
+ return aper_size;
+ }
+
+ /* Single function older card. We read HDP_APER_CNTL to see how the BIOS
+* have set it up. We don't write this as it's broken on some ASICs but
+* we expect the BIOS to have done the right thing (might be too
optimistic...)
+*/
+ if (RREG32(RADEON_HOST_PATH_CNTL) & RADEON_HDP_APER_CNTL)
+ return aper_size * 2;
+ return aper_size;
+}
+
+void r100_vram_init_sizes(struct radeon_device *rdev)
+{
+ u64 config_aper_size;
+ u32 accessible;
+
+ config_aper_size = RREG32(RADEON_CONFIG_APER_SIZE);
if (rdev->flags & RADEON_IS_IGP) {
uint32_t tom;
@@ -1383,10 +1424,30 @@ void r100_vram_info(struct radeon_device *rdev)
}
/* let driver place VRAM */
rdev->mc.vram_location = 0xUL;
+/* Fix for RN50, M6, M7 with 8/16/32(??) MBs of VRAM -
+ * Novell bug 204882 + along with lots of ubuntu ones */
+ if (config_aper_size > rdev->mc.vram_size)
+ rdev->mc.vram_size = config_aper_size;
}
+ /* work out accessible VRAM */
+ accessible = r100_get_accessible_vram(rdev);
+
rdev->mc.aper_base = drm_get_resource_start(rdev->ddev, 0);
rdev->mc.aper_size = drm_get_resource_len(rdev->ddev, 0);
+
+ if (accessible > rdev->mc.aper_size)
+ accessible = rdev->mc.aper_size;
+
+ if (rdev->mc.vram_size > rdev->mc.aper_size)
+ rdev->mc.vram_size = rdev->mc.aper_size;
+}
+
+void r100_vram_info(struct radeon_device *rdev)
+{
+ r100_vram_get_type(rdev);
+
+ r100_vram_init_sizes(rdev);
}
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 6435d65..0e0e094 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -585,10 +585,8 @@ void r300_vram_info(struct radeon_device *rdev)
} else {
rdev->mc.vram_width = 64;
}
- rdev->mc.vram_size = RREG32(RADEON_CONFIG_MEMSIZE);
- rdev->mc.aper_base = drm_get_resource_start(rdev->ddev, 0);
- rdev->mc.aper_size = drm_get_resource_len(rdev->ddev, 0);
+ r100_vram_init_sizes(rdev);
}
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index 570a244..b6bd375 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -227,8 +227,6 @@ static void r520_vram_get_type(struct radeon_device *rdev)
void r520_vram_info(struct radeon_device *rdev)
{
r520_vram_get_type(rdev);
- rdev->mc.vram_size = RREG32(RADEON_CONFIG_MEMSIZE);
- rdev->mc.aper_base = drm_get_resource_start(rdev->ddev, 0);
- rdev->mc.aper_size = drm_get
[Bug 22696] New: Compiling Problem
http://bugs.freedesktop.org/show_bug.cgi?id=22696 Summary: Compiling Problem Product: Mesa Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: trivial Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: stevenward...@hotmail.com Hi to all, I'm currently using Fedora Rawhide.I compile the D.R.M,Mesa,xf86-video-nouveau and now the Linux-2.6 unamed repository to build the drm and nouveau kernel modules from git. When compiling the Mesa code,I use ./configure --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --datadir=/usr/share --sysconfdir=/etc --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --docdir=/usr/share/doc --enable-selinux --x-libraries=/usr/lib --enable-32-bit --enable-xcb --enable-gallium-nouveau --with-x --with-dri-driverdir=/usr/lib/dri --with-xorg-driver-dir=/usr/lib/xorg/modules/drivers --with-state-trackers=dri,egl,xorg,glx --enable-motif --enable-gl-osmesa --with-osmesa-bits=32 --disable-gallium-intel --disable-gallium-radeon --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests and then gmake. The mesa code ends with this error: r200_pixel.c:106: warning: ‘clip_pixelrect’ defined but not used gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/include/drm -I/usr/lib/include -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DMESA_SELINUX -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_LIBDRM_RADEON=1 -I/usr/include/drm -DRADEON_COMMON=1 -DRADEON_COMMON_FOR_R200 r200_tex.c -o r200_tex.o gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/include/drm -I/usr/lib/include -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DMESA_SELINUX -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_LIBDRM_RADEON=1 -I/usr/include/drm -DRADEON_COMMON=1 -DRADEON_COMMON_FOR_R200 r200_texstate.c -o r200_texstate.o gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/include/drm -I/usr/lib/include -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DMESA_SELINUX -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_LIBDRM_RADEON=1 -I/usr/include/drm -DRADEON_COMMON=1 -DRADEON_COMMON_FOR_R200 r200_tcl.c -o r200_tcl.o gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/include/drm -I/usr/lib/include -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m32 -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DMESA_SELINUX -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_LIBDRM_RADEON=1 -I/usr/include/drm -DRADEON_COMMON=1 -DRADEON_COMMON_FOR_R200 r200_swtcl.c -o r200_swtcl.o In file included from r200_swtcl.c:475: ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h: In function ‘quadr_twoside’: ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:401: warning: ‘color[3]’ may be used uninitialized in this function ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:401: warning: ‘color[2]’ may be used uninitialized in this function ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:401: warning: ‘color[1]’ may be used uninitialized in this function ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:401: warning: ‘spec[3]’ may be used uninitialized in this function ../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:401: warning: ‘spec[2]’ may be used uninitialized in this function
Re: [Nouveau] When will nouveau kernel tree be merged into master
Pekka Paalanen wrote: > On Thu, 09 Jul 2009 14:00:29 +0200 > Eric Valette wrote: > >> I've been using nouveau driveau for 8 months or so, using automated >> build from drm git, xf86-video-nouveau git and even sometimes mesa drm >> git and discovered the linux-core build did not build the nouveau >> driver the hard way: X was refusing to start as the nouveau.ko modules >> was not loaded nor build. Build process did chnage without obvious way >> to know womething was wrong. > > Nouveau was removed from make targets, therefore you get this: > > $ make nouveau.o > make: *** No rule to make target `nouveau.o'. Stop. Except this is not the way you build linux-core by default... If you follow the Makefile and make DRM_MODULES=nouveau compilation fails without telling you this is no more the right way. > Btw. Nouveau should fall back to NoAccel mode, if the kernel modules are > not available. Not in my case. KDM simply does not start. >> So my question are: >> - Why not purely delete nouveau files from linux-core and issue >> error messages? > > The code is still in the tree for historical reference, and for BSDs. > I'm not sure if BSDs still need it. Not a convincing agument!. I wasted a few hours trying to find how to compile it. > Yes, and we are trying to alleviate the pain by keeping the guides > in the wiki up-to-date. Granted, there were the few days, when drm.git > nouveau.ko build was broken, and the InstallDRM page was not written > yet, nor InstallNouveau updated. IIRC that was less than a week. Well I would suggest you to look at GALLIUM3D because using gi to clone mesa master is not even working and even if you get a git snapshot it does not build. > The nouveau kernel tree was annouced on the wiki front page, and on > the nouveau mailing list. What more should we have done? I guess I would have done: - when configuring drm with the nouveau API, I would have issued a warning that linux-core will no more build nouveau.ko - I would have purely removed the code now that it is no more used or at least issed an error if DRM_MODULE was containing "nouveau" -- eric -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
openGL: libGL error: failed to open drm device: Permission denied althought Mode 0666 is set
Hi, I'm trying to use the new intel,mesa,libdrm from the git repository with xorg-server-1.6.1.902_r1. Although in Xorg.0.log the driver loads ok (here an excerpt from the log): (II) AIGLX: enabled GLX_MESA_copy_sub_buffer (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects (II) AIGLX: Loaded and initialized /usr/lib/dri/i915_dri.so (II) GLX: Initialized DRI2 GL provider for screen 0 (II) intel(0): Setting screen physical size to 304 x 228 "LIBGL_DEBUG=verbose glxinfo" reports: libGL: OpenDriver: trying /usr/lib/dri/tls/i915_dri.so libGL: OpenDriver: trying /usr/lib/dri/i915_dri.so libGL error: failed to open drm device: Permission denied libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so but in Xorg.conf I have the needed DRI section like this: Section "DRI" Mode 0666 EndSection So, what do I have to do, to have to correct permissions in opengl? Is there a new section needed for DRI2 or do I need a newer xorg-server version? I'm using kernel 2.6.28-r3 without kms (but enabling kms does not solve the problem I already tried that). Thanks for any help with enabling opengl. Marc -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Make xorg.conf NoAccel/DRI options work under KMS
On Thu, Jul 9, 2009 at 09:36:21 -0700, Jesse Barnes wrote: > I wonder if fbdev could fill the "get something on the screen when the > driver is busted" hole. Is it good enough to rely on for that? > IIRC that won't currently work well, because probe_devices_from_device_sections will claim the pci device for the intel driver, at which point fbdev's xf86ClaimFbSlot will fail and it will be disabled before intel has a chance to run its init stuff (so before we know if it's busted). So you need to either uninstall intel, or know the magic xorg.conf incantation to use fbdev. Cheers, Julien -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2][DRM]: Add the explanation about DRM debug level
From: Zhao Yakui Add the explanation about DRM debug level in the drmP header file. This is to explain how/where to use the different DRM debug level. Signed-off-by: Zhao Yakui --- include/drm/drmP.h | 40 1 files changed, 40 insertions(+), 0 deletions(-) diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 45b67d9..05e9c8f 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -89,6 +89,46 @@ struct drm_device; #define DRM_UT_DRIVER 0x02 #define DRM_UT_KMS 0x04 #define DRM_UT_MODE0x08 +/* + * Four debug levels are defined. + * drm_core, drm_driver, drm_kms, drm_mode + * drm_core level can be used in the generic drm code. For example: + * drm_ioctl, drm_mm, drm_memory + * The macro definiton of DRM_DEBUG is used. + * DRM_DEBUG(fmt, args...) + * The debug info by using the DRM_DEBUG can be obtained by adding + * the boot option of "drm.debug=1". + * + * drm_driver level can be used in the specific drm driver. It is used + * to add the debug info related with the drm driver. For example: + * i915_drv, i915_dma, i915_gem, radeon_gem, + * The macro definition of DRM_DEBUG_DRIVER can be used. + * DRM_DEBUG_DRIVER(prefix, fmt, args...) , the prefix is a string and + * the different prefix can be used in the different file + * The debug info by using the DRM_DEBUG_DRIVER can be obtained by + * adding the boot option of "drm.debug=0x02" + * + * drm_kms level can be used in the KMS code related with specific drm driver. + * It is used to add the debug info related with KMS mode. For example: + * the connector/crtc + * the marco definition of DRM_DEBUG_KMS can be used + * DRM_DEBUG_KMS(prefix, fmt, args...) , the prefix is a string and + * the different prefix can be used in the different file. + * The debug info by using the DRM_DEBUG_KMS can be obtained by + * adding the boot option of "drm.debug=0x04" + * + * drm_mode level can be used to add the debug info related with generic DRM + * mode. For example: + * drm_modes.c, drm_crtc_helper.c + * The macro definition of DRM_DEBUG_MODE can be used. + * DRM_DEBUG_MODE(prefix, fmt, args...) , the prefix is a string and + * the different prefix can be used in the different file. + * The debug info by using the DRM_DEBUG_MODE can be obtained by + * adding the boot option of "drm.debug=0x08" + * + * If we add the boot option of "drm.debug=0x0c", we can get the debug info by + * using the DRM_DEBUG_KMS and DRM_DEBUG_MODE. + */ extern void drm_ut_debug_printk(unsigned int request_level, const char *prefix, -- 1.5.4.5 -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] [DRM]: Use the DRM_DEBUG_MODE to add the debug info for generic DRM modes
From: Zhao Yakui
Use the DRM_DEBUG_MODE to add the debug info in generic DRM modes
Signed-off-by: Zhao Yakui
---
drivers/gpu/drm/drm_crtc.c| 36 +---
drivers/gpu/drm/drm_crtc_helper.c | 65 ++--
2 files changed, 63 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8fab789..181a9a9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -34,6 +34,8 @@
#include "drmP.h"
#include "drm_crtc.h"
+#define DRM_CRTC "drm_crtc"
+
struct drm_prop_enum_list {
int type;
char *name;
@@ -1060,7 +1062,8 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
if (file_priv->master->minor->type == DRM_MINOR_CONTROL) {
list_for_each_entry(crtc, &dev->mode_config.crtc_list,
head) {
- DRM_DEBUG("CRTC ID is %d\n", crtc->base.id);
+ DRM_DEBUG_MODE(DRM_CRTC,
+ "CRTC ID is %d\n", crtc->base.id);
if (put_user(crtc->base.id, crtc_id + copied)) {
ret = -EFAULT;
goto out;
@@ -1088,7 +1091,7 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
list_for_each_entry(encoder,
&dev->mode_config.encoder_list,
head) {
- DRM_DEBUG("ENCODER ID is %d\n",
+ DRM_DEBUG_MODE(DRM_CRTC, "ENCODER ID is %d\n",
encoder->base.id);
if (put_user(encoder->base.id, encoder_id +
copied)) {
@@ -1119,7 +1122,7 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
list_for_each_entry(connector,
&dev->mode_config.connector_list,
head) {
- DRM_DEBUG("CONNECTOR ID is %d\n",
+ DRM_DEBUG_MODE(DRM_CRTC, "CONNECTOR ID is %d\n",
connector->base.id);
if (put_user(connector->base.id,
connector_id + copied)) {
@@ -1143,7 +1146,7 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
}
card_res->count_connectors = connector_count;
- DRM_DEBUG("Counted %d %d %d\n", card_res->count_crtcs,
+ DRM_DEBUG_MODE(DRM_CRTC, "Counted %d %d %d\n", card_res->count_crtcs,
card_res->count_connectors, card_res->count_encoders);
out:
@@ -1246,7 +1249,7 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
memset(&u_mode, 0, sizeof(struct drm_mode_modeinfo));
- DRM_DEBUG("connector id %d:\n", out_resp->connector_id);
+ DRM_DEBUG_MODE(DRM_CRTC, "connector id %d:\n", out_resp->connector_id);
mutex_lock(&dev->mode_config.mutex);
@@ -1422,7 +1425,8 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
obj = drm_mode_object_find(dev, crtc_req->crtc_id,
DRM_MODE_OBJECT_CRTC);
if (!obj) {
- DRM_DEBUG("Unknown CRTC ID %d\n", crtc_req->crtc_id);
+ DRM_DEBUG_MODE(DRM_CRTC, "Unknown CRTC ID %d\n",
+ crtc_req->crtc_id);
ret = -EINVAL;
goto out;
}
@@ -1435,7 +1439,8 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
list_for_each_entry(crtcfb,
&dev->mode_config.crtc_list, head) {
if (crtcfb == crtc) {
- DRM_DEBUG("Using current fb for
setmode\n");
+ DRM_DEBUG_MODE(DRM_CRTC,
+ "Using current fb for
setmode\n");
fb = crtc->fb;
}
}
@@ -1443,7 +1448,8 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
obj = drm_mode_object_find(dev, crtc_req->fb_id,
DRM_MODE_OBJECT_FB);
if (!obj) {
- DRM_DEBUG("Unknown FB ID%d\n", crtc_req->fb_id);
+ DRM_DEBUG_MODE(DRM_CRTC, "Unknown FB ID%d\n",
+ crtc_req->fb_id);
ret = -EINVAL;
goto out;
}
@@ -1456,13 +1462,15 @@ int drm_mode_set
Re: 2.6.31-rc2: Reported regressions from 2.6.30
On Tue, 2009-07-07 at 03:25 +0200, Andres Freund wrote: > There is also http://lkml.org/lkml/2009/6/30/398 : Soft-Lockup/Race > in > networking in 2.6.31-rc1+195 (possibly caused by netem) There is some similarity between this soft lockup and the one reported in http://www.spinics.net/lists/netdev/msg100957.html. In both, the process is doing both sends and receives on raw sockets. -- John -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Nouveau] When will nouveau kernel tree be merged into master
Pekka Paalanen wrote: > Sorry for causing that much trouble. > > On Thu, 09 Jul 2009 19:20:54 +0200 > Eric Valette wrote: > >> Well I would suggest you to look at GALLIUM3D because using gi to clone >> mesa master is not even working and even if you get a git snapshot it >> does not build. > > http://nouveau.freedesktop.org/wiki/GalliumHowto > Is there something unclear here? The command git clone git://anongit.freedesktop.org/git/mesa/mesa Does not work for me while others do. It hangs indefinitely (I let it run once half a day, doing strace to see that I was waiting to a read on a socket). > Also, I'd recommend studying git, you only ever have to 'clone' once. If the full clone requires a day on 1Mbit sped, I guess you will have few volunteers. > Receiving updates is a lot faster. I tool you in the first mail, I use drm git, xf86-video-nouveau git and you still suggest I should learn how to use git? In my kernel udate script I have git fetch ; git rebase origin for several trees. I ommited mesa because of the bug > InstallDRM has the instructions, since > the kernel tree is so big, but there are more than one way to pull updates. I do not mind you use a whole kernel tree provide you provide automated way to extract diff compared to the kernel you pull in. I've found the tarball already but will rather extract the whole code and modify my rather complex kernel update script to move original drm directory back and forth for the sake of using still using ketchup, drm git update xf86-video-nouveau git update and regular kernel patching way. -- eric -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.31-rc2: Reported regressions from 2.6.30
Hi John, Hi Rafael, On Friday 10 July 2009 03:46:57 John Dykstra wrote: > On Tue, 2009-07-07 at 03:25 +0200, Andres Freund wrote: > > There is also http://lkml.org/lkml/2009/6/30/398 : Soft-Lockup/Race > > in > > networking in 2.6.31-rc1+195 (possibly caused by netem) > > There is some similarity between this soft lockup and the one reported > in http://www.spinics.net/lists/netdev/msg100957.html. In both, the > process is doing both sends and receives on raw sockets. The issue turned out to be a hrtimer bug - i dont see anything like it in your trace. If you still want to test the fix, its de907e8432b08f2d5966c36e0747e97c0e596810 in -tip (or http://lkml.org/lkml/2009/7/9/150) Rafael: In case youre reading this, I guess you can mark that bug as resolved. Andres -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
