That would be a recent ATI card, though I don’t know exactly which model name. Samuel Greear has imported David Shao’s DRM work, originally for Summer of Code, last year. Most newer Radeons should work (?).
6 Replies to “Got an r600-based video card?”
Comments are closed.
Evergreen is the chipset code name or 57xx i believe the model is or maybe 56xx from memory. one of yhe two any way. so glad this was finarly committed!
Should perhaps look into getting the vm changes in from the freebsd patch to make gem/kms porting easier
edward, I’ve looked at part of the patchset to bring this up to current as of now and saw a bit of new VM stuff — do you know what this is for / could you elaborate?
Otherwise I think bringing us up to the very latest version that FreeBSD has would be quite trivial.
Samuel,
OK so as far as I understand it;
The changes to the VM system allow GEM to allocate physical pages identified from the underlying physical segment. But in a fictitious way (vm_fault.c PG_FICTITIOUS, PG_UNMANAGED) since GEM will handle what are invalidation of pages. int dev_pager_getpages(..) from (device_pager.c) and struct pagerops mgtdevicepagerops = {..} etc..
Since GEM is a memory manager (gem object device pager) kind of on top of the kernel memory manager. Kind of like bus_dma but more domain specific to complex graphics card hardware?
So the kernel memory manager needs to provide some mechanism to kind of bypass (not strictly, just more relaxed and less abstract) certain things in regards to memory physical addresses and hence, instead provide the management of the video/system memory for addressing strictly though GEM. So pagedaemon (changes to pmap.c) must not see pages from the gem object pager and this is one of the main points I believe.
I hope I have answered your question :/
Cheers,
DISCLAIMER: I am not a expert, open to corrections or pointing out how stupid I actually am ;)
P.S. I have exams around the corner however I would love to chip in if there is anything bit size?
From the GEM docs:
“Gem provides explicit memory management primitives. System pages are
allocated when the object is created, either as the fundemental storage for
hardware where system memory is used by the graphics processor directly, or
as backing store for graphics-processor resident memory.”^[1]
[1] – http://lwn.net/Articles/283798/
EOC, I understand, thanks, could you dig up the FreeBSD changesets for me? I would like to bring us to parity with them on the GEM front, because as I understand it they have KMS working by-and-large so that shouldn’t be too far off.
Samuel,
Here is the main wiki page for the current project:
http://wiki.freebsd.org/Intel_GPU
I tested the patch already on my Lenovo X301 laptop and it works perfect. Feedback from the PCBSD folks say it works well for them also.
However I have a fresh install of DragonflyBSD back on this machine again. So happy to chip in as far as I can understand. Absolutely willing to learn new things.
Patches here: http://people.freebsd.org/~kib/drm/
Prob ignore the old stuff. First step is to get the VM changes in and GEM should be smooth sailing after that. Unfortunately I only know the theory of the VM side not how to implement then required changes in Dragonfly.
Kind Regards,
Samuel,
Here is the main wiki page for the current project:
http://wiki.freebsd.org/Intel_GPU
I tested the patch already on my Lenovo X301 laptop and it works perfect. Feedback from the PCBSD folks say it works well for them also.
However I have a fresh install of DragonflyBSD back on this machine again. So happy to chip in as far as I can understand. Absolutely willing to learn new things.
Patches here: http://people.freebsd.org/~kib/drm/
Prob ignore the old stuff. First step is to get the VM changes in and GEM should be smooth sailing after that. Unfortunately I only know the theory of the VM side not how to implement then required changes in Dragonfly.
Kind Regards,