From martin-eric.racine at iki.fi Mon Feb 6 05:14:19 2012 From: martin-eric.racine at iki.fi (=?UTF-8?Q?Martin=2D=C3=89ric_Racine?=) Date: Mon, 6 Feb 2012 15:14:19 +0200 Subject: [Xorg-driver-geode] building xf86-video-geode on non-Linux platforms? In-Reply-To: References: Message-ID: 2. tammikuuta 2012 1.04 Martin-?ric Racine kirjoitti: > Starting with release 2.11.13, the autoconf implementation of > xf86-video-geode allows more flexibility on which platforms it can > succesfully build for, by skipping the ZTV module on platforms that > don't support V4L2. > > Btw, I'd welcome reports about which new platforms 2.11.13 can > succesfully build on. So far, we seem to have: Linux (geode & ztv), > Hurd (geode). Arrigo and Marc, Could you please confirm on which BSD variants the Geode video module now builds and whether ZTV get succesfully built as well? Thanks! Martin-?ric From martin-eric.racine at iki.fi Fri Feb 17 07:42:50 2012 From: martin-eric.racine at iki.fi (=?UTF-8?Q?Martin=2D=C3=89ric_Racine?=) Date: Fri, 17 Feb 2012 17:42:50 +0200 Subject: [Xorg-driver-geode] building xf86-video-geode on non-Linux platforms? In-Reply-To: References: Message-ID: 6. helmikuuta 2012 15.14 Martin-?ric Racine kirjoitti: > 2. tammikuuta 2012 1.04 Martin-?ric Racine > kirjoitti: >> Starting with release 2.11.13, the autoconf implementation of >> xf86-video-geode allows more flexibility on which platforms it can >> succesfully build for, by skipping the ZTV module on platforms that >> don't support V4L2. >> >> Btw, I'd welcome reports about which new platforms 2.11.13 can >> succesfully build on. So far, we seem to have: Linux (geode & ztv), >> Hurd (geode). > > Arrigo and Marc, > > Could you please confirm on which BSD variants the Geode video module > now builds and whether ZTV get succesfully built as well? Any news on this? :) Martin-?ric From matthieu.herrb at laas.fr Sun Feb 19 11:58:08 2012 From: matthieu.herrb at laas.fr (Matthieu Herrb) Date: Sun, 19 Feb 2012 20:58:08 +0100 Subject: [Xorg-driver-geode] building xf86-video-geode on non-Linux platforms? In-Reply-To: References: Message-ID: <20120219195808.GA21793@nebraska.herrb.net> On Fri, Feb 17, 2012 at 05:42:50PM +0200, Martin-?ric Racine wrote: > 6. helmikuuta 2012 15.14 Martin-?ric Racine > kirjoitti: > > 2. tammikuuta 2012 1.04 Martin-?ric Racine > > kirjoitti: > >> Starting with release 2.11.13, the autoconf implementation of > >> xf86-video-geode allows more flexibility on which platforms it can > >> succesfully build for, by skipping the ZTV module on platforms that > >> don't support V4L2. > >> > >> Btw, I'd welcome reports about which new platforms 2.11.13 can > >> succesfully build on. So far, we seem to have: Linux (geode & ztv), > >> Hurd (geode). > > > > Arrigo and Marc, > > > > Could you please confirm on which BSD variants the Geode video module > > now builds and whether ZTV get succesfully built as well? > > Any news on this? :) > Sorry, I've been meaning to test that on OpenBSD for a few weeks already, but have always been distracted by other stuff. And it happened again this weekend. A quick build test of git HEAD shows that it fails to build in geode_msr.c. I'll investigate ASAP and produce either a patch or a more detailled bug report. Thanks for the heads-up. -- Matthieu Herrb From matthieu.herrb at laas.fr Mon Feb 20 13:27:40 2012 From: matthieu.herrb at laas.fr (Matthieu Herrb) Date: Mon, 20 Feb 2012 22:27:40 +0100 Subject: [Xorg-driver-geode] building xf86-video-geode on non-Linux platforms? In-Reply-To: <20120219195808.GA21793@nebraska.herrb.net> References: <20120219195808.GA21793@nebraska.herrb.net> Message-ID: <20120220212739.GB29221@nebraska.herrb.net> On Sun, Feb 19, 2012 at 08:58:08PM +0100, Matthieu Herrb wrote: > On Fri, Feb 17, 2012 at 05:42:50PM +0200, Martin-?ric Racine wrote: > > 6. helmikuuta 2012 15.14 Martin-?ric Racine > > kirjoitti: > > > 2. tammikuuta 2012 1.04 Martin-?ric Racine > > > kirjoitti: > > >> Starting with release 2.11.13, the autoconf implementation of > > >> xf86-video-geode allows more flexibility on which platforms it can > > >> succesfully build for, by skipping the ZTV module on platforms that > > >> don't support V4L2. > > >> > > >> Btw, I'd welcome reports about which new platforms 2.11.13 can > > >> succesfully build on. So far, we seem to have: Linux (geode & ztv), > > >> Hurd (geode). > > > > > > Arrigo and Marc, > > > > > > Could you please confirm on which BSD variants the Geode video module > > > now builds and whether ZTV get succesfully built as well? > > > > Any news on this? :) > > > > Sorry, > > I've been meaning to test that on OpenBSD for a few weeks already, but > have always been distracted by other stuff. And it happened again this > weekend. > > A quick build test of git HEAD shows that it fails to build in > geode_msr.c. I'll investigate ASAP and produce either a patch or a > more detailled bug report. Wrong alert. I did attempt a build on an amd64 machine, because I mis-remembered that geode would also build there. Thats' wrong at least for OpenBSD. Tried more seriously on a 32 bits machines. No issues there. The git HEAD builds out of the box (altough I still have local patches from mbalmer for MSR support on OpenBSD). diff --git a/src/geode_msr.c b/src/geode_msr.c index 26fd78f..d3e7a53 100644 --- a/src/geode_msr.c +++ b/src/geode_msr.c @@ -2,23 +2,40 @@ #include "config.h" #endif +#include +#include +#ifdef __OpenBSD__ +#include +#endif + #include #include #include -#include #include + #include "os.h" #include "geode.h" +#ifdef __OpenBSD__ +#define _PATH_MSRDEV "/dev/amdmsr" +#define X_PRIVSEP +#else +#define _PATH_MSRDEV "/dev/cpu/0/msr" +#endif + static int _msr_open(void) { static int msrfd = 0; if (msrfd == 0) { - msrfd = open("/dev/cpu/0/msr", O_RDWR); +#ifdef X_PRIVSEP + msrfd = priv_open_device(_PATH_MSRDEV); +#else + msrfd = open(_PATH_MSRDEV, O_RDWR); +#endif if (msrfd == -1) - ErrorF("Unable to open /dev/cpu/0/msr: %d\n", errno); + ErrorF("Unable to open %s: %s\n", _PATH_MSRDEV, strerror(errno)); } return msrfd; @@ -27,6 +44,20 @@ _msr_open(void) int GeodeReadMSR(unsigned long addr, unsigned long *lo, unsigned long *hi) { +#ifdef __OpenBSD__ + struct amdmsr_req req; +#endif + int fd = _msr_open(); + +#ifdef __OpenBSD__ + req.addr = addr; + + if (ioctl(fd, RDMSR, &req) == -1) + ErrorF("Unable to RDMSR %d\n", errno); + + *hi = req.val >> 32; + *lo = req.val & 0xffffffff; +#else unsigned int data[2]; int fd = _msr_open(); int ret; @@ -46,13 +77,25 @@ GeodeReadMSR(unsigned long addr, unsigned long *lo, unsigned long *hi) *hi = data[1]; *lo = data[0]; - +#endif return 0; } int GeodeWriteMSR(unsigned long addr, unsigned long lo, unsigned long hi) { +#ifdef __OpenBSD__ + struct amdmsr_req req; +#endif + int fd = _msr_open(); + +#ifdef __OpenBSD__ + req.addr = addr; + req.val = (u_int64_t)hi << 32 | (u_int64_t)lo; + + if (ioctl(fd, WRMSR, &req) == -1) + ErrorF("Unable to WRMSR %d\n", errno); +#else unsigned int data[2]; int fd = _msr_open(); @@ -67,6 +110,6 @@ GeodeWriteMSR(unsigned long addr, unsigned long lo, unsigned long hi) if (write(fd, (void *)data, 8) != 8) return -1; - +#endif return 0; } -- Matthieu Herrb From christian.gmeiner at gmail.com Fri Feb 24 06:48:43 2012 From: christian.gmeiner at gmail.com (Christian Gmeiner) Date: Fri, 24 Feb 2012 15:48:43 +0100 Subject: [Xorg-driver-geode] GEODE_TRACE_FAIL Message-ID: Hi all I have compiled a version of the driver with GEODE_TRACE_FAIL enabled and got this messages: lx_check_composite: Masks can be only done with a 8bpp or 4bpp depth lx_check_composite: Transform operation is non-trivial lx_check_composite: pSrc should be 1x1 pixel if pMsk is not zero Is there some potential for improvements? greets -- Christian Gmeiner, MSc From leio at gentoo.org Sun Feb 26 06:03:52 2012 From: leio at gentoo.org (Mart Raudsepp) Date: Sun, 26 Feb 2012 16:03:52 +0200 Subject: [Xorg-driver-geode] GEODE_TRACE_FAIL In-Reply-To: References: Message-ID: <1330265032.503.22.camel@daedalus.lan> Hello, On R, 2012-02-24 at 15:48 +0100, Christian Gmeiner wrote: > Hi all > > I have compiled a version of the driver with GEODE_TRACE_FAIL enabled > and got this messages: > > lx_check_composite: Masks can be only done with a 8bpp or 4bpp depth > lx_check_composite: Transform operation is non-trivial > lx_check_composite: pSrc should be 1x1 pixel if pMsk is not zero > > Is there some potential for improvements? Does these happen often in the middle of other operations that are hardware accelerated, as such causing heavy pixmap migration ping-pong and huge perfomance slowdown due to that? From bogus@does.not.exist.com Sun Feb 26 06:12:27 2012 From: bogus@does.not.exist.com () Date: Sun, 26 Feb 2012 14:12:27 -0000 Subject: No subject Message-ID: depending what the actual details of the operation are. "Masks can be only done with a 8bpp or 4bpp depth" happens if the given alpha mask is, well, not 4 or 8 bits per pixel depth. I can imagine some optimization possibilities here if all the alpha pixel values could be transformed without loss of detail to a temporary 4bpp or 8bpp alpha mask instead, e.g if the mask is actually 1bpp, 2bpp, or if it's 16bpp or 24bpp with the least significant bits somehow not mattering (not sure what the depth conversion logic here is offhand for them to not matter if converting depth down). Perhaps you could try printing out the actual value of pMsk->format there and see what the depth and other details are when it fallbacks most often. It seems you can get details of the format with the following macros: PICT_FORMAT_BPP(pMsk->format) PICT_FORMAT_TYPE(pMsk->format) PICT_FORMAT_A(pMsk->format) PICT_FORMAT_R(pMsk->format) PICT_FORMAT_G(pMsk->format) PICT_FORMAT_B(pMsk->format) For comparison, PICT_a8 would be 8bpp, type PICT_TYPE_A, and values of 8, 0, 0, 0 for A, R, G, B - those tell how many bits per pixel for alpha, red, green and blue channels are used. "Transform operation is non-trivial" should happen basically if the transform isn't just a full degree rotation, as the Geode hardware can do only 90, 180, 270 degree rotations basically; which is important to have for rotated screens. Depending on the actual transformation, perhaps something tricky can be figured out to do it, as it isn't necessarily some kind of rotation, but could be a different kind of transformation in there - so according to the exact details of nature of it, perhaps something could be done to hardware accelerate it. "pSrc should be 1x1 pixel if pMsk is not zero" happens when it tells it happens. I'm not sure if we could do something with more complex sources with masks than just a pixel. Needs some thinking there. All these fallbacks would also be less costly, if we didn't end up migrating the pixmaps out temporarily from video memory to system memory. I believe that theoretically pixman based software fallbacks could be done inside video memory, but I didn't get EXA classic mode convinced of that yet to try it out. As in, video memory is really just CPU memory too, just framebuffer memory set aside into which hardware accelerated operations can put their result in; so if we were doing software operations in there as well if there's enough room, without migrating out of there, we could avoid the costly part of copying memory around too much and fix it for all cases to not be SO big of a performance hit, while it'd be still nice to do in hardware what is possible. If you have a custom drawing code you need to have fast, then an alternative could be to change the drawing operation at the application level as well. But that's not really feasible for a generic desktop system or so. Best Regards, Mart Raudsepp From ardovm at yahoo.it Tue Feb 28 23:55:29 2012 From: ardovm at yahoo.it (Arrigo Marchiori) Date: Wed, 29 Feb 2012 08:55:29 +0100 Subject: [Xorg-driver-geode] building xf86-video-geode on non-Linux platforms? In-Reply-To: References: Message-ID: <20120229075528.GB21776@snail.casa> Hello everybody, On Mon, Feb 06, 2012 at 03:14:19PM +0200, Martin-?ric Racine wrote: > 2. tammikuuta 2012 1.04 Martin-?ric Racine > kirjoitti: > > Starting with release 2.11.13, the autoconf implementation of > > xf86-video-geode allows more flexibility on which platforms it can > > succesfully build for, by skipping the ZTV module on platforms that > > don't support V4L2. > > > > Btw, I'd welcome reports about which new platforms 2.11.13 can > > succesfully build on. So far, we seem to have: Linux (geode & ztv), > > Hurd (geode). > > Arrigo and Marc, > > Could you please confirm on which BSD variants the Geode video module > now builds and whether ZTV get succesfully built as well? I can confirm that the geode driver, release 2.11.13, builds and runs under FreeBSD 8-STABLE, sources and ports updated at February 19, 2012. The ZTV module seems not to be built. Thank you for your efforts! -- rigo http://rigo.altervista.org