Re: radeon CS parser refactoring

2013-01-08 Thread Christian König
On 08.01.2013 00:09, Ilija Hadzic wrote: * There are multiple patches that contributed to the breakage of UMS. I didn't bother pin-pointing them all, but one that I looked (6a7068b4) dates back to April 2012 so there are kernels out in distros that crash on UMS. That probably tells us how m

Re: radeon CS parser refactoring

2013-01-07 Thread Ilija Hadzic
On Mon, Jan 7, 2013 at 7:21 PM, Marek Olšák wrote: > > IIRC, the radeon gallium drivers call abort() if they encounter an > unsupported DRM version (that is UMS). > I am not familiar enough to comment, but my observation was that as soon as I backed out to classic, the segfault went away. So I as

Re: radeon CS parser refactoring

2013-01-07 Thread Marek Olšák
On Tue, Jan 8, 2013 at 12:09 AM, Ilija Hadzic wrote: > > > On Fri, 4 Jan 2013, Alex Deucher wrote: > >> R6xx and r7xx are really all you need to worry about in this case. >> R1xx-r5xx UMS uses a different kernel interface for command submission >> and evergreen and later don't have UMS drm support

Re: radeon CS parser refactoring

2013-01-07 Thread Ilija Hadzic
On Fri, 4 Jan 2013, Alex Deucher wrote: R6xx and r7xx are really all you need to worry about in this case. R1xx-r5xx UMS uses a different kernel interface for command submission and evergreen and later don't have UMS drm support. UMS r6xx/r7xx support used the same kernel interface for comman

Re: radeon CS parser refactoring

2013-01-06 Thread Daniel Vetter
On Sat, Jan 05, 2013 at 03:21:27PM +0100, Christian König wrote: > [SNIP] > > On 05.01.2013 00:42, Alex Deucher wrote: > >R6xx and r7xx are really all you need to worry about in this case. > >R1xx-r5xx UMS uses a different kernel interface for command submission > >and evergreen and later don't ha

Re: radeon CS parser refactoring

2013-01-05 Thread Christian König
[SNIP] On 05.01.2013 00:42, Alex Deucher wrote: R6xx and r7xx are really all you need to worry about in this case. R1xx-r5xx UMS uses a different kernel interface for command submission and evergreen and later don't have UMS drm support. UMS r6xx/r7xx support used the same kernel interface for

Re: radeon CS parser refactoring

2013-01-04 Thread Alex Deucher
On Fri, Jan 4, 2013 at 5:57 PM, Ilija Hadzic wrote: > > On Fri, 4 Jan 2013, Dave Airlie wrote: > >> Did you run these with pre-kms userspace etc to make sure it doesn't >> cause regressions there? >> > > I did some tests with UMS and shuffled a number of cards. As I feared, I ran > into a number o

Re: radeon CS parser refactoring

2013-01-04 Thread Ilija Hadzic
On Fri, 4 Jan 2013, Dave Airlie wrote: Did you run these with pre-kms userspace etc to make sure it doesn't cause regressions there? I did some tests with UMS and shuffled a number of cards. As I feared, I ran into a number of unrelated problems, but in each case I have seen identical beah

Re: radeon CS parser refactoring

2013-01-04 Thread Alex Deucher
On Wed, Jan 2, 2013 at 6:27 PM, Ilija Hadzic wrote: > The following set of patches refactor the CS-parser logic > in an effort to consolidate the code that is repeated across > ASIC-specific files. All patches except #8 are function-neutral, > that is they preserve the existing functionality of th

Re: radeon CS parser refactoring

2013-01-03 Thread Ilija Hadzic
On Fri, 4 Jan 2013, Dave Airlie wrote: Did you run these with pre-kms userspace etc to make sure it doesn't cause regressions there? No, I didn't, but I can give it a quick whirl. I think I still have one or two machines with 6.14.x DDX that I can put in UMS mode and see what happens. H

Re: radeon CS parser refactoring

2013-01-03 Thread Dave Airlie
> The following set of patches refactor the CS-parser logic > in an effort to consolidate the code that is repeated across > ASIC-specific files. All patches except #8 are function-neutral, > that is they preserve the existing functionality of the driver. > Patch #8 adds one extra check for WAIT_RE