Re: [PATCH 1/2] Remove unused local variable pRADEONEnt
On 30 July 2015 at 17:00, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
../../src/radeon_probe.c: In function 'radeon_get_scrninfo':
../../src/radeon_probe.c:157:22: warning: variable 'pRADEONEnt' set but not
used [-Wunused-but-set-variable]
RADEONEntPtr pRADEONEnt;
^
Signed-off-by: Michel Dänzer michel.daen...@amd.com
For both,
Reviewed-by: Dave Airlie airl...@redhat.com
---
src/radeon_probe.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/src/radeon_probe.c b/src/radeon_probe.c
index f81ed13..65cf0c9 100644
--- a/src/radeon_probe.c
+++ b/src/radeon_probe.c
@@ -154,7 +154,6 @@ radeon_get_scrninfo(int entity_num, void *pci_dev)
*/
{
DevUnion*pPriv;
-RADEONEntPtr pRADEONEnt;
xf86SetEntitySharable(entity_num);
@@ -166,12 +165,8 @@ radeon_get_scrninfo(int entity_num, void *pci_dev)
xf86SetEntityInstanceForScreen(pScrn, pEnt-index,
xf86GetNumEntityInstances(pEnt-index) - 1);
-if (!pPriv-ptr) {
+if (!pPriv-ptr)
pPriv-ptr = xnfcalloc(sizeof(RADEONEntRec), 1);
-pRADEONEnt = pPriv-ptr;
-} else {
-pRADEONEnt = pPriv-ptr;
-}
}
free(pEnt);
--
2.1.4
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 2/2] radeon: move radeon_pixmap forward declaration into other block
From: Dave Airlie airl...@redhat.com
There is already a radeon_pixmap forward decl here, the #else
block is missing one.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/radeon_glamor.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/radeon_glamor.h b/src/radeon_glamor.h
index 1ba7049..c77466e 100644
--- a/src/radeon_glamor.h
+++ b/src/radeon_glamor.h
@@ -61,8 +61,6 @@ struct radeon_pixmap;
#define GLAMOR_USE_PICTURE_SCREEN 0
#endif
-struct radeon_pixmap;
-
Bool radeon_glamor_pre_init(ScrnInfoPtr scrn);
Bool radeon_glamor_init(ScreenPtr screen);
void radeon_glamor_screen_init(ScreenPtr screen);
@@ -76,6 +74,8 @@ XF86VideoAdaptorPtr radeon_glamor_xv_init(ScreenPtr pScreen,
int num_adapt);
#else
+struct radeon_pixmap;
+
static inline Bool radeon_glamor_pre_init(ScrnInfoPtr scrn) { return FALSE; }
static inline Bool radeon_glamor_init(ScreenPtr screen) { return FALSE; }
static inline Bool radeon_glamor_create_screen_resources(ScreenPtr screen) {
return FALSE; }
--
2.4.3
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 1/2] radeon: cleanup the entity rec
From: Dave Airlie airl...@redhat.com
Some of these were set, some of them were
always opposites, so clean things up.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/drmmode_display.c | 2 +-
src/radeon.h | 1 -
src/radeon_kms.c | 5 -
src/radeon_probe.c| 4
src/radeon_probe.h| 4
5 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 337ee55..a769013 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1561,7 +1561,7 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, drmModeResPtr mode_r
if (!RADEONZaphodStringMatches(pScrn, s, name))
goto out_free_encoders;
} else {
- if (info-IsPrimary (num != 0))
+ if (!info-IsSecondary (num != 0))
goto out_free_encoders;
else if (info-IsSecondary (num != 1))
goto out_free_encoders;
diff --git a/src/radeon.h b/src/radeon.h
index d6f18fa..88df93f 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -499,7 +499,6 @@ typedef struct {
#endif
Bool IsSecondary;
-Bool IsPrimary;
Bool r600_shadow_fb;
void *fb_shadow;
diff --git a/src/radeon_kms.c b/src/radeon_kms.c
index 2dad0e6..14de0eb 100644
--- a/src/radeon_kms.c
+++ b/src/radeon_kms.c
@@ -1079,7 +1079,6 @@ Bool RADEONPreInit_KMS(ScrnInfoPtr pScrn, int flags)
info = RADEONPTR(pScrn);
info-IsSecondary = FALSE;
-info-IsPrimary = FALSE;
info-pEnt =
xf86GetEntityInfo(pScrn-entityList[pScrn-numEntities - 1]);
if (info-pEnt-location.type != BUS_PCI
#ifdef XSERVER_PLATFORM_BUS
@@ -1097,14 +1096,10 @@ Bool RADEONPreInit_KMS(ScrnInfoPtr pScrn, int flags)
if(xf86IsPrimInitDone(pScrn-entityList[0]))
{
info-IsSecondary = TRUE;
-pRADEONEnt-pSecondaryScrn = pScrn;
}
else
{
- info-IsPrimary = TRUE;
xf86SetPrimInitDone(pScrn-entityList[0]);
-pRADEONEnt-pPrimaryScrn = pScrn;
-pRADEONEnt-HasSecondary = FALSE;
}
}
diff --git a/src/radeon_probe.c b/src/radeon_probe.c
index ad1e96e..f81ed13 100644
--- a/src/radeon_probe.c
+++ b/src/radeon_probe.c
@@ -169,10 +169,8 @@ radeon_get_scrninfo(int entity_num, void *pci_dev)
if (!pPriv-ptr) {
pPriv-ptr = xnfcalloc(sizeof(RADEONEntRec), 1);
pRADEONEnt = pPriv-ptr;
-pRADEONEnt-HasSecondary = FALSE;
} else {
pRADEONEnt = pPriv-ptr;
-pRADEONEnt-HasSecondary = TRUE;
}
}
@@ -271,10 +269,8 @@ radeon_platform_probe(DriverPtr pDriver,
if (!pPriv-ptr) {
pPriv-ptr = xnfcalloc(sizeof(RADEONEntRec), 1);
pRADEONEnt = pPriv-ptr;
-pRADEONEnt-HasSecondary = FALSE;
} else {
pRADEONEnt = pPriv-ptr;
-pRADEONEnt-HasSecondary = TRUE;
}
pRADEONEnt-platform_dev = dev;
}
diff --git a/src/radeon_probe.h b/src/radeon_probe.h
index 958cb23..258c7be 100644
--- a/src/radeon_probe.h
+++ b/src/radeon_probe.h
@@ -132,12 +132,8 @@ typedef struct {
typedef struct
{
-Bool HasSecondary;
Bool HasCRTC2; /* All cards except original Radeon */
-ScrnInfoPtr pSecondaryScrn;
-ScrnInfoPtr pPrimaryScrn;
-
int fd; /* for sharing across zaphod heads */
int fd_ref;
unsigned long fd_wakeup_registered; /* server generation for which fd
has been registered for wakeup handling */
--
2.4.3
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH] radeon: adopt for new X server dirty tracking APIs.
Signed-off-by: Dave Airlie airl...@redhat.com --- src/drmmode_display.c | 4 +++- src/radeon_kms.c | 4 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/src/drmmode_display.c b/src/drmmode_display.c index ad2f48b..337ee55 100644 --- a/src/drmmode_display.c +++ b/src/drmmode_display.c @@ -969,7 +969,9 @@ drmmode_set_scanout_pixmap(xf86CrtcPtr crtc, PixmapPtr ppix) screen-height = screenpix-drawable.height = max_height; } drmmode_crtc-prime_pixmap_x = this_x; -#ifdef HAS_DIRTYTRACKING2 +#ifdef HAS_DIRTYTRACKING_ROTATION + PixmapStartDirtyTracking(ppix, screenpix, 0, 0, this_x, 0, RR_Rotate_0); +#elif defined(HAS_DIRTYTRACKING2) PixmapStartDirtyTracking2(ppix, screenpix, 0, 0, this_x, 0); #else PixmapStartDirtyTracking(ppix, screenpix, 0, 0); diff --git a/src/radeon_kms.c b/src/radeon_kms.c index ec8f51c..2dad0e6 100644 --- a/src/radeon_kms.c +++ b/src/radeon_kms.c @@ -287,7 +287,11 @@ redisplay_dirty(ScreenPtr screen, PixmapDirtyUpdatePtr dirty) PixmapRegionInit(pixregion, dirty-slave_dst); DamageRegionAppend(dirty-slave_dst-drawable, pixregion); +#ifdef HAS_DIRTYTRACKING_ROTATION + PixmapSyncDirtyHelper(dirty); +#else PixmapSyncDirtyHelper(dirty, pixregion); +#endif radeon_cs_flush_indirect(pScrn); DamageRegionProcessPending(dirty-slave_dst-drawable); -- 2.4.3 ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 3/3] radeon: add support for DP 1.2 display hotplug
From: Dave Airlie airl...@redhat.com
This allows for dynamic creation of conneectors when the
kernel tells us.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/drmmode_display.c | 174 --
src/drmmode_display.h | 2 +
src/radeon.h | 3 +-
src/radeon_kms.c | 5 ++
4 files changed, 177 insertions(+), 7 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index dd79db5..fc03842 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1194,11 +1194,66 @@ const char *output_names[] = { None,
#define NUM_OUTPUT_NAMES (sizeof(output_names) / sizeof(output_names[0]))
+static xf86OutputPtr find_output(ScrnInfoPtr pScrn, int id)
+{
+ xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
+ int i;
+ for (i = 0; i xf86_config-num_output; i++) {
+ xf86OutputPtr output = xf86_config-output[i];
+ drmmode_output_private_ptr drmmode_output;
+
+ drmmode_output = output-driver_private;
+ if (drmmode_output-output_id == id)
+ return output;
+ }
+ return NULL;
+}
+
+static int parse_path_blob(drmModePropertyBlobPtr path_blob, int
*conn_base_id, char **path)
+{
+ char *conn;
+ char conn_id[5];
+ int id, len;
+ char *blob_data;
+
+ if (!path_blob)
+ return -1;
+
+ blob_data = path_blob-data;
+ /* we only handle MST paths for now */
+ if (strncmp(blob_data, mst:, 4))
+ return -1;
+
+ conn = strchr(blob_data + 4, '-');
+ if (!conn)
+ return -1;
+ len = conn - (blob_data + 4);
+ if (len + 1 5)
+ return -1;
+ memcpy(conn_id, blob_data + 4, len);
+ conn_id[len] = '\0';
+ id = strtoul(conn_id, NULL, 10);
+
+ *conn_base_id = id;
+
+ *path = conn + 1;
+ return 0;
+}
+
static void
drmmode_create_name(ScrnInfoPtr pScrn, drmModeConnectorPtr koutput, char *name,
- int *num_dvi, int *num_hdmi)
+ drmModePropertyBlobPtr path_blob, int *num_dvi, int
*num_hdmi)
{
- {
+ xf86OutputPtr output;
+ int conn_id;
+ char *extra_path;
+
+ output = NULL;
+ if (parse_path_blob(path_blob, conn_id, extra_path) == 0)
+ output = find_output(pScrn, conn_id);
+ if (output) {
+ snprintf(name, 32, %s-%s, output-name, extra_path);
+ } else {
if (koutput-connector_type = NUM_OUTPUT_NAMES)
snprintf(name, 32, Unknown%d-%d,
koutput-connector_type,
koutput-connector_type_id - 1);
@@ -1241,14 +1296,16 @@ drmmode_create_name(ScrnInfoPtr pScrn,
drmModeConnectorPtr koutput, char *name,
}
static void
-drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, drmModeResPtr
mode_res, int num, int *num_dvi, int *num_hdmi)
+drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, drmModeResPtr
mode_res, int num, int *num_dvi, int *num_hdmi, int dynamic)
{
+ xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
RADEONInfoPtr info = RADEONPTR(pScrn);
xf86OutputPtr output;
drmModeConnectorPtr koutput;
drmModeEncoderPtr *kencoders = NULL;
drmmode_output_private_ptr drmmode_output;
drmModePropertyPtr props;
+ drmModePropertyBlobPtr path_blob = NULL;
char name[32];
int i;
const char *s;
@@ -1257,6 +1314,18 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, drmModeResPtr mode_r
if (!koutput)
return;
+ for (i = 0; i koutput-count_props; i++) {
+ props = drmModeGetProperty(drmmode-fd, koutput-props[i]);
+ if (props (props-flags DRM_MODE_PROP_BLOB)) {
+ if (!strcmp(props-name, PATH)) {
+ path_blob = drmModeGetPropertyBlob(drmmode-fd,
koutput-prop_values[i]);
+ drmModeFreeProperty(props);
+ break;
+ }
+ drmModeFreeProperty(props);
+ }
+ }
+
kencoders = calloc(sizeof(drmModeEncoderPtr), koutput-count_encoders);
if (!kencoders) {
goto out_free_encoders;
@@ -1269,7 +1338,26 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, drmModeResPtr mode_r
}
}
- drmmode_create_name(pScrn, koutput, name, num_dvi, num_hdmi);
+ drmmode_create_name(pScrn, koutput, name, path_blob, num_dvi, num_hdmi);
+ if (path_blob)
+ drmModeFreePropertyBlob(path_blob);
+
+ if (path_blob dynamic) {
+ /* See if we have an output with this name already
+* and hook stuff up.
+*/
+ for (i = 0; i xf86_config-num_output; i
add hotplug connector support
These patches just prepare the DDX for naming DP 1.2 MST connectors properly and to expect hotplug connectors. They are ported from similiar code I wrote for the Intel DDX. kernel support for radeon MST is still WIP, but I should get these upstream I suppose. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 2/3] radeon: move output name creation to its own function
From: Dave Airlie airl...@redhat.com
The secondary indent is deliberate to make the next patch more
parseable for mst support.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/drmmode_display.c | 85 ---
1 file changed, 47 insertions(+), 38 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index c69abbf..dd79db5 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1195,6 +1195,52 @@ const char *output_names[] = { None,
#define NUM_OUTPUT_NAMES (sizeof(output_names) / sizeof(output_names[0]))
static void
+drmmode_create_name(ScrnInfoPtr pScrn, drmModeConnectorPtr koutput, char *name,
+ int *num_dvi, int *num_hdmi)
+{
+ {
+ if (koutput-connector_type = NUM_OUTPUT_NAMES)
+ snprintf(name, 32, Unknown%d-%d,
koutput-connector_type,
+koutput-connector_type_id - 1);
+#ifdef RADEON_PIXMAP_SHARING
+ else if (pScrn-is_gpu)
+ snprintf(name, 32, %s-%d-%d,
+output_names[koutput-connector_type],
pScrn-scrnIndex - GPU_SCREEN_OFFSET + 1,
+koutput-connector_type_id - 1);
+#endif
+ else {
+ /* need to do smart conversion here for compat with
non-kms ATI driver */
+ if (koutput-connector_type_id == 1) {
+ switch(koutput-connector_type) {
+ case DRM_MODE_CONNECTOR_DVII:
+ case DRM_MODE_CONNECTOR_DVID:
+ case DRM_MODE_CONNECTOR_DVIA:
+ snprintf(name, 32, %s-%d,
output_names[koutput-connector_type], *num_dvi);
+ (*num_dvi)++;
+ break;
+ case DRM_MODE_CONNECTOR_HDMIA:
+ case DRM_MODE_CONNECTOR_HDMIB:
+ snprintf(name, 32, %s-%d,
output_names[koutput-connector_type], *num_hdmi);
+ (*num_hdmi)++;
+ break;
+ case DRM_MODE_CONNECTOR_VGA:
+ case DRM_MODE_CONNECTOR_DisplayPort:
+ snprintf(name, 32, %s-%d,
output_names[koutput-connector_type],
+koutput-connector_type_id -
1);
+ break;
+ default:
+ snprintf(name, 32, %s,
output_names[koutput-connector_type]);
+ break;
+ }
+ } else {
+ snprintf(name, 32, %s-%d,
output_names[koutput-connector_type],
+koutput-connector_type_id - 1);
+ }
+ }
+ }
+}
+
+static void
drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, drmModeResPtr
mode_res, int num, int *num_dvi, int *num_hdmi)
{
RADEONInfoPtr info = RADEONPTR(pScrn);
@@ -1223,44 +1269,7 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, drmModeResPtr mode_r
}
}
- if (koutput-connector_type = NUM_OUTPUT_NAMES)
- snprintf(name, 32, Unknown%d-%d, koutput-connector_type,
-koutput-connector_type_id - 1);
-#ifdef RADEON_PIXMAP_SHARING
- else if (pScrn-is_gpu)
- snprintf(name, 32, %s-%d-%d,
-output_names[koutput-connector_type],
pScrn-scrnIndex - GPU_SCREEN_OFFSET + 1,
-koutput-connector_type_id - 1);
-#endif
- else {
- /* need to do smart conversion here for compat with non-kms ATI
driver */
- if (koutput-connector_type_id == 1) {
- switch(koutput-connector_type) {
- case DRM_MODE_CONNECTOR_DVII:
- case DRM_MODE_CONNECTOR_DVID:
- case DRM_MODE_CONNECTOR_DVIA:
- snprintf(name, 32, %s-%d,
output_names[koutput-connector_type], *num_dvi);
- (*num_dvi)++;
- break;
- case DRM_MODE_CONNECTOR_HDMIA:
- case DRM_MODE_CONNECTOR_HDMIB:
- snprintf(name, 32, %s-%d,
output_names[koutput-connector_type], *num_hdmi);
- (*num_hdmi)++;
- break;
- case DRM_MODE_CONNECTOR_VGA:
- case DRM_MODE_CONNECTOR_DisplayPort:
- snprintf(name, 32, %s-%d,
output_names[koutput-connector_type
[PATCH 1/3] radeon: stop caching mode resources
From: Dave Airlie airl...@redhat.com
This is step one towards MST connector hotplug support,
it stop caching the mode resources structure, and
just passes a pointer to it around.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/drmmode_display.c | 35 +++
src/drmmode_display.h | 2 +-
src/radeon_dri2.c | 2 +-
src/radeon_kms.c | 2 +-
4 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index ef5dfbe..c69abbf 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -850,7 +850,7 @@ void drmmode_crtc_hw_id(xf86CrtcPtr crtc)
}
static void
-drmmode_crtc_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, int num)
+drmmode_crtc_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, drmModeResPtr
mode_res, int num)
{
xf86CrtcPtr crtc;
drmmode_crtc_private_ptr drmmode_crtc;
@@ -860,7 +860,7 @@ drmmode_crtc_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode,
int num)
return;
drmmode_crtc = xnfcalloc(sizeof(drmmode_crtc_private_rec), 1);
- drmmode_crtc-mode_crtc = drmModeGetCrtc(drmmode-fd,
drmmode-mode_res-crtcs[num]);
+ drmmode_crtc-mode_crtc = drmModeGetCrtc(drmmode-fd,
mode_res-crtcs[num]);
drmmode_crtc-drmmode = drmmode;
crtc-driver_private = drmmode_crtc;
drmmode_crtc_hw_id(crtc);
@@ -1195,7 +1195,7 @@ const char *output_names[] = { None,
#define NUM_OUTPUT_NAMES (sizeof(output_names) / sizeof(output_names[0]))
static void
-drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, int num, int
*num_dvi, int *num_hdmi)
+drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, drmModeResPtr
mode_res, int num, int *num_dvi, int *num_hdmi)
{
RADEONInfoPtr info = RADEONPTR(pScrn);
xf86OutputPtr output;
@@ -1207,7 +1207,7 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, int num, int *num_dv
int i;
const char *s;
- koutput = drmModeGetConnector(drmmode-fd,
drmmode-mode_res-connectors[num]);
+ koutput = drmModeGetConnector(drmmode-fd, mode_res-connectors[num]);
if (!koutput)
return;
@@ -1285,7 +1285,7 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, int num, int *num_dv
goto out_free_encoders;
}
- drmmode_output-output_id = drmmode-mode_res-connectors[num];
+ drmmode_output-output_id = mode_res-connectors[num];
drmmode_output-mode_output = koutput;
drmmode_output-mode_encoders = kencoders;
drmmode_output-drmmode = drmmode;
@@ -1354,7 +1354,7 @@ uint32_t find_clones(ScrnInfoPtr scrn, xf86OutputPtr
output)
static void
-drmmode_clones_init(ScrnInfoPtr scrn, drmmode_ptr drmmode)
+drmmode_clones_init(ScrnInfoPtr scrn, drmmode_ptr drmmode, drmModeResPtr
mode_res)
{
int i, j;
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
@@ -1369,8 +1369,8 @@ drmmode_clones_init(ScrnInfoPtr scrn, drmmode_ptr drmmode)
for (j = 0; j drmmode_output-mode_output-count_encoders;
j++)
{
int k;
- for (k = 0; k drmmode-mode_res-count_encoders; k++)
{
- if (drmmode-mode_res-encoders[k] ==
drmmode_output-mode_encoders[j]-encoder_id)
+ for (k = 0; k mode_res-count_encoders; k++) {
+ if (mode_res-encoders[k] ==
drmmode_output-mode_encoders[j]-encoder_id)
drmmode_output-enc_mask |= (1 k);
}
@@ -1730,25 +1730,27 @@ drm_wakeup_handler(pointer data, int err, pointer p)
Bool drmmode_pre_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, int cpp)
{
int i, num_dvi = 0, num_hdmi = 0;
+ drmModeResPtr mode_res;
xf86CrtcConfigInit(pScrn, drmmode_xf86crtc_config_funcs);
drmmode-scrn = pScrn;
drmmode-cpp = cpp;
- drmmode-mode_res = drmModeGetResources(drmmode-fd);
- if (!drmmode-mode_res)
+ mode_res = drmModeGetResources(drmmode-fd);
+ if (!mode_res)
return FALSE;
- xf86CrtcSetSizeRange(pScrn, 320, 200, drmmode-mode_res-max_width,
drmmode-mode_res-max_height);
- for (i = 0; i drmmode-mode_res-count_crtcs; i++)
+ drmmode-count_crtcs = mode_res-count_crtcs;
+ xf86CrtcSetSizeRange(pScrn, 320, 200, mode_res-max_width,
mode_res-max_height);
+ for (i = 0; i mode_res-count_crtcs; i++)
if (!xf86IsEntityShared(pScrn-entityList[0]) ||
pScrn-confScreen-device-screen == i)
- drmmode_crtc_init(pScrn, drmmode, i);
+ drmmode_crtc_init(pScrn, drmmode, mode_res, i);
- for (i = 0; i drmmode-mode_res-count_connectors; i++)
- drmmode_output_init(pScrn, drmmode, i, num_dvi, num_hdmi);
+ for (i = 0; i mode_res-count_connectors; i
Re: Stride of 800x600 framebuffer
I am very new to DRM and radeon driver, There are many concepts of Linux graphic system I haven't acquired.I am looking help for a question about drm framebuffer, it might be very simple to you. Why is stride of 800x600 framebuffer is 832*4=3328? Actually the number of pitch 832 is derive from The hardware has certain limitations you have to confrom to, this is one of them, the framebuffer is most likely tiled, so has alignment requirements for the tiles. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: displayport detects monitoring, but monitor goes into power saving
On 5 August 2014 18:56, Glen Ogilvie n...@linuxsolutions.co.nz wrote: Hi, I've got a problem, that I'd like a little help with getting to the bottom of... so looking for a little advise. I can't get my laptop's displayport output to drive my monitor, using the free ati driver. It does work on the legacy driver, from ATI, however, that only works on X = 1.12, which is no fun to be stuck with, as no current distro ships old versions of X. I have a 27 inch dell monitor, so using HDMI is not great option, as it can't drive a high enough resolution to look sharp, as I want 2560 x 1440. I think Bug 45291 is basically the same problem, and I've updated it to include my hardware as well. I am looking for some advise, as to what I can do to help the smart graphics driver developers here get to the bottom of this.. as it's becoming a pain for me to live with a 4 year old Distro, or have to replace my laptop, which is otherwise working great for me. I've tried kernel 3.15.6, which is a great improvement, as the power management seems to work, so the GPU fan's don't run full speed the whole time, but still have the issues with displayport. So, I assume to help, I could provide xorg logs, dmesg, lspci, dmidecode.. but what else.. in all of these, no where can I see any errors, as the monitor is detected.. just no output. Trying the same monitor with hdmi, works, but the resolution is limited, as HDMI can't drive resolutions above 1920x1200 as far as I know. file a bug on bugs.freedesktop.org, and attach a boot with drm.debug=6 to start it might be possible to work it out from there. Also the monitor model etc would be good. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH] radeon: fix use-after-free in modesetting cleanup
From: Dave Airlie airl...@redhat.com
noticed while looking at something else.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/drmmode_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index fc99128..f22f198 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -966,8 +966,8 @@ drmmode_output_destroy(xf86OutputPtr output)
}
for (i = 0; i drmmode_output-mode_output-count_encoders; i++) {
drmModeFreeEncoder(drmmode_output-mode_encoders[i]);
- free(drmmode_output-mode_encoders);
}
+ free(drmmode_output-mode_encoders);
free(drmmode_output-props);
drmModeFreeConnector(drmmode_output-mode_output);
free(drmmode_output);
--
1.8.5.3
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH 1/3] radeon: fix naming clashes with multiple GPUs
On Wed, Jul 31, 2013 at 9:21 AM, alexdeuc...@gmail.com wrote: From: Alex Deucher alexander.deuc...@amd.com The compat naming code for UMS causes problems with multiple GPU as you may end up with the same output name on multiple GPUs. This may break compatibilty with certain old setups but it's necessary to properly handles multiple GPUs. I was going to suggest we just add something more to the name, like DVI-I-1-1 or GPU-1-DVI-1, but only do it for secondary GPUs. this would avoid clashes with other drivers in certain conditions as well. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH 4/4] EXA/evergreen/ni: accelerate PictOpOver with component alpha
On Tue, Jul 23, 2013 at 8:42 AM, Grigori Goronzy g...@chown.ath.cx wrote: On 23.07.2013 00:30, Dave Airlie wrote: On Mon, Jul 22, 2013 at 2:06 PM, Grigori Goronzy g...@chown.ath.cx wrote: Subpixel text rendering is typically done with a solid src and a pixmap mask. Traditionally, this cannot be accelerated in a single pass and requires two passes [1]. However, we can cheat a little with a constant blend color. The hw should be able to do things in one pass with dual source blending afaik. Yes it can do that, and this was actually my first idea. However, dual source blending requires additional render target state setup, modifications to the shaders, and so on. It's likely also a bit slower than single source blending, after all the shader needs to export twice as much data. It might be worthwhile to get back to this to accelerate some of the other PictOps with component alpha, but using the constant blend color was the easier and faster solution for the common PictOpOver case. I think it's a nice trick, I wonder if any other driver implements it? Oh yeah I'm not saying we shouldn't merge this, it looks like a great idea for this case, and is probably faster than dual source. but yeah for the other cases I suspect a single pass is going to be faster than two passes, even with the extra overheads of dual exports. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
libbacklight support for randr backlight property
xbacklight and gnome would really like to use xrandr to control the backlight if possible, I've just taken the property code from intel driver, and hooked it up to libbacklight from git://git.freedesktop.org/git/libbacklight. The kernel can't deal with this due to the insanity that is ACPI and non-ACPI backlight controls, so lets just hope this works instead! I've only tested this on my T60p ancient piece of crap, appreciate any testing anyone can give it. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 1/2] radeon: split out radeon_create_ranged_atom for now
From: Dave Airlie airl...@redhat.com
I want to use this to add randr backlight support.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/drmmode_display.c | 54 ---
1 file changed, 34 insertions(+), 20 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index cd276f3..6874ede 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -912,6 +912,33 @@ drmmode_property_ignore(drmModePropertyPtr prop)
}
static void
+radeon_create_ranged_atom(xf86OutputPtr output, Atom *atom,
+ const char *name, INT32 min, INT32 max,
+ uint64_t value, Bool immutable)
+{
+int err;
+INT32 atom_range[2];
+
+atom_range[0] = min;
+atom_range[1] = max;
+
+*atom = MakeAtom(name, strlen(name), TRUE);
+err = RRConfigureOutputProperty(output-randr_output, *atom,
+ FALSE, TRUE, immutable,
+ 2, atom_range);
+if (err != 0) {
+ xf86DrvMsg(output-scrn-scrnIndex, X_ERROR,
+ RRConfigureOutputProperty error, %d\n, err);
+}
+err = RRChangeOutputProperty(output-randr_output, *atom,
+XA_INTEGER, 32, PropModeReplace, 1, value,
FALSE, TRUE);
+if (err != 0) {
+ xf86DrvMsg(output-scrn-scrnIndex, X_ERROR,
+ RRChangeOutputProperty error, %d\n, err);
+}
+}
+
+static void
drmmode_output_create_resources(xf86OutputPtr output)
{
drmmode_output_private_ptr drmmode_output = output-driver_private;
@@ -942,30 +969,17 @@ drmmode_output_create_resources(xf86OutputPtr output)
drmmode_prop = p-mode_prop;
if (drmmode_prop-flags DRM_MODE_PROP_RANGE) {
- INT32 range[2];
- INT32 value = p-value;
-
p-num_atoms = 1;
p-atoms = calloc(p-num_atoms, sizeof(Atom));
if (!p-atoms)
continue;
- p-atoms[0] = MakeAtom(drmmode_prop-name,
strlen(drmmode_prop-name), TRUE);
- range[0] = drmmode_prop-values[0];
- range[1] = drmmode_prop-values[1];
- err = RRConfigureOutputProperty(output-randr_output, p-atoms[0],
- FALSE, TRUE,
- drmmode_prop-flags DRM_MODE_PROP_IMMUTABLE ? TRUE :
FALSE,
- 2, range);
- if (err != 0) {
- xf86DrvMsg(output-scrn-scrnIndex, X_ERROR,
- RRConfigureOutputProperty error, %d\n, err);
- }
- err = RRChangeOutputProperty(output-randr_output, p-atoms[0],
- XA_INTEGER, 32, PropModeReplace, 1, value, FALSE, TRUE);
- if (err != 0) {
- xf86DrvMsg(output-scrn-scrnIndex, X_ERROR,
- RRChangeOutputProperty error, %d\n, err);
- }
+
+ radeon_create_ranged_atom(output, p-atoms[0],
+ drmmode_prop-name,
+ drmmode_prop-values[0],
+ drmmode_prop-values[1],
+ p-value,
+ drmmode_prop-flags
DRM_MODE_PROP_IMMUTABLE ? TRUE : FALSE);
} else if (drmmode_prop-flags DRM_MODE_PROP_ENUM) {
p-num_atoms = drmmode_prop-count_enums + 1;
p-atoms = calloc(p-num_atoms, sizeof(Atom));
--
1.8.2.1
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 2/2] radeon: add libbacklight support.
From: Dave Airlie airl...@redhat.com
This adds randr BACKLIGHT and Backlight properties using libbacklight
as the backend.
Signed-off-by: Dave Airlie airl...@redhat.com
---
configure.ac | 3 +++
src/Makefile.am | 7 ++-
src/drmmode_display.c | 47 +++
src/drmmode_display.h | 9 +
4 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index b4f1d4c..b47f0b7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -81,6 +81,9 @@ PKG_CHECK_MODULES(XEXT, [xextproto = 7.0.99.1],
HAVE_XEXTPROTO_71=no)
AM_CONDITIONAL(HAVE_XEXTPROTO_71, [ test $HAVE_XEXTPROTO_71 = yes ])
+PKG_CHECK_MODULES(LIBBACKLIGHT, [libbacklight], LIBBACKLIGHT=yes;
AC_DEFINE(HAVE_LIBBACKLIGHT, 1, [libbacklight available]), [LIBBACKLIGHT=no])
+AM_CONDITIONAL(LIBBACKLIGHT, [ test $LIBBACKLIGHT = yes ])
+
AC_ARG_ENABLE([udev],
AS_HELP_STRING([--disable-udev], [Disable libudev support
[default=auto]]),
[enable_udev=$enableval],
diff --git a/src/Makefile.am b/src/Makefile.am
index 6b7171e..e777267 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -38,12 +38,17 @@ RADEON_EXA_SOURCES = radeon_exa.c r600_exa.c r6xx_accel.c
r600_textured_videofun
AM_CFLAGS = \
@LIBDRM_RADEON_CFLAGS@ \
@XORG_CFLAGS@ \
-@LIBUDEV_CFLAGS@
+@LIBUDEV_CFLAGS@ \
+ @LIBBACKLIGHT_CFLAGS@
if LIBUDEV
radeon_drv_la_LIBADD += $(LIBUDEV_LIBS)
endif
+if LIBBACKLIGHT
+radeon_drv_la_LIBADD += $(LIBBACKLIGHT_LIBS)
+endif
+
ati_drv_la_LTLIBRARIES = ati_drv.la
ati_drv_la_LDFLAGS = -module -avoid-version
ati_drv_ladir = @moduledir@/drivers
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 6874ede..629b6c3 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -50,6 +50,12 @@
#endif
#define DEFAULT_NOMINAL_FRAME_RATE 60
+#ifdef HAVE_LIBBACKLIGHT
+#define BACKLIGHT_NAME Backlight
+#define BACKLIGHT_DEPRECATED_NAME BACKLIGHT
+
+static Atom backlight_atom, backlight_deprecated_atom;
+#endif
static Bool
RADEONZaphodStringMatches(ScrnInfoPtr pScrn, const char *s, char *output_name)
@@ -876,6 +882,10 @@ drmmode_output_destroy(xf86OutputPtr output)
drmModeFreeEncoder(drmmode_output-mode_encoders[i]);
free(drmmode_output-mode_encoders);
}
+#ifdef HAVE_LIBBACKLIGHT
+ backlight_destroy(drmmode_output-backlight);
+#endif
+
free(drmmode_output-props);
drmModeFreeConnector(drmmode_output-mode_output);
free(drmmode_output);
@@ -1010,6 +1020,27 @@ drmmode_output_create_resources(xf86OutputPtr output)
}
}
}
+
+#ifdef HAVE_LIBBACKLIGHT
+{
+ RADEONInfoPtr info = RADEONPTR(output-scrn);
+ struct pci_device *dev = info-PciInfo;
+
+ drmmode_output-backlight = backlight_init(dev, 0,
mode_output-connector_type,
+ mode_output-connector_type_id);
+
+ if (drmmode_output-backlight) {
+ drmmode_output-backlight_max =
backlight_get_max_brightness(drmmode_output-backlight);
+ drmmode_output-backlight_active_level =
backlight_get_brightness(drmmode_output-backlight);
+ radeon_create_ranged_atom(output, backlight_atom,
+ BACKLIGHT_NAME, 0,
drmmode_output-backlight_max,
+ drmmode_output-backlight_active_level,
FALSE);
+ radeon_create_ranged_atom(output, backlight_deprecated_atom,
+ BACKLIGHT_DEPRECATED_NAME, 0,
drmmode_output-backlight_max,
+ drmmode_output-backlight_active_level,
FALSE);
+ }
+}
+#endif
}
static Bool
@@ -1020,6 +1051,22 @@ drmmode_output_set_property(xf86OutputPtr output, Atom
property,
drmmode_ptr drmmode = drmmode_output-drmmode;
int i;
+#ifdef HAVE_LIBBACKLIGHT
+if (property == backlight_atom || property == backlight_deprecated_atom) {
+ INT32 val;
+
+ if (value-type != XA_INTEGER || value-format != 32 ||
+ value-size != 1)
+ return FALSE;
+
+ val = *(INT32 *)value-data;
+ if (val 0 || val drmmode_output-backlight_max)
+ return FALSE;
+
+ backlight_set_brightness(drmmode_output-backlight, val);
+}
+
+#endif
for (i = 0; i drmmode_output-num_props; i++) {
drmmode_prop_ptr p = drmmode_output-props[i];
diff --git a/src/drmmode_display.h b/src/drmmode_display.h
index 2fccfda..3d24cf1 100644
--- a/src/drmmode_display.h
+++ b/src/drmmode_display.h
@@ -32,6 +32,10 @@
#include libudev.h
#endif
+#ifdef HAVE_LIBBACKLIGHT
+#include libbacklight.h
+#endif
+
#include radeon_probe.h
#ifndef DRM_CAP_TIMESTAMP_MONOTONIC
@@ -102,6 +106,11 @@ typedef struct {
drmmode_prop_ptr props;
int enc_mask;
int enc_clone_mask;
+#ifdef HAVE_LIBBACKLIGHT
+struct
Re: Problems with multiple monitors in Ubuntu 13.04
I have two 6450 cards in my Ubuntu 13.04 system with three monitors. This is a recent install with no binary drivers installed and no additional X ppa's installed. I can get X to display output on the primary monitor, and I can see all three in xrandr: Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 16384 x 16384 HDMI-0 disconnected (normal left inverted right x axis y axis) DVI-0 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm 2560x1440 60.0*+ VGA-0 disconnected (normal left inverted right x axis y axis) HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 475mm x 267mm 1920x1080 60.0*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x60075.0 60.3 640x48075.0 60.0 720x40070.1 DVI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 475mm x 267mm 1920x1080 60.0*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x60075.0 60.3 640x48075.0 60.0 720x40070.1 VGA-1 disconnected (normal left inverted right x axis y axis) The second and third monitor are on (out of power save mode) but show no input. However, XFCE seems to detect them as I have two wallpapers stacked on top of each other, one at the main monitor's 2560x1440 resolution and one at a 1920x1080 resolution (see http://edolnx-public.objects.dreamhost.com/Screenshot%20-%2005072013%20-%2009_10_02%20AM.png ). Attempting to make any changes with xrandr causes X to crash with a SIGSEGV. Here's a log: http://paste.ubuntu.com/5640585/ Any ideas? You probably need to setup an xorg.conf like you always have before for dual-card setups like that. It might be possible to make it work better if you plug two monitors into the first card and one into second, you'll be using GPU offload, so the second GPU won't be doing anything more than displaying what the first is showing. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH] radeon/man: ColorTiling2D is by default on for r6xx-cayman
Do we mention anywhere we need mesa 9.0? Dave. On Fri, Nov 2, 2012 at 10:51 PM, Alex Deucher alexdeuc...@gmail.com wrote: Pushed. thanks! On Fri, Nov 2, 2012 at 8:30 AM, Andreas Boll andreas.boll@gmail.com wrote: Signed-off-by: Andreas Boll andreas.boll@gmail.com --- man/radeon.man |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/radeon.man b/man/radeon.man index de1f6ec..55d6bb9 100644 --- a/man/radeon.man +++ b/man/radeon.man @@ -237,7 +237,7 @@ will be disabled if the drm module is too old or if the current display configur does not support it. KMS ColorTiling2D is only supported on R600 and newer chips. .br The default value is -.B off +.B on for R/RV6XX, R/RV7XX, RS780, RS880, EVERGREEN, and CAYMAN. .TP .BI Option \*qEnablePageFlip\*q \*q boolean \*q -- 1.7.10.4 ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: xf86-video-ati: Branch 'master' - 8 commits
I think you also need to prevent the acceleration code from using RADEON_GEM_DOMAIN_VRAM when these are used for the destination, or they will be migrated into VRAM anyway? Yeah probably should for completeness, we should never be rendering to a slave pixmap anyways, just copying, maybe I should just block every op except copy to them. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH xf86-video-r128] Add EXA support
On Tue, Jul 17, 2012 at 6:43 PM, Michel Dänzer mic...@daenzer.net wrote: On Mon, 2012-07-16 at 12:56 -0700, Connor Behan wrote: This introduces EXA acceleration which can improve performance and allow 2D acceleration to be used without XAA. Implemented hooks are Solid, Copy and Composite. They appear to pass all rendercheck tests, except the gradient test which XAA also fails. Tested on multiple color depths, with and without DRI, with and without the composite extension. Hardware cursor, Xvideo and page flipping are supported as well. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=47866 This patch breaks r128 build, look at tinderbox.x.org for results. But since XAA removal, info-accel isn't there, but this patch also sets info-accel = FALSE, which is totally wrong, it should at least be info-accel = NULL, surrounded by #ifdef HAVE_XAA_H Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: dropping UMS - xf86-video-ati-7.0.0
On Fri, Jun 15, 2012 at 9:35 AM, Michel Dänzer mic...@daenzer.net wrote: On Don, 2012-06-14 at 20:19 +0100, Dave Airlie wrote: I'm seriously thinking of resurrecting the kms killing branch, I'm not opposed, it's becoming rather painful to keep UMS building, let alone working. can anyone give me a reason not too, Not sure a reason is enough, someone would need to step up and take care of UMS vs. ongoing development. we'd fork the current master into a UMS branch and move on. Sounds good. Might even allow cleaning up the UMS code as well for someone so inclined. Okay I've pushed a branch kms-only to the master repo I've only build tested it, now for the fun bit. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: dropping UMS - xf86-video-ati-7.0.0
On Fri, Jun 15, 2012 at 3:53 PM, Roland Scheidegger rscheidegger_li...@hispeed.ch wrote: Am 14.06.2012 21:19, schrieb Dave Airlie: I'm seriously thinking of resurrecting the kms killing branch, can anyone give me a reason not too, we'd fork the current master into a UMS branch and move on. Aren't there still some OS using this driver but not supporting kms? Though I guess it doesn't actually matter for them if they need to use the ums branch instead... Otherwise sounds good to me. There hasn't been anything new in UMS world really in 2-3 years, I'd rather split it off and let those who care about it deal with it, a lot of changes have broken UMS recently. So far its also 61k loc less to worry about, along with reducing the complexity of the macros and spaghetti useEXA, XAA code. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
dropping UMS - xf86-video-ati-7.0.0
I'm seriously thinking of resurrecting the kms killing branch, can anyone give me a reason not too, we'd fork the current master into a UMS branch and move on. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
radeontool 1.6.3
I've dropped a radeontool release in http://people.freedesktop.org/~airlied/radeontool/ changes below: Alex Deucher (3): add latest chip families from the ddx add radeonreg program radeonreg: add radeonreg regs all option Dave Airlie (4): evergreen : more regs radeontool: update pci ids radeontool: add support for parsing OF ibm,* setup tables update version Jonathan Nieder (12): avoid -Wformat-security warnings teach fatal() to write newline avivotool: make card detection and mapping errors non-fatal avivotool, radeonreg: make fatal errors exit use continue statement to simplify for each PCI device loop avivotool, radeonreg: completely skip early cards with --skip exit for each PCI device loop as soon as Radeon device is found radeontool, avivotool: remove unnecessary region autodetection magic switch to modern pci_device_map_range API include errno string in more messages radeontool: document functions that require mapped control region radeontool: make card detection and mapping errors non-fatal Rafał Miłecki (6): avivotool: allow reading regs from given range avivotool: allow reading basic audio info on Evergreen avivotool: allow reading HDMI related regs on R600 avivotool: dump current audio state on Evergreen avivotool: dump enabled HDMI blocks on Evergreen avivotool: dump whole HDMI block on Evergreen Tormod Volden (2): radeontool: add missing newline to error message prefix fatal error messages with fatal error: ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH/RFC v2 0/10] Re: avivotool: error out unless there is exactly one control and fb region
2012/3/9 Rafał Miłecki zaj...@gmail.com: W dniu 28 lutego 2012 07:13 użytkownik Rafał Miłecki zaj...@gmail.com napisał: 2012/2/25 Jonathan Nieder jrnie...@gmail.com: Alex Deucher wrote: region 0 is always the frame buffer and region 2 is always mmio. radeontool and avivotool should be cleaned up the same way radeonreg is. Thanks, makes perfect sense. Here's a reroll that does that. The motivation is still patches 7 (libpciaccess API churn) and 10 (unfriendly behavior when run as non-root). The rest of the patches are cleanups or small potential improvements noticed in the process of writing those two. Still untested, since my radeon is still temporarily out of commission. Compiles at least. :) Seems to work on my RV620. I can still read and write regs, values look alright. Dave: have you received this patchset? Should we push this? I'm considering creating one more patch for avivotool, maybe you could consider making a new release in some next future? I've pushed all of these out, not really watching this list enough. If you have another patch let me know and I can make a 1.7 release. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH] radeon: r200 depth buffers are always tiled
On Mon, Dec 5, 2011 at 9:13 PM, Roland Scheidegger rscheidegger_li...@hispeed.ch wrote: Am 05.12.2011 21:51, schrieb Dave Airlie: On Mon, Dec 5, 2011 at 8:08 PM, Roland Scheidegger rscheidegger_li...@hispeed.ch wrote: IIRC this is not only true for r200. Might be true for r300 too, and r100 (possibly not rv100) even. Looks good otherwise though. Yeah I've been trying to solve it as I find it, I found it definitely on rv250/rv280, r200 I'm not 100% sure on but will check that. my rv100 definitely doesn't need it, but I don't have simple access to an rv200 or r100 yet, might be able to get an M7 tomorrow. Good point for r300-r500 should probably check that, but we should be enabling tiling on those by default anyways. I think it might be always tiled for anything below r600 except the rv100 (and the igp-based rv100s). Of course, with different tiling patterns. I'm not 100% sure though, but I remember some differences there between r100 and rv100 (it is possible though just the tiling pattern was different). Okay so I've tested now on an M7 laptop, and it has always tiled depth, r200, rv250 and rv280 are always tiled, and my rv100 has never tiled. The code in mesa now passes readPixSanity on all the ancient crap^Wradeons I can beg or borrow access to. In theory color tiling should also work fine enabled, and it seems to, not seeing and piglit regressions apart from noise between tiled/untiled runs. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH] radeon: r200 depth buffers are always tiled
From: Dave Airlie airl...@redhat.com
When we do the allocations we need to make sure the always tiled
nature is taken into account.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/radeon.h |1 +
src/radeon_dri2.c |8
src/radeon_exa.c |3 +++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/radeon.h b/src/radeon.h
index 34f6f53..91c7b62 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -1667,6 +1667,7 @@ static __inline__ int radeon_timedout(const struct
timeval *endtime)
enum {
RADEON_CREATE_PIXMAP_TILING_MACRO = 0x1000,
RADEON_CREATE_PIXMAP_TILING_MICRO = 0x2000,
+RADEON_CREATE_PIXMAP_DEPTH = 0x4000, /* for r200 */
};
#endif /* _RADEON_H_ */
diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index 8789d73..9fd3658 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -121,6 +121,8 @@ radeon_dri2_create_buffers(DrawablePtr drawable,
flags = RADEON_CREATE_PIXMAP_TILING_MICRO;
else
flags = RADEON_CREATE_PIXMAP_TILING_MACRO |
RADEON_CREATE_PIXMAP_TILING_MICRO;
+ if (IS_R200_3D)
+ flags |= RADEON_CREATE_PIXMAP_DEPTH;
break;
case DRI2BufferDepthStencil:
if (info-ChipFamily = CHIP_FAMILY_R600) {
@@ -132,6 +134,8 @@ radeon_dri2_create_buffers(DrawablePtr drawable,
need_enlarge = 1;
} else
flags = RADEON_CREATE_PIXMAP_TILING_MACRO |
RADEON_CREATE_PIXMAP_TILING_MICRO;
+ if (IS_R200_3D)
+ flags |= RADEON_CREATE_PIXMAP_DEPTH;
break;
case DRI2BufferBackLeft:
case DRI2BufferBackRight:
@@ -271,6 +275,8 @@ radeon_dri2_create_buffer(DrawablePtr drawable,
flags = RADEON_CREATE_PIXMAP_TILING_MICRO;
else
flags = RADEON_CREATE_PIXMAP_TILING_MACRO |
RADEON_CREATE_PIXMAP_TILING_MICRO;
+ if (IS_R200_3D)
+ flags |= RADEON_CREATE_PIXMAP_DEPTH;
break;
case DRI2BufferDepthStencil:
/* macro is the preferred setting, but the 2D detiling for software
@@ -282,6 +288,8 @@ radeon_dri2_create_buffer(DrawablePtr drawable,
need_enlarge = 1;
} else
flags = RADEON_CREATE_PIXMAP_TILING_MACRO |
RADEON_CREATE_PIXMAP_TILING_MICRO;
+ if (IS_R200_3D)
+ flags |= RADEON_CREATE_PIXMAP_DEPTH;
break;
case DRI2BufferBackLeft:
case DRI2BufferBackRight:
diff --git a/src/radeon_exa.c b/src/radeon_exa.c
index f3daec0..95646ab 100644
--- a/src/radeon_exa.c
+++ b/src/radeon_exa.c
@@ -473,6 +473,9 @@ void *RADEONEXACreatePixmap2(ScreenPtr pScreen, int width,
int height,
if (usage_hint RADEON_CREATE_PIXMAP_TILING_MICRO)
tiling |= RADEON_TILING_MICRO;
}
+ if ((usage_hint RADEON_CREATE_PIXMAP_DEPTH) IS_R200_3D)
+ tiling |= RADEON_TILING_MACRO | RADEON_TILING_MICRO;
+
}
/* Small pixmaps must not be macrotiled on R300, hw cannot sample them
--
1.7.6.4
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH] radeon: r200 depth buffers are always tiled
On Mon, Dec 5, 2011 at 8:08 PM, Roland Scheidegger rscheidegger_li...@hispeed.ch wrote: IIRC this is not only true for r200. Might be true for r300 too, and r100 (possibly not rv100) even. Looks good otherwise though. Yeah I've been trying to solve it as I find it, I found it definitely on rv250/rv280, r200 I'm not 100% sure on but will check that. my rv100 definitely doesn't need it, but I don't have simple access to an rv200 or r100 yet, might be able to get an M7 tomorrow. Good point for r300-r500 should probably check that, but we should be enabling tiling on those by default anyways. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH 2/5] Disable DRI by default on IA64.
On Fri, Nov 4, 2011 at 3:42 PM, Johannes Obermayr
johannesoberm...@gmx.de wrote:
See: https://bugzilla.novell.com/show_bug.cgi?id=437651
---
You are not authorized to access bug #437651.
Open the bug or fix the commit msg :)
Dave.
src/radeon_driver.c | 5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/radeon_driver.c b/src/radeon_driver.c
index 293897a..2cfe36a 100644
--- a/src/radeon_driver.c
+++ b/src/radeon_driver.c
@@ -2387,8 +2387,11 @@ static Bool RADEONPreInitDRI(ScrnInfoPtr pScrn)
return FALSE;
}
}
-
+#if !defined (__ia64__)
if (!xf86ReturnOptValBool(info-Options, OPTION_DRI, TRUE)) {
+#else
+ if (!xf86ReturnOptValBool(info-Options, OPTION_DRI, FALSE)) {
+#endif
xf86DrvMsg(pScrn-scrnIndex, X_INFO,
Direct rendering forced off\n);
return FALSE;
--
1.7.7
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH 3/5] Fix https://bugzilla.novell.com/show_bug.cgi?id=474071.
Same problem, bug isn't public. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [Help][RS780E][mipsel]Screen corruption sometimes
2011/8/8 Chen Jie ch...@lemote.com: Hi, 在 2011年8月7日 下午4:35，Chen Jie ch...@lemote.com 写道： 2011/8/4 Michel Dänzer mic...@daenzer.net: You can try booting with radeon.test=1 and see in dmesg if the transfer tests triggered by that succeed. Seems has some test failure, see attachment radeon.test.log I did the same test on a x86 machine with RS780E, running ubuntu 10.10(linux 2.6.35), BO move testing reports no error. Maybe some arch-depend problems? You might want to try some of 3.1-rc1 kernel drm radeon code, Ben Herrenschmidt did a bunch of powerpc fixes that might be required on MIPS. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Two mouse/display problems on Evergreen
On Sat, Dec 11, 2010 at 4:40 AM, Bruce Guenter br...@untroubled.org wrote: Hi. I'm having a problem with my X system after replacing my video card. The mouse and display freeze for about 1/10th of a second every roughly 10 seconds when moving the mouse. When the mouse is not moving, no freezes are observed. I have been using glxgears as a simple program to show the freezes, and the glitches visible in its movements are consistent with the mouse motion pauses. As well, when the pauses happen, the FPS reported by glxgears consistently drop by about 3-4%. The same stalls are observed when no GL applications are running, and I am not using a compositing window manager. Sounds like output polling but I can't see why you'd be getting it on that card. echo 0 /sys/module/drm_kms_helper/parameters/poll Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Bug#591061: Leak still present.
Proposed patch to remove leak attached.
Dave.
On Tue, Sep 28, 2010 at 6:42 PM, Eduardo I. persegui...@gmail.com wrote:
Hi Cyril, thanks for the heads up.
Unfortunately I still seem to be able to leak memory in the exact same
way. I'm reporting this back at RH's bugzilla.
I'm attaching ttm/drm related entries in vmallocinfo just in case.
--
Eduardo.
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
From 086970d5b8371bc38d25bfc9b3a59328bce7a6f9 Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@redhat.com
Date: Wed, 29 Sep 2010 13:31:07 +1000
Subject: [PATCH] drm/ttm: remove race and optimise evicting destroyed buffers.
A race condition was identifed that led to a leak of the BOs, when
a bo was on the delayed delete list and was selected for eviction,
the code would enter
thread 1 (evict) -- thread2 (dd)
bo added to delayed destroy list
take lru lock
ttm_mem_evict_first called
- reserve locked
- remove from lru
- drop lru lock
take lru lock
try del from lru - get put_count == 0
try to reserve locked
- drop lru lock to wait unreserved
call bo_evict
unreserve buffer
- take lru lock
- add back to lru
- unreserver
- drop lru lock
take lru lock due to unreserved
unbind ttm
drop put_count references (which is 0)
despite being on the lru/swap lru lists.
leak due to never losing reference
The obvious quick fix is to try the bo from the ddestroy list if we
are going to evict it, however if we are going to evict a buffer that
is going to be destroyed we should just destroy it instead, its more
likely to be a lighter-weight operation than evict + delayed destroy.
This patch check is a bo that we are about to evict is actually on the
destroy list and if it is, it unreserves it (without adding to lru),
and cleans up its references. It should then get destroyed via
normal ref counting means.
proposed fix for:
https://bugzilla.redhat.com/show_bug.cgi?id=615505
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591061
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index cb4cf7e..60689b1 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -689,7 +689,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
struct ttm_mem_type_manager *man = bdev-man[mem_type];
struct ttm_buffer_object *bo;
int ret, put_count = 0;
-
+ bool destroy = false;
retry:
spin_lock(glob-lru_lock);
if (list_empty(man-lru)) {
@@ -719,6 +719,13 @@ retry:
}
put_count = ttm_bo_del_from_lru(bo);
+
+ /* is the buffer currently on the delayed destroy list? */
+ if (!list_empty(bo-ddestroy)) {
+ list_del_init(bo-ddestroy);
+ destroy = true;
+ put_count++;
+ }
spin_unlock(glob-lru_lock);
BUG_ON(ret != 0);
@@ -726,8 +733,13 @@ retry:
while (put_count--)
kref_put(bo-list_kref, ttm_bo_ref_bug);
- ret = ttm_bo_evict(bo, interruptible, no_wait_reserve, no_wait_gpu);
- ttm_bo_unreserve(bo);
+ if (destroy) {
+ atomic_set(bo-reserved, 0);
+ ret = ttm_bo_cleanup_refs(bo, !no_wait_gpu);
+ } else {
+ ret = ttm_bo_evict(bo, interruptible, no_wait_reserve, no_wait_gpu);
+ ttm_bo_unreserve(bo);
+ }
kref_put(bo-list_kref, ttm_bo_release_list);
return ret;
--
1.7.2.3
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Eyefinity support
On Mon, Sep 20, 2010 at 8:36 AM, Felix Blanke felixbla...@gmail.com wrote: Yeah. I have buyed a third monitor and now need a video card for it :) I want to buy a HD 5770 (flex-edition from sapphire) to use 3 monitors via DVI. Open-source would be mutch nicer to use then the closed source driver :) Only if you use active displayport-dvi convertors. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH] dri2: Reference count DRI2 buffers
2010/8/21 Oldřich Jedlička oldium@seznam.cz: On Friday 20 August 2010 11:05:40 Christopher James Halse Rogers wrote: On Fri, 2010-08-20 at 07:55 +0200, Oldřich Jedlička wrote: On Friday 20 August 2010 02:04:35 Christopher James Halse Rogers wrote: On Thu, 2010-08-19 at 21:23 +0200, Oldřich Jedlička wrote: On Thursday 19 August 2010 10:57:21 Christopher James Halse Rogers wrote: When a client calls ScheduleSwap we set up a kernel callback when the relevent vblank event occurs. However, it's possible for the client to go away between calling ScheduleSwap and the vblank event, resulting in the buffers being destroyed before they're passed to radeon_dri2_frame_event_handler. I was also thinking about the solution and did some xorg-server investigation. Personally I don't like comparing pointer values (ClientPtr), because it could be the same - sequence malloc/free/malloc could return the same pointer value. Yeah, there is a chance that a stray DRI2_SwapBuffersComplete event could be written to an uninterested client. It certainly won't try to write to an invalid client, though, so it shouldn't crash X. And it is reasonably unlikely that a client will go away and a new client will both fill the same slot *and* get the same memory address - there's a lot of memory allocation going on in the surrounding code. Question is if the client can handle this :-) Here are two other possible solutions: 1. Add a uniqueId (increasing number with each client) to ClientRec. Then you can compare something really unique. On the other hand this needs change in xorg-server. 2. Use AddCallback(ClientStateCallback, our_client_state_changed_method, 0) during driver initialization to detect that any client went away and invalidate its events (add field valid in event). That would be even better than solution 1 - no change of xorg-server is needed. Each client could have private data too - double-linked list of pending events - registered with dixRegisterPrivateKey(). The event would be removed from the list only when it is valid (otherwise the prev/next list pointers would be invalid too). Invalid events would be ignored in the handler, they would be only freed. I thought about that, too. It seemed a bit excessive for the driver to maintain a list of clients as they come and go just for the purpose of not sending an event when a client quits. There is no need to have a list of clients. Each client would have the list of events kept in the client's devPrivate area (registered with dixRegisterPrivateKey, found by dixLookupPrivate) - ony the event list head is necessary: 1. The event would have prev and next pointers for the purposes of the list and a new valid boolean field. 2. Register Client State callback by the call to AddCallback and call dixRegisterPrivateKey in the driver initialization routine. Add RemoveCallback in the driver shut-down routine. 3. Whenever new client connects, the list head would be set to 0 (done in the Client State callback). This step is probably unnecessary if the area is set to 0 via calloc (I'm just not sure). 4. Whenever the new event is created, dixLookupPrivate would get the client's list head and the new event would be added to the list head. 5. Whenever the client dies (recognized in the Client State callback), the list would be walked-through and events invalidated (valid=false). 6. For valid events (valid==true) on event callback the event would be removed from the list (just modify the event's prev's next and event's next's prev pointers, eventually modifying the client's list head). 7. For invalid events (valid==false) the list would stay unmodified (because of the list head modification on freed client's memory), only the event would be freed. This looks to me like a few lines of code for each point, nothing big. Ah, right. That's the reverse of what I was thinking; it's more reasonable. It still seems a bit heavyweight to me for this corner case. Yeah, looks so. I think it is now the ATI driver developpers turn to say what they want - if your patch is good or needs enhancing. The pointer comparison is quick, cheap, and ensures we won't crash X. Yes, that should work most of the time :-) But this might add some hard-to- reproduce problem with client getting unwanted message. Personally I like solution 2, because it fully uses xorg-server facilities. But I don't know if this isn't too much or if there exists a simpler solution. I think that there should actually be solution 3: the DRI2 extension handles this for drivers as a part of the swapbuffers/waitmsc common code. Yes, definitely. But it looks like the driver is currently scheduling the event (and holding wrong data - ClientPtr) and handling it, only
Re: Debian bugs: 588601, 588602: xpress 200m 5955 = resume from suspend fails with KMS enabled
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=580b4fffbbdc3c899ee1f8189ba321bd60b48840 I added this qurik upstream, it may need to be extended to other rs4xx, its worth a try. Dave. On Sat, Jul 10, 2010 at 4:13 PM, Andres Cimmarusti andrescimmaru...@yahoo.com wrote: I dedicated a large portion of the day to finding a clue to this one. Following this advice: http://lxr.linux.no/#linux+v2.6.34.1/Documentation/power/s2ram.txt I was able to extract a trace from the failed resume process: Magic number: 0:981:799 hash matches drivers/base/power/main.c:523 pci :01:05.0: hash matches ec PNP0C09:00: hash matches The first hash match is none other than my ATI Radeon card as I easily verified with lspci: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon XPRESS 200M 5955 (PCIE) However, the above link says that the likely culprit in the failed resume process is the last hash match. This corresponds to the EC driver: http://lxr.free-electrons.com/source/drivers/acpi/ec.c My card was, till recently, listed under embedded graphics at the AMD/ATI website. So there appears to be some conflict when using KMS between radeon and ec that causes the kernel to hang (that explains why I can't ssh into my computer to get a trace). For this reason I've cloned the original bug and reported the copy as a kernel bug. I will try to delve deeper into the matter by activating more verbose debugging symbols for acpi. I would appreciate some advice and guidance, since I'm flying half-blind (I will try to follow the information present here http://ubuntuforums.org/showthread.php?t=505890) Cheers, Andres ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[ANNOUNCE] xf86-video-ati 6.13.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stable release of xf86-video-ati for the 6.13.x series. Main features: server 1.9 support, evergreen accel disabled explicitly, kms uevent + sync support, rn50 fixes, enable color tiling on kms on r300-r500. xv cleanup and large vertex number fixes. Alex Deucher (35): change version post release radeon: don't setup Xv on rn50 radeon: add some new pci ids Xv overlay: set scalerwidth to 1920 on r3xx/r4xx chips atom: disable TV encoder when VGA is in use radeon: add support for pll algo selection radeon/kms: fix crash when using more than two heads radeon/kms: fix possible crtc mask for evergreen Xv: track vtx_count, is_planar in port priv r1xx textured video: split into prepare and draw functions r2xx textured video: split into prepare and draw functions r3xx textured video: split into prepare and draw functions r5xx textured video: split into prepare and draw functions r1xx texvid: deal with large numbers of verts r2xx texvid: deal with large numbers of verts r3xx texvid: deal with large numbers of verts r5xx texvid: deal with large numbers of verts r3xx-r5xx: fix vertex units r3xx: fix gb pipe setup for SE cards radeon: fix pll_out_min default for pre-avivo r1xx/r2xx EXA: handle RepeatNone properly with transforms r2xx exa: fix typo in 27c3326863deae36bc35e2c3b73fffd400208ff1 dri2: use radeon_pick_best_crtc() evergreen: explicitly disable accel on evergreen radeon: fix rn50 cloning with kms r6xx/r7xx accel: remove some duplicate emits and minor clean up r6xx/r7xx: reorg default and clipping state emit r6xx/r7xx: remove unnecessary state emit r3xx-r5xx Xv: disable bicubic filtering by default radeon: fix depth 16 with ums r6xx/r7xx: macro safety fixes r6xx/r7xx accel: add back some additional default state r6xx/r7xx: fix miscount in state emit r6xx shader: use ADDR() for CF_DWORD0 remove rv100 quirk Cooper Yuan (1): Remove HDP_SOFT_RESET function, there is no need to reset HDP block. Dave Airlie (8): kms: add uevent support. radeon: add FireMV 2400 pci id. xv: fix Xv on M6/RV100 under KMS. drmmode: fix big endian issue with properties. radeon: set proper stride for cursor in tiling flags. radeon: fixup last fix, use CURSOR_WIDTH not RADEON_CURSOR_WIDTH. radeon: fix support for 1.9 server master. set version for release Gaetan Nadon (1): COPYING: replace stub file with actual copyright notices Jerome Glisse (1): kms: add support for the MSC swap sync API Marek Olšák (3): r3xx-r5xx: fix texturing with small macrotiled pixmaps rs740: follow macro-switch too r3xx-r5xx: enable color tiling by default on KMS Michel Dänzer (3): FB/MMIO_cnt should be ints, not pointers. Convert x(c)alloc/xfree to m/calloc/free. DRI2: Fix up confusion between windows and pixmaps. Owain Ainsworth (1): Reference count shared driver mappings. Owain G. Ainsworth (3): Remove remnants of the ShowCache option. Kill per-context SAREA support. Make consistent use of fbOffset and share fb mappings. Wolfram (1): r6xx/r7xx: fix ums cmd buffer leak git tag: xf86-video-ati-6.13.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.13.1.tar.bz2 MD5: d65ae11cc66146c7006dbf5acebde413 xf86-video-ati-6.13.1.tar.bz2 SHA1: 74a8e647e3149af0b1eb1baf58ef1b69b44f0228 xf86-video-ati-6.13.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.13.1.tar.gz MD5: 7f76bb3503eebe328a48733fa22ae7a8 xf86-video-ati-6.13.1.tar.gz SHA1: 913f9c15e53e7aed32aa8ec5d265875892932879 xf86-video-ati-6.13.1.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkwz0aAACgkQ6acWQe8WxxrhPwCeMJ9Y00/THlaKSkAOpG04rIR6 d+0AoKee2Crf5Bk1i9YNi9YczCseom5X =Vzhn -END PGP SIGNATURE- ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
radeon-vbos branch
I've just pushed a branch with a patch in it to use VBOs for vertex data on r300-r500 GPUs. This should provide a benefit due to the vertex data no longer having to be copied to the GPU in-kernel, and also allowing more state to be in a single indirect buffer. It is only enabled under KMS. It needs a bit more testing before I push it to master, in theory r100 and r200 could be ported to use the code as well. On my rv370 Lenovo T43 laptop, this gets x11perf aa10text from 320 reps @ 0.0020 msec (507000.0/sec): Char in 80-char aa line (Charter 10) to 320 reps @ 0.0018 msec (546000.0/sec): Char in 80-char aa line (Charter 10) Thats a fairly lowly by today's standards Pentium-M 1.8. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Error in rs400_gart_adjust_size
On Sun, Apr 25, 2010 at 11:58 PM, Jerome Glisse gli...@freedesktop.org wrote: On Sat, Apr 24, 2010 at 02:17:50PM +0200, Daniel Klaffenbach wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I noticed a strange line in dmesg when KMS is enabled and I wondered how to get rid of it: [drm:rs400_gart_adjust_size] *ERROR* Forcing to 32M GART size (because of ASIC bug ?) KMS is very unstable for me and I feel like this error could be a reason. This is the device in question: We have to play somemore with X200M but i think we had issue with GART size bigger than 32M in the past, i am adding that to my todo list. I will keep you posted. from memory it was rs480+4GB RAM where the issue arose. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: HD5770 bringup
On Sun, Apr 11, 2010 at 6:00 AM, Mark Knecht markkne...@gmail.com wrote: OK, so I'm searching around for instructions on doing right this but I'm not finding them yet. That's leaving me poking around and of course that never goes well. I'll post some data and keep some records in case others try this again later. I don't want to post here too much and wear out my welcome but I really want to see a desktop today if possible. Don't use radeonhd, use -ati or radeon (same thing) Also get a really recent kernel with evergreen support for KMS, the UMS support isn't great and will probbaby remain sub-par. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH] Mark highly predictable branches as likely/unlikely
On Wed, 2010-04-07 at 19:25 -0400, Matt Turner wrote: On Wed, Apr 7, 2010 at 7:15 PM, Dave Airlie airl...@redhat.com wrote: On Wed, 2010-04-07 at 18:49 -0400, Matt Turner wrote: Highly predicatble branches include - unlikely: error conditions, such as those leading to - RADEON_FALLBACK - goto fail - return FALSE (as an error - likely: if (info-useEXA) Can we limit these to fastpaths? i.e. no need in atombios or drmmode code or anywhere like that. I expect you just want it in the accel/exa/xv codepaths. Dave. Sure. I can strip out the others and resend if you'd like, or you could just commit the parts you think are appropriate. I don't imagine there would be any ill effects from including the patch for files like src/atombios_output.c|2 +- src/drmmode_display.c|6 +- though. This wasn't a blind find'n'replace, so the ones included should be pretty good. Its more for our sanity, and future maintainance cost. likely/unlikely isn't worth the effort, also these have to be maintained going forward, in case some path becomes more likely or unlikely. The kernel has a real problem using these in the wrong places and I'd hate for it to spread. like when the standard code was for kfree was if (ptr) kfree(ptr) and kfree contains an if (unlikely(!ptr)), then someone removed all the if (ptr) and it suddenly became a lot more likely. Dave. Thanks, Matt ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: R600, S-Video TV out for PAL, and horizontal rolling
Not sure it ever worked I think I remembered seeing something similiar last time I tried PAL I just haven't had time to get back to it. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: ATI 6.12.4 on ultraSparc runs slow
On Thu, Mar 25, 2010 at 8:05 AM, Alex Deucher alexdeuc...@gmail.com wrote: 2010/3/24 jean-francois simon jfsimonc...@gmail.com: 2010/3/24 Michel Dänzer mic...@daenzer.net so it is PIO not DMA? just curious, where is the code that is doing that transfer? shadowUpdatePacked() in xserver/miext/shadow/shpacked.c . very interesting thanks. i can see that this transfer is being triggered by something called the shadow block handler. and i am thinking maybe this is not done often enough, thus explaning the slow videos? More likely the write to vram performance is better on x86 since you are using write combining. Yes definitely this, most non-x86 CPUs don't have mtrr/write combining support, which really helps for shadowfb situations. The only thing I can think to do is possible some sparc specific optimisations to the copying that may or may not speed it up. I know Linux/sparc has mostly working DRM, since davem plays quake3 on his. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: ATI Rage Mobility P/M - Mach64 kernel module source - is it available anywhere?
I found a couple of well-documented posts relative to this issue, which indicate that the source was recently removed from the mesa/drm tree at anongit.freedesktop.org and is now available in the kernel tree under drivers/gpu/drm directory. Its still not upstream, we'd need to clean the code up from the libdrm (its in the version control just not in master, you need to back a few tags) The code would need to be ported to the kernel (maybe in staging) then make to pass checkpatch.pl Dave. Since I did no see anything with a file name such as mach64.c in this directory, I was wondering if the source was available anywhere at this point in time, and if not, if there are any plans to reinstate it. Thanks, CJ ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Radeon : Exclude some memory zone
2010/1/11 Jerome Glisse gli...@freedesktop.org: On Sun, Jan 10, 2010 at 07:06:41PM +0100, José JORGE wrote: A Segunda 04 Janeiro 2010 23:46:32 José JORGE você escreveu: The question : is it possible by myself to change the radeon driver to ignore a memory zone of a video card? Something like the badram patch for linux kernel? Just if someone had the time to answer simply forget it, or maybe done with lots of work, I'd thank him... It's doable, i think best way would be to allocate a serie of BO covering the damaged area using the new ttm allocator which allow to specify addr of BO. Then you need to pin all those BO. Maybe the trickier part is to design the commandline argument to allow such thing. Most GPU memory is interleaved so if one chip is broken you can't just ignore it linearly, its probably possible to reconfigure the memory controller but I can't imaging a 256-bit memory bus working at 192-bit so well, and you'd lose more than one RAM chip. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: RV710 much slower on kms
On Sat, Dec 26, 2009 at 2:54 AM, Dr. David Alan Gilbert d...@treblig.org wrote: Hi, I'm running an RV710 on 2.6.33-rc2 and it works great without KMS; but with KMS it's a lot slower and I can see X eating a lot of CPU even when not much is happening. It seems to start off OK, but then really starts eating it - I've seen X eating ~80% of one core running a simple flash game, and even saw the system when apparently idle eating over 50% of one core (but that stopped after reboot). The CPU is an i7-860. The time in that last idle case all seems to be userspace time, strace'ing X shows it was doing a lot of ioctl's to the DRI. I'm running X 1.6.5 (I'm using the Ubuntu xorg-edgers packages for everything other than the kernel; I'm on Ubuntu 9.10 as the base system). I've included two xorg.0.log's; one with kms and one without. If you need any other debug, just ask. Get a new X server really is the answer, 1.7.x has improved EXA mainly to deal with kms drivers. radeon KMS on pre-1.7 servers isn't something I'd forsee a distro wanting to ship. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Releases question
2009/12/17 Tomáš Chvátal scarab...@gentoo.org: Hi, I would like to ask you to start considering creating some rc/beta/alpha snapshot of upcoming driver series 6.13 (or what ever you decide to call it). There are quite few users trying to test the KMS features and i was pointing them out to our live package for ATI drivers, but i think it might be more convinient to provide some snapshot for them (commits fixing the KMS behaviour in the driver itself are not so common lately so it might be possible). We might have an ABI break on libdrm_radeon to make it maintainable which would make having any sort of released tarball a pain. when we move the kernel driver out of staging it should all trickle down. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH] radeon: avoid using hw pixmaps when we have little VRAM.
From: Dave Airlie airl...@redhat.com
This patch returns NULL for pixmap creation when we are using
mixed pixmaps and the pixmap has a size.
The size check is necessary for the front buffer.
We add a flag to force pixmap creation for certain pixmaps
that need to be hw, like the DRI2 and Xv ones.
Idea from Michel and workarounds from Ben Skeggs.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/radeon.h|1 +
src/radeon_dri2.c |8
src/radeon_exa.c| 12 +++-
src/radeon_textured_video.c |2 ++
4 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/src/radeon.h b/src/radeon.h
index 5cdc3db..c959c56 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -888,6 +888,7 @@ typedef struct {
Bool accelOn;
Bool useEXA;
#ifdef USE_EXA
+Bool exa_force_create;
XF86ModReqInfoexaReq;
#endif
#ifdef USE_XAA
diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index db46d27..56c00a3 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -65,6 +65,8 @@ radeon_dri2_create_buffers(DrawablePtr drawable,
int count)
{
ScreenPtr pScreen = drawable-pScreen;
+ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
+RADEONInfoPtr info = RADEONPTR(pScrn);
BufferPtr buffers;
struct dri2_buffer_priv *privates;
PixmapPtr pixmap, depth_pixmap;
@@ -120,7 +122,9 @@ radeon_dri2_create_buffers(DrawablePtr drawable,
if (attachments[i] == DRI2BufferDepth) {
depth_pixmap = pixmap;
}
+ info-exa_force_create = TRUE;
exaMoveInPixmap(pixmap);
+ info-exa_force_create = FALSE;
driver_priv = exaGetPixmapDriverPrivate(pixmap);
r = radeon_gem_get_kernel_name(driver_priv-bo, buffers[i].name);
if (r)
@@ -143,6 +147,8 @@ radeon_dri2_create_buffer(DrawablePtr drawable,
unsigned int format)
{
ScreenPtr pScreen = drawable-pScreen;
+ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
+RADEONInfoPtr info = RADEONPTR(pScrn);
BufferPtr buffers;
struct dri2_buffer_priv *privates;
PixmapPtr pixmap, depth_pixmap;
@@ -198,7 +204,9 @@ radeon_dri2_create_buffer(DrawablePtr drawable,
if (attachment == DRI2BufferDepth) {
depth_pixmap = pixmap;
}
+info-exa_force_create = TRUE;
exaMoveInPixmap(pixmap);
+info-exa_force_create = FALSE;
driver_priv = exaGetPixmapDriverPrivate(pixmap);
r = radeon_gem_get_kernel_name(driver_priv-bo, buffers-name);
if (r)
diff --git a/src/radeon_exa.c b/src/radeon_exa.c
index 99a93a4..a985624 100644
--- a/src/radeon_exa.c
+++ b/src/radeon_exa.c
@@ -391,6 +391,11 @@ void *RADEONEXACreatePixmap(ScreenPtr pScreen, int size,
int align)
RADEONInfoPtr info = RADEONPTR(pScrn);
struct radeon_exa_pixmap_priv *new_priv;
+if (info-accel_state-exa-flags EXA_MIXED_PIXMAPS) {
+if (size != 0 !info-exa_force_create info-vram_size =
(32*1024*1024))
+return NULL;
+}
+
new_priv = xcalloc(1, sizeof(struct radeon_exa_pixmap_priv));
if (!new_priv)
return NULL;
@@ -421,7 +426,12 @@ void *RADEONEXACreatePixmap2(ScreenPtr pScreen, int width,
int height,
uint32_t size;
uint32_t tiling = 0;
int pixmap_align = 0;
-
+
+if (info-accel_state-exa-flags EXA_MIXED_PIXMAPS) {
+if (width != 0 height != 0 !info-exa_force_create
info-vram_size = (32*1024*1024))
+return NULL;
+}
+
if (usage_hint) {
if (info-allowColorTiling) {
if (usage_hint RADEON_CREATE_PIXMAP_TILING_MACRO)
diff --git a/src/radeon_textured_video.c b/src/radeon_textured_video.c
index 39c7574..7396f6f 100644
--- a/src/radeon_textured_video.c
+++ b/src/radeon_textured_video.c
@@ -349,7 +349,9 @@ RADEONPutImageTextured(ScrnInfoPtr pScrn,
#ifdef USE_EXA
if (info-useEXA) {
/* Force the pixmap into framebuffer so we can draw to it. */
+ info-exa_force_create = TRUE;
exaMoveInPixmap(pPriv-pPixmap);
+ info-exa_force_create = FALSE;
}
#endif
--
1.6.5.2
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: broken msi interrupts with radeon rv570 on amd 8151 agp bridge
On Fri, Nov 6, 2009 at 6:10 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Nov 5, 2009 at 9:06 AM, Matthew Wilcox matt...@wil.cx wrote: On Thu, Nov 05, 2009 at 01:57:10PM +0100, Daniel Vetter wrote: When starting a failsafe X session and starting glxgears (which should cause plenty of interrupts to be generated), /proc/interrupts shows absolutely no MSI interrupts arriving. There are no other devices in this box using MSI interrupts. I've also tried with the lastest -linus git tree merged in, with the same effects. Booting with pci=nomsi works around the issue. I dunno whether this is a pci or radeon issue therefore I'm posting to both lists. lspci -v (as root) is attached below. That sucks, and we need to fix it. It's almost certainly a chipset issue, so my suspicion falls primarily on this device: 04:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8151 AGP Bridge (rev 14) (prog-if 00 [Normal decode]) We have a number of quirks to handle MSIs (both disabling their use, and programming the feature in bridges that the BIOS forgot to set up) on HyperTransport machines already; could you send both lspci -t and lspci -vvvnn (as root) to the linux-pci list? While working on irq support for newer radeons I've noticed a similar issue on an rs780 board, but only with the integrated graphics chip (1002:9610). MSIs work fine on the PCIE slots and other integrated peripherals. When I enable MSIs on the integrated graphics chip, I get no MSI interrupts arriving for that device. Other MSI enabled devices work fine. I haven't had a chance to test any other rs780 systems with integrated graphics yet. Actually I suspect this is different, I'm guessing the PCIE-AGP bridge on the radeon card is screwing up the MSI, I suspect we shouldn't enable MSI on AGP cards ever. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: xf86-video-ati: Branch 'master'
radeon: fix build without kms Sorry about that, I'll try to check this before pushing in the future. Thanks for fixing it up. No worries I'm starting to wonder if I can come up with a cleaner away, because I never test this build path either. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: xf86-video-ati: Branch 'master'
2009/9/1 Michel Dänzer mic...@daenzer.net:
On Mon, 2009-08-31 at 22:24 -0700, Dave Airlie wrote:
commit 22fbd6476f4b3513378e848affc4dd269e9d4498
Author: Dave Airlie airl...@itt42.(none)
Date: Tue Sep 1 15:22:57 2009 +1000
r100/r200: seriously WRAP is illegal for rectangular textures
unless we scale all the bos up to POT
diff --git a/src/radeon_exa_render.c b/src/radeon_exa_render.c
index 69d8140..c3beadc 100644
--- a/src/radeon_exa_render.c
+++ b/src/radeon_exa_render.c
@@ -415,7 +415,10 @@ static Bool FUNC_NAME(R100TextureSetup)(PicturePtr
pPict, PixmapPtr pPix,
switch (repeatType) {
case RepeatNormal:
- txfilter |= RADEON_CLAMP_S_WRAP | RADEON_CLAMP_T_WRAP;
+ if (txformat RADEON_TXFORMAT_NON_POWER2)
+ txfilter |= RADEON_CLAMP_S_CLAMP_LAST |
RADEON_CLAMP_T_CLAMP_LAST;
+ else
+ txfilter |= RADEON_CLAMP_S_WRAP | RADEON_CLAMP_T_WRAP;
This code doesn't make much sense as is - such a condition should have
been caught earlier. Maybe R[12]00TextureSetup need the same code as
R300TextureSetup for info-accel_state-need_src_tile_[xy] or something
like that.
Ah I'll investigate that tomorrow, that might make more sense.
Dave.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: KMS
On Tue, Aug 25, 2009 at 9:31 AM, James Clooscl...@jhcloos.com wrote: can you post the output of dmesg after loading the radeon drm? There is no printk() output when X starts. I used to get: Aug 19 05:21:55 [kernel] agpgart-intel :00:00.0: AGP 2.0 bridge Aug 19 05:21:55 [kernel] agpgart-intel :00:00.0: putting AGP V2 device into 4x mode Aug 19 05:21:55 [kernel] radeonfb :01:00.0: putting AGP V2 device into 4x mode Aug 19 05:21:55 [kernel] [drm] Setting GART location based on new memory map Aug 19 05:21:55 [kernel] [drm] Loading R100 Microcode Aug 19 05:21:55 [kernel] [drm] writeback test succeeded in 1 usecs but now get nothing since I turned on CONFIG_DRM_RADEON_KMS and recompiled ati with enable-kms (and recompiled everything else, too). sounds like you are missing fbcon support maybe. CONFIG_FRAMEBUFFER_CONSOLE. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: xf86-video-ati: Branch 'master' - 2 commits
On Sat, 2009-08-22 at 04:18 -0700, Dave Airlie wrote:
src/radeon_exa.c |3 +--
src/radeon_exa_funcs.c | 35 +++
2 files changed, 36 insertions(+), 2 deletions(-)
New commits:
commit bac224912c750dc1c85ff2d9b8526dad6c23b572
Author: Dave Airlie airl...@redhat.com
Date: Sat Aug 22 21:17:59 2009 +1000
radeon: don't spec any initial placement for pixmaps.
allow the first use to decide placement.
diff --git a/src/radeon_exa.c b/src/radeon_exa.c
index ec65722..3f3c9ba 100644
--- a/src/radeon_exa.c
+++ b/src/radeon_exa.c
@@ -391,8 +391,7 @@ void *RADEONEXACreatePixmap(ScreenPtr pScreen, int
size, int align)
return new_priv;
new_priv-bo = radeon_bo_open(info-bufmgr, 0, size,
- align, RADEON_GEM_DOMAIN_VRAM |
- RADEON_GEM_DOMAIN_GTT, 0);
+ align, 0, 0);
if (!new_priv-bo) {
xfree(new_priv);
ErrorF(Failed to alloc memory\n);
IME this has a significant impact on 2D performance (e.g. x11perf
-aa10text drops from about 325K/s to about 225K/s, and this is
noticeable in real apps), until the kernel side avoids unnecessary BO
copies.
The problem is the API is specced as initial_domain, not domains, so
its incorrect. I'm writing a TTM patch at the moment to avoid BO copies
to VRAM where nothing has yet mapped or touched the BO.
Dave.
Also, current EXA (with EXA_MIXED_PIXMAPS) actually only calls the
driver CreatePixmap(2) hook just before the first accelerated operation
on the pixmap. So I'd suggest setting RADEON_GEM_DOMAIN_VRAM |
RADEON_GEM_DOMAIN_GTT in both hooks.
commit 77f98717d825162da106c6898cdbcbdf5c984ae6
Author: Dave Airlie airl...@redhat.com
Date: Sat Aug 22 21:16:25 2009 +1000
exa/cs: add DFS from GTT optimisation
This uses the new libdrm busy interface, once I had this in place
I added a error if this happened and it does on my desktop here,
so may as well add the optimisation that used to be in my old KMS tree.
Signed-off-by: Dave Airlie airl...@redhat.com
diff --git a/src/radeon_exa_funcs.c b/src/radeon_exa_funcs.c
index e48317f..f937c4e 100644
--- a/src/radeon_exa_funcs.c
+++ b/src/radeon_exa_funcs.c
@@ -507,6 +507,33 @@ out:
}
static Bool
+RADEONDownloadFromScreenGTT(PixmapPtr pSrc, int x, int y, int w,
+ int h, char *dst, int dst_pitch)
+{
+struct radeon_exa_pixmap_priv *driver_priv;
+int src_pitch = exaGetPixmapPitch(pSrc);
+int bpp = pSrc-drawable.bitsPerPixel;
+int src_offset;
+int r;
+
+driver_priv = exaGetPixmapDriverPrivate(pSrc);
+r = radeon_bo_map(driver_priv-bo, 0);
+if (r)
+ return FALSE;
+
+src_offset = (x * bpp / 8) + (y * src_pitch);
+w *= bpp / 8;
+
+while (h--) {
+memcpy(dst, driver_priv-bo-ptr + src_offset, w);
+src_offset += src_pitch;
+dst += dst_pitch;
+}
+radeon_bo_unmap(driver_priv-bo);
+return TRUE;
+}
+
+static Bool
RADEONDownloadFromScreenCS(PixmapPtr pSrc, int x, int y, int w,
int h, char *dst, int dst_pitch)
{
@@ -519,11 +546,19 @@ RADEONDownloadFromScreenCS(PixmapPtr pSrc, int x, int
y, int w,
unsigned bpp = pSrc-drawable.bitsPerPixel;
uint32_t scratch_pitch = (w * bpp / 8 + 63) ~63;
Bool r;
+uint32_t src_domain;
+int busy;
if (bpp 8)
return FALSE;
driver_priv = exaGetPixmapDriverPrivate(pSrc);
+
+busy = radeon_bo_is_busy(driver_priv-bo, src_domain);
+
+if (src_domain == RADEON_GEM_DOMAIN_GTT)
+ return RADEONDownloadFromScreenGTT(pSrc, x, y, w, h,
+ dst, dst_pitch);
RADEONDownloadFromScreenGTT is superfluous, just return FALSE from
RADEONDownloadFromScreenCS. Also, this doesn't take into account any
unflushed operations involving the BO.
Below is what I've been testing for DFS / UTS.
diff --git a/src/radeon_exa_funcs.c b/src/radeon_exa_funcs.c
index bada4fb..abb8be3 100644
--- a/src/radeon_exa_funcs.c
+++ b/src/radeon_exa_funcs.c
@@ -459,6 +459,7 @@ RADEONUploadToScreenCS(PixmapPtr pDst, int x, int y, int
w, int h,
struct radeon_bo *scratch;
unsigned size;
uint32_t datatype = 0;
+uint32_t dst_domain;
uint32_t dst_pitch_offset;
unsigned bpp = pDst-drawable.bitsPerPixel;
uint32_t scratch_pitch = (w * bpp / 8 + 63) ~63;
@@ -470,6 +471,18 @@ RADEONUploadToScreenCS(PixmapPtr pDst, int x, int y, int
w, int h,
driver_priv = exaGetPixmapDriverPrivate(pDst);
+/* If we know the BO won't be busy, don't bother */
+if (driver_priv-bo-cref == 1
+ !radeon_bo_is_busy(driver_priv-bo, dst_domain))
+{
+ static Bool printed;
+ if (!printed) {
+ ErrorF(%s: Bailing
Re: Problems with KMS on RS690
On Thu, Jul 16, 2009 at 12:55 AM, Mike Lothianm...@fireburn.co.uk wrote: I'm using that kernel branch For libdrm: ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --prefix=/usr --datadir=/usr/share --enable-udev --enable-nouveau-experimental-api --enable-radeon-experimental-api * Messages for package x11-libs/libdrm-: * GIT update -- * repository: git://anongit.freedesktop.org/git/mesa/drm * git fetch -f -u origin master:master * at the commit: 3f3c5be6f908272199ccf53f108b1124bfe0a00e * branch: master Fir DDX: ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --prefix=/usr --datadir=/usr/share --enable-dri * Messages for package x11-drivers/xf86-video-ati-: * GIT update -- * repository: git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati * at the commit: 95d431e8b260dd43cf6d93b90eecab1dc0ec7c26 * branch: master I've attached the logs (compressed this time) - with KMS I get a black screen with the X cursor but the system is unusable - without KMS KDE starts - the problem before was unrelated (policykit problem) You have two cards in that machine? Dave. So to reiterate the problem only exist with KMS Thanks for the quick responses Mike ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Problems with KMS on RS690
On Thu, Jul 16, 2009 at 10:01 AM, Mike Lothianm...@fireburn.co.uk wrote: You have two cards in that machine? Dave. Actually yes I've got a Radeon 4650 in there but I'm not using it, should I remove it completely? I was going to switch back to it once the r700 branch is ready I thought I'd disabled it completely in the bios I think we have a bug in the kms radeon driver with multi-card, need to investigate. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: pushed preparation patch for KMS
2009/7/2 Michel Dänzer mic...@daenzer.net: On Thu, 2009-07-02 at 12:07 +1000, Dave Airlie wrote: 2009/7/1 Michel Dänzer mic...@daenzer.net: On Tue, 2009-06-30 at 16:38 +1000, Dave Airlie wrote: I pushed a patch that prepares the driver accel code for the upcoming KMS/DRI2 support. This mainly sorts out the accel interfaces and tries to hide the mess that supporting 25 different methods of accel does. Let me know if it breaks anything major, or if there is any insanity you'd rather see not live much longer. I've mainly tried to avoid having an #ifdef XF86DRM_MODE mass. Looking good basically. I haven't noticed any correctness regressions, but x11perf -aa10text seems to have dropped from almost 600k/s to just above 500k/s. Haven't had time to really look into why that is, but one thing I noticed before on kms-support is that we seem to be (re-)emitting some 2D state we never use with EXA, e.g. background colours. It might be worth even trying not to re-emit state that hasn't changed. what hw was that on? my r500 has no difference before this commit and after it with aa10text. RV350 in my PowerBook. I'll try and get to some older hw later. We could probably two 2D the same as 3D, setup the engine and then do emission, but I'm really trying to avoid adding a full state caching + change feature to the DDX. From what I can see for 2D we probably now emit 4 qwords more than previously. Note that I'm not sure the performance regression is related to the 2D state issue, x11perf -aa10text should be mostly Composite operations in the hot path. yeah thats what I was wondering, like maybe the extra if statements in the accel codepaths make a big difference or a bigger diff on powerpc. like really the amount of 3D state emitted shouldn't be that much bigger, unless I'm flushing more often somewhere or reemitting the 3D base state too often. Dave. But if I can reproduce it on my older hw I'll try and fix it. Great, thanks. I'll also try and see if oprofile gives any hints, though it probably won't if it's indeed related to the GPU command stream. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
pushed preparation patch for KMS
Hi guys I pushed a patch that prepares the driver accel code for the upcoming KMS/DRI2 support. This mainly sorts out the accel interfaces and tries to hide the mess that supporting 25 different methods of accel does. Let me know if it breaks anything major, or if there is any insanity you'd rather see not live much longer. I've mainly tried to avoid having an #ifdef XF86DRM_MODE mass. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: very slow 3d on Mobility FireGL V5200 with radeon driver
On Mon, Dec 1, 2008 at 4:47 PM, Marc MERLIN [EMAIL PROTECTED] wrote: On Sun, Nov 30, 2008 at 11:15:21AM -0800, Michel Dänzer wrote: On Fri, 2008-11-28 at 15:01 -0800, Marc MERLIN wrote: This is with 6.9.0+git20081003.f9826a56-0ubuntu4 with the latest packages from ubuntu jaunty (i.e. bleeding edge). I get the X server to init DRI with both radeonhd and radeon. With radeonhd, the machine deadlocks after I exit the X app (which is slow too) With radeon, things work, but they are quite slow. 1613fps glxgears, 14fps lavalite, and google earth takes 5mn to zoom on a spot. I don't think Google Earth should be that slow. Maybe something like https://bugs.freedesktop.org/show_bug.cgi?id=17929 is biting you. I had a look and tried to see what you mean. I don't get any r300 debug output, but is that because I have AIGLX on? Would you like me to turn it off? Is that expected because the driver is still experimental, or bad? (my much other r300 based thinkpad T42p does 3d much faster than this r5xx chip on my thinkpad Z61p). That's weird. Are you using the same (or at least as similar as possible) driver versions and configuration? Same config file, I just s/radeonhd/radeon/ Drivers are the latest I could get in ubuntu unstable: ii xserver-xorg-video-radeon 1:6.9.0+git20081003.f9826a56-0ubuntu4 ii xserver-xorg-video-radeonhd 1.2.3-1 I don't mind going to git next, but I'm not even sure if I should prefer radeon to radeonhd for that chip, or the other way around?] I'm not radeonhd turns on DRI, just use radeon. Dave. Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems security what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [radeonhd] 0x94CC:0x1545:0x3650: Radeonhd RV610 HD2400Pro
On Wed, Aug 13, 2008 at 7:54 PM, Tai Tri Nguyen [EMAIL PROTECTED] wrote: Hi Alex, The driver I'm using is from git, the latest version of xf86-video-ati git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati I have just downloaded and compiled again but the issue still exist. Video can display in 24 bits depth color but perform wrong color. Do you have any idea for the issue? I think this is a pixman bug, but I'm not sure, Ben you have any luck tracking it down further? Actually R600 doesn't have surfaces like previous cards so actually we need to program some bits of r600. Dave. Thanks, TaiNguyen -Original Message- From: Alex Deucher [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2008 9:01 PM To: Tai Tri Nguyen Cc: Dave Airlie; [EMAIL PROTECTED]; Tuan Thanh Phan Subject: Re: [radeonhd] 0x94CC:0x1545:0x3650: Radeonhd RV610 HD2400Pro On Tue, Aug 12, 2008 at 6:52 AM, Tai Tri Nguyen [EMAIL PROTECTED] wrote: Hi Dave, I got an issue wrong color and low frame rate with Radeon HD 2400 Pro for PowerPC architect. Everything seems OK but the color showed abnormally. I think there's something wrong with the driver or configuration. Please feel free to take a look if you can help. You're using an old version of the driver which is not big endian aware. For big endian, you'll need to pull the latest driver bits from git. Since you are using radeon, you should move this discusssion to [EMAIL PROTECTED] Alex CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Correctly configuring dual head
On Thu, Jul 3, 2008 at 7:29 PM, Christoph Bartoschek [EMAIL PROTECTED] wrote: Am Mittwoch, 2. Juli 2008 schrieb Alex Deucher: I've installedd 6.9.0 and it seems as if I can resolve my DPI problems. Unfortunately the rotated display is unbearable slow. One can see the scanline when parts of the desktop are updated. Is there a trick to get the rotated display fast? Switch to EXA: Option AccelMethod EXA Thanks. Now the rotated display is ok. However there are two problems: 1. If I enter Option Rotate Left to my monitor section, the driver crashes on startup. Is this known? It is now, I've pushed the fix to master. 2. It seems as if the GPU fan is now running all the time. Is it possible that the rotated mode is more gpu intensive such that more power is transformed to heat? Yes, rotation runs the 3D engine in order to do the rotation, so it would need more GPU power. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Problems compilling driver
On Wed, Jun 18, 2008 at 8:09 AM, Alex Deucher [EMAIL PROTECTED] wrote: On Tue, Jun 17, 2008 at 11:12 AM, Helber Maciel Guerra [EMAIL PROTECTED] wrote: I try to compile from git and have some errors: legacy_crtc.c: In function 'radeon_crtc_modeset_ioctl': legacy_crtc.c:628: error: 'struct drm_modeset_ctl' has no member named 'crtc' I can't compile since 9d3afbf5fa4110928a9f965df2733c7 9db92ea99 Tue Jun 3 11:40:49 2008 +0200 You need a newer drm headers. The build process should do the right thing, but I think the drm stuff in fedora has issues with this at the moment. I've just created a new libdrm package for F9, I've asked for it to be pushed into stable. http://kojipkgs.fedoraproject.org/packages/libdrm/2.4.0/0.13.fc9/ if you can't wait. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: x1250 AIGLX
On Wed, May 7, 2008 at 4:01 AM, Alex Rades [EMAIL PROTECTED] wrote: Hi, I'm having this error during X startup on my x1250: (EE) AIGLX error: Calling driver entry point failed(EE) AIGLX: reverting to software rendering I'm using: xserver 1.4 Mesa 7.0.3 drm (lib and radeon module) from git master (I've also tried r345-cleanup but makes no difference) do you have ideas? yes 7.0.3 doesn't support the rs cards. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: X1550 (RV515) with zaphod mode
can you open a bug and attach your conf and logfiles... you might need to try latest git instead of 6.8.0 Dave. On Thu, Apr 17, 2008 at 2:47 AM, Jason Kim [EMAIL PROTECTED] wrote: Driver version: ati-6.8.0 Video card: Radeon X1550 (RV515) I heard zaphod mode has been included again in ati-6.8.0. I tried dualhead(zaphod) with my X1550, but it never worked. Jason -- *** Jason Kim, Software Developer http://userful.com 2nd Floor, 928-6th Ave SW Calgary, AB T2P 0V5 Tel: 403-289-2177 EXT: 210 866-USERFUL (873-7385) Fax: 403-206-7010 ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: X1900 G5 edition and microcode in mesa/drm
On Mon, Mar 31, 2008 at 5:11 AM, Robin H. Johnson [EMAIL PROTECTED] wrote: I'd like to renew my question from back in November 2007, in light of the fact that the mesa/drm branch now seems to have ATI microcode. Previously, I was informed that the X1900 G5 edition cards (PCI ID 0x7240) would not be supported as they contained OFW (which I disputed at the time, noting that the card returned only zeros when trying to read it's ROM, while other OFW cards I had did return their ROM fine) and no AtomBIOS. As the microcode is now in the DRM tree, does this negate the need for having an AtomBIOS from the card directly? No these two things have nothing to do with each other whatosever. Wierd the G5 editions don't have some sort of useful ROM tables in them or something.. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: AMD 780G, anyone?
On Wed, Mar 26, 2008 at 7:56 PM, Magnus Hörlin [EMAIL PROTECTED] wrote: Has anyone managed to get the radeon driver to work on it? I can't, all I get is No devices detected. Tried both VGA and HDMI. Catalyst 8.3 works, but would prefer this. Thankful for any help. /Magnus You'll need to get the radeon driver from git, git clone git://git.freedesktop.org/git/xorg/driver/xf86-video-ati cd xf86-video-ati sh autogen.sh --prefix=/usr make make install (may require installing some distro packages). Dave. lspci -v: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3200 Graphics (prog-if 00 [VGA controller]) Subsystem: Giga-byte Technology Unknown device d000 Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at d800 (32-bit, prefetchable) [size=128M] I/O ports at ee00 [size=256] Memory at fdfe (32-bit, non-prefetchable) [size=64K] Memory at fde0 (32-bit, non-prefetchable) [size=1M] Capabilities: [50] Power Management version 3 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- dpkg -l: xserver-xorg 1:7.3+10ubuntu7 xserver-xorg-video-ati 1:6.8.0-1 Section Files ModulePath /usr/lib/xorg/modules FontPath unix/:7100 EndSection Section Module Load dbe Load extmod Load fbdevhw Load glx Load record Load freetype #Load type1 Load dri EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc105 Option XkbLayout se Option XkbOptionslv3:ralt_switch EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ImPS/2 Option ZAxisMapping 4 5 Option Emulate3Buttons true EndSection Section Device Identifier Device0 Driver radeon EndSection Section Monitor Identifier Generic Monitor Option DPMS Horizsync 28-84 Vertrefresh 43-60 EndSection Section Screen Identifier Default Screen Device Device0 Monitor Generic Monitor Defaultdepth24 SubSection Display Modes 1680x1050 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen Inputdevice Generic Keyboard Inputdevice Configured Mouse EndSection ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: 2.6.25-rc3 + RS690 + DRM + xf86-video-ati hang
On Mon, 3 Mar 2008, Andrew Morton wrote: On Sat, 1 Mar 2008 19:35:11 + Jonathan McDowell [EMAIL PROTECTED] wrote: If I enable CONFIG_DRM_RADEON under 2.6.25-rc3 then starting up X using the xf86-video-ati driver (6.8.0 or latest git) causes the machine to become unresponsive; while it still pings and will accept incoming connections they never actually complete and it's not possible to login over a serial console (the actual video console doesn't display anything and the monitor reports a loss of sync). Disabling the kernel DRM option results in X running successfully. Likewise 2.6.24 works fine with DRM enabled, presumably because the support for the RS690 was only added in 2.6.25-rc The last messages from the kernel before it becomes unresponsive are: [drm] Setting GART location based on new memory map [drm] Loading R300 Microcode [drm] writeback test succeeded in 1 usecs The motherboard in question is an ASUS M2A-VM HDMI, with the analog VGA output being used. The machine is running an AMD64 with Debian unstable. I have put the output of lspci, a non drm Xorg.log and a drm Xorg.log at: http://the.earth.li/~noodles/xorg-ati-drm/lspci http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-nodrm http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-drm If I can provide any more useful information please let me know. Did 2.6.24 work OK with all the same userspace software? We haven't actually released any userspace software properly yet, its all experimental at this point until we debug the hardware some more.. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: 2.6.25-rc3 + RS690 + DRM + xf86-video-ati hang
Is xf86-driver-ati 6.8.0 not a proper release? I'm pretty sure the combination of that, 2.6.25-rc3 and CONFIG_DRM_RADEON causes my machine to become unresponsive. I only tried a git build of the driver after the released version was causing issues. Yes we made a mistake with 6.8.0 enabling DRI on rs680 chips before we knew it worked for everyone, I may be still able to fix this in the kernel but there is a good chance that it'll require a 6.8.1 userspace, I can't do anything else about it.. Jonathan I appreciate the bug report, I'm more saying to Andrew that getting DRI right on new chipsets is non-trivial as there are lot of configurations we can't test until we actually push the code to users.. and in this case you are one of those.. you might try setting the VRAM in your BIOS to 128MB instead of Auto and seeing it helps.. I'll be trying to fix the problem properly quite soon. The correct workaround is to add Option DRI Off to xorg.conf or for me to travel back in time and unrelease 6.8.0. Removing the kernel DRI support will just break lots of working systems. Dave. Replacing 2.6.25-rc3 with 2.6.24 (still with CONFIG_DRM_RADEON enabled) results in a machine that boots to GDM successfully. Likewise if I disable CONFIG_DRM_RADEON in 2.6.25-rc3 the machine boots to GDM ok. J. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Compile error on git master?
/bin/sh ../libtool --tag=CC --mode=compile i486-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src-I/usr/include/xorg -I/usr/include/drm -I/usr/include/X11/dri -Wall -g -O2 -Wall -MT radeon_bios.lo -MD -MP -MF .deps/radeon_bios.Tpo -c -o radeon_bios.lo ../../src/radeon_bios.c i486-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src -I/usr/include/xorg -I/usr/include/drm -I/usr/include/X11/dri -Wall -g -O2 -Wall -MT radeon_bios.lo -MD -MP -MF .deps/radeon_bios.Tpo -c ../../src/radeon_bios.c -fPIC -DPIC -o .libs/radeon_bios.o ../../src/radeon_bios.c: In function 'RADEONGetBIOSInfo': ../../src/radeon_bios.c:162: error: 'AtomBiosArgRec' undeclared (first use in this function) ../../src/radeon_bios.c:162: error: (Each undeclared identifier is reported only once ../../src/radeon_bios.c:162: error: for each function it appears in.) ../../src/radeon_bios.c:162: error: expected ';' before 'atomBiosArg' Any ideas? Not sure what happened but re-run autogen.sh and it should work okay.. Dave. Marius ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
new irc channel #radeon on freenode
I've just registered #radeon on freenode IRC network. This channel is for end user support of the radeon driver. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Radeon R500 support
On Nov 21, 2007 9:27 AM, GerbilSoft [EMAIL PROTECTED] wrote: I tested out the atombios-support branch of xf86-driver-ati on my ThinkPad T60p (2623-DDU; FireGL V5200; 1600x1200 LCD), and it doesn't seem to work correctly. The display is all garbled, though the desktop environment does start up. When switching back to the RadeonHD driver via blind typing in console, the previous desktop image does show up for a few seconds before RadeonHD clears the screen, so I'm thinking there's an LVDS setting problem. I have attached the Xorg.log file from this run. Could you try it again with the latest code? I think agd5f pushed some LVDS fixes.. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Radeon X200M help offered
and with disable_lowimpact_fallback=1: [EMAIL PROTECTED] ~/src $ disable_lowimpact_fallback=1 googleearth ATTENTION: default value of option disable_lowimpact_fallback overridden by environment. Fatal error in __driConfigOptions line 129, column 0: illegal default value: 1. Google Earth has caught signal 6. disable_lowimpact_fallback=true perhaps.. Mesa-7.0.1 isn't all that good on xpress 200M, it doesn't do clipping properly.. there is a patch in Fedora which backports r300 from master for xpress200m support.. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Radeon X200M help offered
I've got a laptop with a Radeon Xpress 200M, and am wondering what I can do to help with getting 3D hardware acceleration to work properly, more specifically, is there a place where the basics are listed on how to 'hack' on the driver(I'm also prepared to test stuff)? Also, is this the correct list to be mailing, or should I mail the MESA list instead? It should for a large value of work, googleearth and stuff wfm... compiz not so much.. compiz needs a small test program written doing what it does.. I think we might have a problem with different data going into the driver when it comes direct vs indirect.. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Radeon 7500 no 3D-funktion in X.org 7.2
I am not sure to be in the right list. If not please tell me. Well I have just installed OpenSuSE 10.3 with X.org 7.2. In the docs for X.org 7.0 I have fount the ATI Radeon 7500 fully supportet in 2D and 3D-Funktion. However my graphics-adapter does not work in 3D, but I need for google-earth. The monitor is a flat panel with 1280x1024 pixels and DVI-Input. I have adjustedt 16 bpp for color-deph. glxgears libGL error: open DRM failed (Operation not permitted) libGL error: reverting to (slow) indirect rendering try running LIBGL_DEBUG=verbose glxinfo and working out what went wrong.. my best guess is permissions on /dev/dri/card0 Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Radeon 7500 no 3D-funktion in X.org 7.2
Wierd you have direct rendering.. I'm not sure why you don't get glxgears working.. It looks like SuSE have some wierd patches to Mesa for updated drivers the lack of drirc shouldn't matter.. so does LIBGL_DEBUG=verbose glxgears give anything different.. Dave. # LIBGL_DEBUG=verbose glxinfo name of display: :0.0 libGL: XF86DRIGetClientDriverName: 5.2.0 radeon (screen 0) libGL: OpenDriver: trying /usr/lib/dri/updates/radeon_dri.so libGL error: dlopen /usr/lib/dri/updates/radeon_dri.so failed (/usr/lib/dri/updates/radeon_dri.so: cannot open shared object file: No such file or directory) libGL: OpenDriver: trying /usr/lib/dri/radeon_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:00.0 libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /root/.drirc: No such file or directory. display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20061018 AGP 4x x86/MMX+/3DNow! +/SSE TCL OpenGL version string: 1.3 Mesa 7.0.1 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 tc 0 16 0 r . . 5 6 5 0
Re: ppracer + xf86-video-ati = some colors/objects garbeled
to test the xf86-video-ati git HEAD with my ATI Radeon Mobility X300 (M22) 5460 (PCIE) I tried the ppracer. Performance looks really ok, but some objects on the track and some patches of white (which might be supposed to be ice?!) have funny random colors. Any idea? Sounds like a Mesa bug probably dri-devel is a better place, or log a bug in freedesktop.org against the Mesa r300 driver.. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [Bug 12068] r300: compiz has poor performance
--- Comment #10 from [EMAIL PROTECTED] 2007-08-21 15:34 PST --- I had a look at the site. do you think that those 2 are enough? or others should be applied too? xserver-1.3.0-newglx-offscreen-pixmaps.patch xserver-1.3.0-exaupgrade.patch You also need the mesa7 patch and of course Mesa 7.0.1 Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
