Re: eee + glx

["Chavdar Ivanov" <ci4ic4%gmail.com@localhost>]

2008/9/2 Blair Sadewitz <blair.sadewitz%gmail.com@localhost>:
>>> On 8/29/08, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
>>>  >  modload drm
>>>  >  modload i915drm
>>>  >
> FYI:
>
> Currently, the i915 module is vastly more reliable than the
> radeon module.  If it works for you, I'm glad to hear it; however,
> in any case where there're untoward issues, please try
> building the code into the kernel as usual, as they're not
> bug-free yet (at least insofar as I'm aware).
>
> Additionally, if anyone's using a radeon card with our drm,
> please do try this patch:
>
> <http://www.netbsd.org/~bjs/drm-latest.diff>

The patch applied cleanly, but 'make depend' in compile/{CONFIG} gives me:

....
#    create  LOAN8DRM/ati_pcigart.d
mkdep -f ati_pcigart.d --  -ffreestanding -fno-zero-initialized-in-bss
 -O2 -std=gnu99 -fno-strict-aliasing   -Werror -Wall -Wno-main
-Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes
-Wstrict-prototypes -Wswitch -Wshadow -Wcast-qual -Wwrite-strings
-Wno-unreachable-code -Wno-sign-compare -Wno-pointer-sign
-Wno-attributes -Wextra -Wno-unused-parameter  -Werror -march=i486
-mtune=pentiumpro   -Di386 -I. -I../../../../contrib/dev/ath/netbsd
-I../../../../../common/include -I../../../../arch  -I../../../..
-nostdinc -DLKM -DUDF_READWRITE -DMAXUSERS=64 -D_KERNEL -D_KERNEL_OPT
-I../../../../lib/libkern/../../../common/lib/libc/quad
-I../../../../lib/libkern/../../../common/lib/libc/string
-I../../../../lib/libkern/../../../common/lib/libc/arch/i386/string
-I../../../../../common/include -I../../../../dev/drm
-I../../../../dist/ipf -I../../../../dev/pci/drm
../../../../dev/pci/drm/ati_pcigart.c
In file included from ../../../../dev/pci/drm/ati_pcigart.c:40:
../../../../dev/drm/drmP.h:141:24: error: drm_netbsd.h: No such file
or directory
mkdep: compile failed.
...


Otherwise, I was impressed yesterday when I finally decided to switch
one of my old laptops to -current (mainly as a server, not required
otherwise) : - radeondrm worked straight after installation, gave me
some reasonable glxgears figures (~140fps, but this is 5 y/o IGP 200
or something). I don't remember whether I used one of the ISOs from
releng or a slf-built one on this occasion, but it looks just fine.

>
> This patch includes a bunch of improvements I've accumulated
> over time, including:
>
> - Uses cv(9) instead of mtsleep.
> - Uses pool_cache(9) memory allocator in radeon_mem.c
>  (if you have issues with this, please let me know, but it
>  seems to work for me, at least).
> - Uses bus_dma(9) where appropriate instead of malloc(9),
>  which should absolutely not be used e.g. for scatter/gather
>  (also eliminates ugly vtophys() use in drm_vm.c).
> - Uses "quick-n-dirty" mmap "cookies" for offsets passed
>  to drm_mmap.  If you have a radeon card, this should
>  allow you to use the drm on amd64.  Unfortunately,
>  due to bugs in our revision of the i915 driver, this will
>  break Intel cards (if you're interested in helping resolve this
> issue, please contact me).  Once we have the newer drm code
>  in src/sys/external working, this should no longer be an issue.
> - Uses in-kernel realloc(9) instead of the drm-provided one.
> - The interrupt handler and corresponding "drm_irq" mutex
>  now use IPL_SOFTNET; IPL_VM was probably excessive.
> - Various locking fixes in drm_bufs.c and drm_auth.c.
> - The code allocating memory with bus_dma now keeps state
>  information and provides verbose debugging output each time
>  a mapping is removed.
> - The mtrr functions in drm_memory.c now use the 'n'
>  argument as intended.  That is, instead of this:
>
>  return mtrr_set(&mtrrmap, &one, NULL, MTRR_GETSET_KERNEL);
>
> where one is initialized to 1, they do this:
>
>       KERNEL_LOCK(1, NULL);
>       ret = mtrr_set(&mtrrmap, &n, NULL, MTRR_GETSET_KERNEL);
>       if (n != 0) {
>               mtrr_commit();
>       }
>       KERNEL_UNLOCK_ONE(NULL);
>       return ret;
>
>  If you're curious about this, see the code in e.g. i686_mem.c.
>  Should I be mistaken in my use of our mtrr API, please
>  do let me know!
>
> Comments/suggestions/gripes/etc are always welcome
> (so are volunteers!).
>
> Regards,
>
> --Blair
>



-- 
----
Chavdar Ivanov