Michel Dänzer wrote:
On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote:
Alan Cox wrote:
The log design presents numerous opportunities for rogue processes to do
bad things. At some level, that's inherent in the nature of direct
rendering. If you don't trust the processes, don't
On Wed, 2005-08-24 at 09:18 -0600, Brian Paul wrote:
Michel Dänzer wrote:
On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote:
Alan Cox wrote:
Other stuff like textures is merely annoyance value. Knowing who owned a
block for cleanup matters and the DRI lock/mem handling on some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
1. I'd like an allocator that can be used outside/independent of the
Xserver. Specifically, an allocator that EGL and EGL drivers can use.
2. There needs to be a way to share memory blocks between processes.
So that an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michel Dänzer wrote:
On Wed, 2005-08-24 at 09:18 -0600, Brian Paul wrote:
1. The location of the object in memory (perhaps the framebuffer has
to be at the start of memory).
2. Particular byte/word alignments
3. Can we use VRAM and/or AGP
This patch contains the following small cleanups:
- make two needlessly global functions static
- drm_sysfs.c: every file should #include the header with the prototypes
of the global functions it is offering
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
1. I'd like an allocator that can be used outside/independent of the
Xserver. Specifically, an allocator that EGL and EGL drivers can use.
2. There needs to be a way to share memory blocks between
The framebuffer (including color, Z, stencil, etc)
Pbuffers
Renderbuffer/Framebuffer objects
Pixel/Vertex buffer objects
Texture images
OpenGL miscellaneous (e.g. vertex/fragment programs)
X server miscellaneous (pixmap cache, etc)
Most of these are fairly static objects.
1. The location
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Ian Romanick wrote:
In the prototype code that I posted to the list several months ago,
these four things were handled together. Each object has an associated
region ID. The region IDs are allocated to a process by the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
On Wed, 2005-08-24 at 08:47 -0700, Ian Romanick wrote:
Brian Paul wrote:
I think it would be worthwhile to start a specification document for
this project (or perhaps a wiki page) where the requirements, issues and
proposed
Alan Cox wrote:
The framebuffer (including color, Z, stencil, etc)
Pbuffers
Renderbuffer/Framebuffer objects
Pixel/Vertex buffer objects
Texture images
OpenGL miscellaneous (e.g. vertex/fragment programs)
X server miscellaneous (pixmap cache, etc)
Most of these are fairly static objects.
On 8/24/05, Vitja Makarov [EMAIL PROTECTED] wrote:
Hi!
xorg from cvs works with my card just perfect, it solves some fglrx bugs(xv
doesn't work after s3 resume).
drm. I've added following string to drm_pciids.txt:
0x1002 0x5955 CHIP_RS300|CHIP_IS_PCIE|CHIP_IS_MOBILITY
ATI Radeon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Ian Romanick wrote:
1. Video card has 8MB.
2. 1MB of the card memory is allocated for the front buffer and pinned.
3. Process A allocates (and commits) a 7MB region for a big texture.
4. Process B allocates (and commits) a 2MB
On Mer, 2005-08-24 at 11:18 -0600, Brian Paul wrote:
2. 1MB of the card memory is allocated for the front buffer and pinned.
3. Process A allocates (and commits) a 7MB region for a big texture.
4. Process B allocates (and commits) a 2MB region for a texture. To do
this, it kick out part
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Ian Romanick wrote:
In the prototype code that I posted to the list several months ago,
these four things were handled together. Each object has an associated
region ID. The region IDs are allocated to a
[ this is the card that crashes when I try to do anything 3D with it.]
###
:02:07.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro
215GP (rev 5c)
###
(II) ATI(1): VESA BIOS detected
(II) ATI(1): VESA VBE Version 2.0
(II) ATI(1): VESA VBE Total Mem: 8192 kB
(II) ATI(1):
On 8/24/05, Alan Grimes [EMAIL PROTECTED] wrote:
[ this is the card that crashes when I try to do anything 3D with it.]
you might try some of the driver options for 3d:
#ifdef XF86DRI_DEVEL
{
ATI_OPTION_IS_PCI,
force_pci_mode,
OPTV_BOOLEAN,
{0, },
On Fri, 15 Jul 2005 12:04:43 +0200
Rune Petersen [EMAIL PROTECTED] wrote:
Just to add that login (KDM) is more or less fine (cursor is corrupted
untill its moved).
Attached diff should fix this temporarily.
Im still unsure why MaxSurfaceWidth ends up affecting piches and stuff...
--
Aapo
On 8/24/05, Aapo Tahkola [EMAIL PROTECTED] wrote:
On Fri, 15 Jul 2005 12:04:43 +0200
Rune Petersen [EMAIL PROTECTED] wrote:
Just to add that login (KDM) is more or less fine (cursor is corrupted
untill its moved).
Attached diff should fix this temporarily.
Im still unsure why
Alex Deucher wrote:
On 8/24/05, Aapo Tahkola [EMAIL PROTECTED] wrote:
On Fri, 15 Jul 2005 12:04:43 +0200
Rune Petersen [EMAIL PROTECTED] wrote:
Just to add that login (KDM) is more or less fine (cursor is corrupted
untill its moved).
Attached diff should fix this temporarily.
Im still
Michel Dänzer wrote:
Security is more than just the memory manager. To enforce video memory
protection, we'd have to audit the code and add memory protection to
existing drm modules. That is quite a lot of work, and requires
extensive knowledge of each card. So I don't think it's worth the
On Thu, 2005-08-18 at 14:19 -0500, Alan Grimes wrote:
I installed the latest CVS DRM source a few days ago. (the kernel
modules), and it is still broken! =(
Maybe if someone could point me in the general vicinity of the culprit,
I could take a whack at it myself...
[EMAIL PROTECTED]
I think this should be fixed in CVS, though I couldn't test due to libGL
issues. Could you test and see if it works now?
I just tried a build and got this error:
[EMAIL PROTECTED] ~/source/Mesa $ make linux-dri-x86
(cd configs rm -f current ln -s linux-dri-x86 current)
make default
On Wed, 2005-08-24 at 23:58 -0500, Alan Grimes wrote:
I think this should be fixed in CVS, though I couldn't test due to libGL
issues. Could you test and see if it works now?
I just tried a build and got this error:
[EMAIL PROTECTED] ~/source/Mesa $ make linux-dri-x86
(cd configs rm
^^^ Just install libdrm from DRM CVS. It's a requirement now.
IN FILE xf86drm.h AND include/GL/internal/dri_interface.h CHANGE
#include drm.h
#include drm/drm.h
--
Friends don't let friends use GCC 3.4.4
GCC 3.3.6 produces code that's twice as fast on x86!
Non-sequiter item:
PPRACER: Works but has nasty texture bug affecting the ground textures..
(Problem disappears when I run it on the other, unaccelerated monitor..)
n64 emulator: Par behavior (sucks due to my lack of coding skill...)
flightgear: Works, no obvious problems.
Celestia: Works, no obvious problems
25 matches
Mail list logo
