The problem didn't let me rest and I believe I have found a solution. I
need to use virt_to_page instead of vmalloc_to_page in order to find
consistent pages in drm_vm_shm_nopage. I still don't understand how
agpAlloc made vmalloc_to_page work.
If no one objects I'll commit the attached patch
Am Samstag, den 08.01.2005, 20:54 -0500 schrieb Alex Deucher:
On Sat, 8 Jan 2005 21:18:24 + (UTC), Martin Lucina [EMAIL PROTECTED]
wrote:
Hi Felix,
[... new Savage DRM ...]
I just tried this code via John's experimental Xorg packages at
www.nixnuts.net.
400fps in glxgears,
Hi all,
has anyone ever considered using the video overlay for 3D page flipping?
It always bothered me that the page-flipping method used by the radeon
drivers is so complicated WRT 2D/3D interaction and it would even stop
working when (if?) we switch to allocating back buffers per-client. So I
Am So, den 02.01.2005 schrieb Sergio Monteiro Basto um 2:42:
On Fri, 2004-12-31 at 16:02 +0100, Felix Kühling wrote:
I was going to change mesa/src/mesa/drivers/dri/Makefile.template to use
the share-core directory for DRM includes. This will be needed for the
new Savage DRM as it lives
Am Sa, den 01.01.2005 schrieb Roland Scheidegger um 19:00:
Felix Kühling wrote:
Hi,
I want to share an idea that I had, which drastically improves the depth
buffer quality on Savage4 hardware. Maybe the same can be applied to
different hardware too.
Short version: reverse the
Am Sa, den 01.01.2005 schrieb Albert Vilella um 23:03:
The Savage hardware can handle W buffers too. In fact I experimented
with that and the quality looks good. But it doesn't work under all
circumstances. If the viewing transformation is changed in the middle of
rendering a frame, the
Am Sa, den 01.01.2005 schrieb Roland Scheidegger um 19:00:
Felix Kühling wrote:
[snip]
I'm a bit sceptical that this really improves depth buffer quality in
general. With D3D it is (if the hw supports it) possible to use a w
buffer instead of a z buffer, which has the same precision for far
Hi,
I want to share an idea that I had, which drastically improves the depth
buffer quality on Savage4 hardware. Maybe the same can be applied to
different hardware too.
Short version: reverse the depth range (z' = 1 - z) such that far
coordinates map to z'=0 and near coordinates to z'=1. Then
Am Do, den 30.12.2004 schrieb Adam Jackson um 20:20:
The goal: Load DRI drivers from the server's libglx, rather than the
software-based libGLcore.
Currently there are four server-side modules: dri, drm, glx, and GLcore.
There are also three client-side pieces: libGL, *_dri.so, and
Am Fr, den 31.12.2004 schrieb Dave Airlie um 7:28:
Okay some people have commented on the DRM CVS of late, and are unsure of
what is happening with it,
I'm very willing to drop the shared and linux directories into an archived
area but that will stop all support for Linux 2.4,
but at the
Am Do, den 30.12.2004 schrieb Dave Airlie um 9:36:
I'm a bit behind on this area, the patch looks fine, I'm just wondering
should it intersect with the drm_pci.c stuff for the mach64
Hmm, drm_pci.c looks like a OS-independent mechanism for allocating PCI
memory from within a DRM module.
Am Do, den 30.12.2004 schrieb Dave Airlie um 13:19:
drm_pci_alloc allows limiting the maximum address. Would it be too
hackish to pass this via map-offset to the drm_addmap ioctl?
Probably no need for the Xserver maps to care about a max address I'd hate
to overload anything in the
Am Do, den 30.12.2004 schrieb Felix Kühling um 15:06:
Am Do, den 30.12.2004 schrieb Dave Airlie um 13:19:
drm_pci_alloc allows limiting the maximum address. Would it be too
hackish to pass this via map-offset to the drm_addmap ioctl?
Probably no need for the Xserver maps to care
Am Mi, den 29.12.2004 schrieb John Lightsey um 1:41:
[snip]
With a new libGL in place, installing Mesa and drm CVS by hand isn't
that difficult and doesn't have to overwrite the packaged X server. It
would be nice if driconf had a way of overriding LIBGL_DRIVERS_PATH on a
per-user or global
Hi all,
After a few coding night shifts over the holidays the development of the
new Savage DRM driver finally reached a stage where I am pretty
confident that no more binary-incompatible changes to the interfaces
between DDX, DRM and the 3D driver will be needed. I uploaded my work in
the form
Hello DRI developers,
I'm asking for review of the attached patch. I submitted basically the
same patch on Oct 17th but I didn't get a definite go or no-go. I
need this for the new Savage DRM which I intend to commit to CVS soon.
The patch adds a new mapping type to the DRM for consistent PCI
Am Mi, den 29.12.2004 schrieb Felix Kühling um 21:54:
Hello DRI developers,
I'm asking for review of the attached patch.
[snip]
It happened again. :-/ Here is the patch. Really!
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30
17 matches
Mail list logo
