On Sun, 12 Sep 2004 20:45:18 -0400 (EDT), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer wrote:
On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
I think yourself and Linus's ideas for a locking scheme look good, I also
know they won't
On Mon, 2004-09-13 at 00:42, Dave Airlie wrote:
works well, and the X team decide to do a decent X on mesa-solo on Jons
super-DRM, now the super-DRM gets pushed via the X tree and distributions
start relasing kernels with it merged into it and it never goes into the
main tree... it won't
Jon Smirl wrote:
On Sat, 11 Sep 2004 17:21:22 +0100, Alan Cox [EMAIL PROTECTED] wrote:
On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
User 1's game queues up 20ms of 3D drawing commands.
Process swap to user 2. -quiesce() is going to take 20ms.
User 2's timeslice expires and we go back to user 1.
Hi all,
I have made some moderate progress in getting R300 3d to play nicely,
you can see the results at
http://volodya-project.sf.net/R300.php
So people with Radeon R300 or later cards that want to experiment with
their powerful GPUs can try out the code and mess with it at the level
On Sul, 2004-09-12 at 23:42, Dave Airlie wrote:
The worst things that will happen for all concerened is this:
Jon does all this work on a merged solution outside the kernel, and it
works well, and the X team decide to do a decent X on mesa-solo on Jons
super-DRM, now the super-DRM gets pushed
Vladimir Dergachev
I will look at all this as soon as i get back home :) I was doing
some research on this R300 stuff too but with little success.
By the way i got a little question regarding ACPI. Does any one
is looking for this issue (i guess it is a drm issue) ? Maybe
On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer wrote:
On Sun, 2004-09-12 at 20:45 -0400, Vladimir Dergachev wrote:
On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer wrote:
On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
I think yourself and Linus's ideas for a locking scheme look good, I also
On Llu, 2004-09-13 at 15:52, Vladimir Dergachev wrote:
However, if we want the switch from X to framebuffer to be as fast as
switching between different text consoles (assuming they have the same
resolution) and if we want to be able to run different Xservers on
different consoles or
On Mon, 13 Sep 2004 12:26:33 +0100, Alan Cox [EMAIL PROTECTED] wrote:
Well this is what I came up with so far. It creates a vga class so you
can bind the drivers to functions of the card (and we can add/remove
functions later as appropriate), tells functions about each other and
now implements
On Mon, 13 Sep 2004, Alan Cox wrote:
On Llu, 2004-09-13 at 15:52, Vladimir Dergachev wrote:
However, if we want the switch from X to framebuffer to be as fast as
switching between different text consoles (assuming they have the same
resolution) and if we want to be able to run different Xservers
Am Mittwoch, 8. September 2004 15:26 schrieb Roland Scheidegger:
Roland Scheidegger wrote:
Dieter Ntzel wrote:
Only some rejections in
src/mesa/main/texcompress_s3tc.c
I'll fix it, but you have to wait at least another full week.
Ok, new version can be found as usual at
On Llu, 2004-09-13 at 16:06, Jon Smirl wrote:
It also needs something to sort out both drivers using pci_drvdata()
to get to their private data. For example in the hotplug routines you
only get passed a pdev and you want to use that to locate your private
data.
The hotplug routines for vga
On Llu, 2004-09-13 at 16:20, Vladimir Dergachev wrote:
It depends how the various components fit together. Clearly for Radeon
you want everyone using the DMA command path when DRI is loaded. That
doesn't require one driver
Alan, do I understand right that you are proposing to have two
On Mon, 2004-09-13 at 08:30, Dieter Nützel wrote:
Am Mittwoch, 8. September 2004 15:26 schrieb Roland Scheidegger:
Roland Scheidegger wrote:
Dieter Nützel wrote:
Only some rejections in
src/mesa/main/texcompress_s3tc.c
I'll fix it, but you have to wait at least another full
On Mon, 2004-09-13 at 10:52 -0400, Vladimir Dergachev wrote:
So, as Jon rightly points out the multiple drivers scheme only makes
sense in the current usage patter - you either use X or framebuffer, never
both at the same time and you consider a few seconds per switch normal.
You are
On Mon, 13 Sep 2004 10:54:50 -0400 (EDT), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
Vladimir Dergachev
I will look at all this as soon as i get back home :) I was doing
some research on this R300 stuff too but with little success.
By the way i got a little
Doesn't the base platform need to be designed to also treat individual
heads as resources?
fbdev only sets the mode on a single head. My cards have more that one
head. When I tried adding mode setting to DRM so that I could handle
my other heads there was a big uproar that fbdev owns mode setting
On Mon, 2004-09-13 at 02:05 -0400, Alex Deucher wrote:
On Sun, 12 Sep 2004 20:45:18 -0400 (EDT), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer wrote:
On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
I think yourself and
By the way i got a little question regarding ACPI. Does any one
is looking for this issue (i guess it is a drm issue) ? Maybe it
is a part of the on going work of drm restructuration.
What ACPI issue ? If you mean that you can't suspend, this is because the
video card loses its state so completely
On Llu, 2004-09-13 at 17:28, Jon Smirl wrote:
Doesn't the base platform need to be designed to also treat individual
heads as resources?
Already covered - although at the moment the question is open about who
tells the vga generic code It has 4 heads ?
Had a look over your class code - its
How's this going to work with hotplug? Hotplug works by associating a
device with a driver by the PCI ID table contained in the driver. Both
the fbdev and DRI drivers currently contain the same PCI IDs for the
cards that the chipsets they support.
So when a card gets hotplugged, which driver do I
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
5:00PM EDT or 2:00PM PDT, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous
It wasn't intended to stay in the PCI layer. Something needs to be
done about hotplugging bridges. There aren't callouts from the PCI
layer for that. A hotplugged bridge can be capable of VGA routing and
have VGA devices behind it. I just started off in the PCI layer while
I figured out what hooks
On Monday, September 13, 2004 11:11 am, Jon Smirl wrote:
The IA64 people want a file/ioctl interface on the /dev/vga0 devices
so that they can issue control calls to the active device in each VGA
space
I think ppc and sparc want this too, we'll use it for issuing legacy in/out.
Thanks,
Jesse
How would any of these plans handle power management and ACPI events?
I'd like to be able to suspect my laptop with the DRI enabled, or have
the DDX (or whatever) handle acpi lid and button events or put the
chip into various power modes.
Alex
On Mon, 13 Sep 2004 08:20:58 -0700 (PDT), Linus
I've updated the drm.watchdog.2.patch
http://marc.theaimsgroup.com/?l=dri-develm=108551485018672w=2
to latest DRM CVS and it works together with
ati.unlock.1.patch and ati.drm-r300-version.1.patch
http://marc.theaimsgroup.com/?l=dri-develm=108551675805810w=2
when the UT2003/2004 lockups ('Shock
As someone mentioned before, in OpenGL 2.0 generic attributes (set by
calling glVertexAttrib) do not alias with conventional attributes.
This conflicts with GL_NV_vertex_program and changes the policy
defined in GL_ARB_vertex_program (where aliasing was optional).
The GL_ARB_vertex_shader
Am Montag, 13. September 2004 22:08 schrieb Dieter Nützel:
I've updated the drm.watchdog.2.patch
http://marc.theaimsgroup.com/?l=dri-develm=108551485018672w=2
to latest DRM CVS and it works together with
ati.unlock.1.patch and ati.drm-r300-version.1.patch
On Monday 13 September 2004 03:21 pm, Alex Deucher wrote:
How would any of these plans handle power management and ACPI events?
I'd like to be able to suspect my laptop with the DRI enabled, or have
the DDX (or whatever) handle acpi lid and button events or put the
chip into various power
On Mon, 13 Sep 2004 16:35:51 -0400, Anish Mistry [EMAIL PROTECTED] wrote:
On Monday 13 September 2004 03:21 pm, Alex Deucher wrote:
How would any of these plans handle power management and ACPI events?
I'd like to be able to suspect my laptop with the DRI enabled, or have
the DDX (or
Alex Deucher wrote:
How would any of these plans handle power management and ACPI events?
I'd like to be able to suspect my laptop with the DRI enabled, or have
the DDX (or whatever) handle acpi lid and button events or put the
chip into various power modes.
Alex
Since I've been doing a little
On Monday 13 September 2004 04:41 pm, Alex Deucher wrote:
On Mon, 13 Sep 2004 16:35:51 -0400, Anish Mistry [EMAIL PROTECTED] wrote:
On Monday 13 September 2004 03:21 pm, Alex Deucher wrote:
How would any of these plans handle power management and ACPI events?
I'd like to be able to
What is the status on the M10 line of ATI GPUs (Mobility FireGL [T2]) so
far? I am a happy new owner of a Notebook with this chip but the only way
to enable DRI with this so far was the dreaded fglrx driver. Is trying CVS
worth a shot for me or isnt anything here yet for this GPU?
br,
Fionn
Dieter Nützel wrote:
Am Montag, 13. September 2004 22:08 schrieb Dieter Nützel:
I've updated the drm.watchdog.2.patch
http://marc.theaimsgroup.com/?l=dri-develm=108551485018672w=2
to latest DRM CVS and it works together with
ati.unlock.1.patch and ati.drm-r300-version.1.patch
On Mon, 13 Sep 2004 16:41:06 -0400
Alex Deucher [EMAIL PROTECTED] wrote:
On Mon, 13 Sep 2004 16:35:51 -0400, Anish Mistry [EMAIL PROTECTED] wrote:
On Monday 13 September 2004 03:21 pm, Alex Deucher wrote:
How would any of these plans handle power management and ACPI events?
I'd like to
Brian Paul wrote:
As someone mentioned before, in OpenGL 2.0 generic attributes (set by
calling glVertexAttrib) do not alias with conventional attributes. This
conflicts with GL_NV_vertex_program and changes the policy defined in
GL_ARB_vertex_program (where aliasing was optional).
The
On Mon, Sep 13, 2004 at 10:33:26PM +0200, Fionn Behrens wrote:
What is the status on the M10 line of ATI GPUs (Mobility FireGL [T2]) so
far? I am a happy new owner of a Notebook with this chip but the only way
to enable DRI with this so far was the dreaded fglrx driver. Is trying CVS
worth a
Ian Romanick wrote:
Brian Paul wrote:
As someone mentioned before, in OpenGL 2.0 generic attributes (set by
calling glVertexAttrib) do not alias with conventional attributes.
This conflicts with GL_NV_vertex_program and changes the policy
defined in GL_ARB_vertex_program (where aliasing was
Hi,
while I've had less success (read: hard locks and reboots) with the recently
drmtest and r300_demo, I did use glxtest to find out registers of the R300.
Basically, what I did is run a small GL program, get the command buffer,
make some small changes and rerun. Often, this results in only a
On Mon, 13 Sep 2004 23:08:07 +0200, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Dieter Nützel wrote:
Am Montag, 13. September 2004 22:08 schrieb Dieter Nützel:
I've updated the drm.watchdog.2.patch
http://marc.theaimsgroup.com/?l=dri-develm=108551485018672w=2
to latest DRM CVS and it works
On Mon, 13 Sep 2004 13:42:19 -0700, David Bronaugh
[EMAIL PROTECTED] wrote:
Alex Deucher wrote:
How would any of these plans handle power management and ACPI events?
I'd like to be able to suspect my laptop with the DRI enabled, or have
the DDX (or whatever) handle acpi lid and button events
Brian Paul wrote:
Ian Romanick wrote:
Brian Paul wrote:
It looks like the only way to tell the difference between the two
extensions is !!ARBvp1.0 vs. !!VP1.0 in the program text. I
suppose we could track the glVertexAttrib3fvARB as non-aliased, but
compile a !!VP1.0 program to use the attribs
Hi,
the return value of drm_probe seems to be ignored when probing in
stealth mode. I saw a user logfile where it printed
[drm:drm_probe] *ERROR* Cannot initialize the agpgart module.
but apparently the driver continued loading. Should drm_init fail if
drm_probe returns something non-zero? Or
Ian Romanick wrote:
Brian Paul wrote:
Ian Romanick wrote:
Brian Paul wrote:
It looks like the only way to tell the difference between the two
extensions is !!ARBvp1.0 vs. !!VP1.0 in the program text. I
suppose we could track the glVertexAttrib3fvARB as non-aliased, but
compile a !!VP1.0
On Tuesday 14 September 2004 00:28, Jon Smirl wrote:
Doesn't the base platform need to be designed to also treat individual
heads as resources?
fbdev only sets the mode on a single head. My cards have more that one
head. When I tried adding mode setting to DRM so that I could handle
my other
Add pci_enable_device()/pci_disable_device. In the past, drivers often worked
without this, but it is now required in order to route PCI interrupts
correctly.
Evan Paul Fletcher found this problem with 2.6.9-rc1-mm4 and X.org 6.8.0
and verified that this patch fixes it.
Signed-off-by: Bjorn
This causes problems when DRI and fb are loaded and you unload dri.. guess
what happens your fb??, or it does in theory I might have time to practice
later,
now the quick fix is to take the stealth/non-stealth code from CVS which
we know works or we wait for Alan to finish his vga device code
Hi Alex and everyone
http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff
the code still needs the develdri #ifdefs added.
Savage dri works quite well (again) on xorg 6.8, except on xv video mode
with some mpegs, as I reported at first time.
The good news is direct rendering is enabled
On Tue, 14 Sep 2004 02:21:21 +0100, Sérgio Monteiro Basto
[EMAIL PROTECTED] wrote:
Hi Alex and everyone
http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff
the code still needs the develdri #ifdefs added.
I'll probably commit the merge of the savage DRI driver to xorg cvs in
the
49 matches
Mail list logo
