Re: redundant xf86-video-intel patches

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Jan 25, 2015 at 03:57:48PM +0000, Patrick Welche wrote:
> We have local patches to use
> 1) drmIoctl instead of do_ioctl
> 2) drmMap   instead of mmap
> 
> 1) The only difference between drmIoctl and do_ioctl is that do_ioctl calls
>    sched_yield() if ioctl returns EAGAIN. Why is calling sched_yield() a
>    bad idea?
> 
>    The sched_yield() call was added upstream in:
> 
>    Author: Chris Wilson <chris%chris-wilson.co.uk@localhost>
>    Date:   Mon Jan 20 09:32:50 2014 +0000
> 
>     sna: Yield the processor if the kernel reports EAGAIN
>     
>     An artifact of our kernel/userspace interaction is that under certain
>     circumstances the kernel will report EAGAIN in order for it to have CPU
>     time to run its own workqueues before it can process the userspace
>     request. We can be cooperative and yield ourselves rather than busy-spin
>     waiting for the scheduler to demote us.
> 
> 2)  Again, anyone remember what lead to us thinking that __kgem_bo_size()
>     is doing the wrong thing?
> 
>     drmMap:
>       pagesize_mask = getpagesize() - 1;
>       size = (size + pagesize_mask) & ~pagesize_mask;
>     mmap with call to bytes() => __kgem_bo_size():
>       return PAGE_SIZE * bo->size.pages.count;
> 
> A poor experiment is that without those two changes, I can run
> intel_drv.so on NetBSD-current/amd64 on a Sandy Bridge, which
> suggests that they might no longer be necessary.
> 
> It is a poor experiment in the sense that that is probably a well
> tested configuration... 32-bit and old intel would be better.

I can test on i386 on a 965GM if you provide patches against netbsd-7.
Note that accelleration doens't work well on this platform anyway,
I see display corruption (especially in fonts)

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--