On Sat, 2004-09-11 at 06:19 +0100, Dave Airlie wrote:
You're probably right, but it still doesn't follow that this driver must
include all the fbdev and DRM code as well. Both fbdev and the DRM could
use that driver, e.g., just like ide_cd and ide_disk use the IDE driver.
I think your
I still haven't seen a complete logical chain leading to that
conclusion.
The lowlevel driver could provide all the necessary arbitration and
safety measures to prevent the two from stepping on each other's toes.
The thing is I know of no way to provide arbitration in such a way as to
permit
Dave Airlie wrote:
2D and 3D _are_ to most intents and purposes different functions. They
are as different as IDE CD and IDE disk if not more so.
stop saying this, it isn't true and hasn't been for years, for the mach64
type cards I'd agree, for something even like the i810 this isn't
true, most
Vladimir Dergachev wrote:
Alan,
I would like to disagree with you.
On Fri, 10 Sep 2004, Alan Cox wrote:
On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing lowlevel
VGA
Alan Cox wrote:
On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing lowlevel
VGA device drivers until someone addresses why it is acceptable to have
two separate driver
On Saturday 11 September 2004 13:19, Dave Airlie wrote:
The other thing I think some people are confusing is 2.4 fbdev and 2.6...
there is no console support in 2.6 fbdev drivers, it is all in the fbcon
stuff, so the fbdev drivers are only doing 2d mode setting and monitor
detection, some
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Vladimir Dergachev wrote:
Alan,
I would like to disagree with you.
On Fri, 10 Sep 2004, Alan Cox wrote:
On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
If the kernel developers can address this point I would be most
If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing lowlevel
VGA device drivers until someone addresses why it is acceptable to have
two separate driver driving the same hardware for video and not for
anything else..
--- Christoph Hellwig [EMAIL PROTECTED] wrote:
If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing
lowlevel
VGA device drivers until someone addresses why it is acceptable to
have
two separate driver driving
Bugs item #1026326, was opened at 2004-09-11 13:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=100387aid=1026326group_id=387
Category: None
Group: None
Status: Open
Priority: 5
On Sad, 2004-09-11 at 00:25, Jon Smirl wrote:
I need a major number for the VGA device.
Use one of the experimental ones (see Documentation/devices.txt). As and
if the driver becomes mainstream kernel material apply for one via
LANANA. I don't know what the *BSD procedures are.
On Sad, 2004-09-11 at 00:36, Jon Smirl wrote:
inter_module can't be removed until we move to the drm_core design
with personality modules
Of course it can go. You just fix up the DRI to start using
try_module_get(). Actually when you have the video class driver layer it
all comes for free
On 11.09.2004, at 14:50, Alan Cox wrote:
On Sad, 2004-09-11 at 00:25, Jon Smirl wrote:
I need a major number for the VGA device.
Use one of the experimental ones (see Documentation/devices.txt). As
and
if the driver becomes mainstream kernel material apply for one via
LANANA. I don't know what
On Sad, 2004-09-11 at 00:24, Dave Airlie wrote:
stop saying this, it isn't true and hasn't been for years, for the mach64
type cards I'd agree, for something even like the i810 this isn't
Its true. Its still true whether you demand people stop saying it or
not.
true, most cards have two paths
On Sad, 2004-09-11 at 01:47, Vladimir Dergachev wrote:
One driver per device. I.e. one driver per *physical* device.
This is a religion the kernel doesn't follow. Its a pointless
religion
Lastly, one point that you appear to have missed: DRM does DMA transfers
(among everything else). FB
On Sad, 2004-09-11 at 01:50, Dave Airlie wrote:
So the IDE-CD driver and IDE-disk drivers both program registers on the
IDE controller directly.. oh no the ide driver seems to do that.. this is
FUD,
Its a shame the DRI people having nothing better to do than tell folks
to shut up or mutter FUD
On Fri, 10 Sep 2004 19:52:55 +0200, Marcello Maggioni [EMAIL PROTECTED] wrote:
Hi all ,
I've posted for AA few days ago, and I'm here again :)
Now the problem is with UT2004 .
My card is a 3D prophet Radeon 8500LE with R200 ,My drivers are the
lastest taken yesterday from CVS.
I've
On Sad, 2004-09-11 at 06:19, Dave Airlie wrote:
1. It doesn't matter where the code lives, fbdev/DRM need to start talking
about things
It matters immensely what the divison is because people talking doesn't
scale ..
I'm interested in seeing what Alan comes up with, even in a non-working
On Sad, 2004-09-11 at 08:11, Vladimir Dergachev wrote:
The thing is I know of no way to provide arbitration in such a way as to
permit other code to access PLL registers directly.
This arises solely because the DRM and framebuffer drivers cannot find
each other and have no shared structures.
anything else.. (remembering graphics cards are not-multifunction cards -
like Christoph used as an example before - 2d/3d are not separate
functions...)...
We've addressed this before. Zillions of drivers provide multiple
functions to multiple higher level subsystems. They don't all have to
be
On Sad, 2004-09-11 at 10:20, Antonino A. Daplas wrote:
In theory, one can have a process (kernel or userland) change the video
mode, then provide the in-kernel driver with the necessary information
about the layout of the framebuffer. When this in-kernel driver gets the
necessary information,
On Sat, 11 Sep 2004 13:53:41 +0100, Alan Cox [EMAIL PROTECTED] wrote:
On Sad, 2004-09-11 at 00:36, Jon Smirl wrote:
inter_module can't be removed until we move to the drm_core design
with personality modules
Of course it can go. You just fix up the DRI to start using
try_module_get().
Thus at the very least you would want to mandate the availability of mode
setting part of FB when DRM is loaded - and they you can just as well link
the relevant code together.
You are making a generic assumption for a single card specific problem
in a specific situation. That leads to bad
On Sat, 11 Sep 2004 13:27:27 +0100, Christoph Hellwig [EMAIL PROTECTED] wrote:
If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing lowlevel
VGA device drivers until someone addresses why it is acceptable to have
On Sat, 11 Sep 2004 17:20:38 +0800, Antonino A. Daplas
[EMAIL PROTECTED] wrote:
On Saturday 11 September 2004 13:19, Dave Airlie wrote:
The other thing I think some people are confusing is 2.4 fbdev and 2.6...
there is no console support in 2.6 fbdev drivers, it is all in the fbcon
stuff,
On Sat, Sep 11, 2004 at 12:11:13PM -0400, Jon Smirl wrote:
The resource reservation conflicts are already solved in the current
DRM code. Most of the changes are in kernel and the rest are in the
pipeline. DRM loads in two modes, primary where it behaves like a
normal Linux driver and stealth
On Sat, Sep 11, 2004 at 05:49:30AM -0700, Mike Mestnik wrote:
Not to step on toes, but... From what I can tell the idea is to add code
into FB that calles functions in the DRM and vice vers. This would seam
to add another ABI. Unless the code gets linked into one module, this
idea has been
On Sat, 11 Sep 2004 15:33:43 +0100, Alan Cox [EMAIL PROTECTED] wrote:
For example I can see the radeon DRM driver providing
-queue_commands()
-quiesce()
to the 2D driver. And the 2D driver providing
-define_fb_layout() for DRI to provide to X
That way it is
On Sat, 11 Sep 2004, Jon Smirl wrote:
The resource reservation conflicts are already solved in the current
DRM code. Most of the changes are in kernel and the rest are in the
pipeline. DRM loads in two modes, primary where it behaves like a
normal Linux driver and stealth where it uses the
On Sat, 11 Sep 2004, Alan Cox wrote:
On Sad, 2004-09-11 at 16:53, Vladimir Dergachev wrote:
Lastly, I am not saying you have to put all the code in the same file.
All I am saying we can mandate that all Radeon HW specific code is linked
in one module - and this would make things easier for
Coprocessor 3D mode is deeply pipelined
2D mode is immediate
How can you build a system that process swaps between these two modes?
The 3D pipeline has to be emptied before you can enter 2D immediate
mode.
My solution is to leave the coprocessor always running and convert
everything to use the
On Sad, 2004-09-11 at 18:02, Linus Torvalds wrote:
My personal preference for this whole mess has always been the silly
driver that isn't even hardware-specific, and really does _nothing_ on
its own. This one would be the only thing that actually reserves the IO
regions and owns the card
On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
This is a good point - if we don't need DMA or 3d acceleration we can
reduce memory footprint. This would seem that current DRM driver would
need to be dependent on whatever driver contains the mode setting code.
What do you think ?
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.
User 1 queues up another 20ms.
User 2's editor is never going to function.
If
On Sad, 2004-09-11 at 18:13, Jon Smirl wrote:
Coprocessor 3D mode is deeply pipelined
2D mode is immediate
Card dependant.
How can you build a system that process swaps between these two modes?
The 3D pipeline has to be emptied before you can enter 2D immediate
mode.
My solution is to
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.
User 1 queues up another 20ms.
User 2's editor is never going to function.
If
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.
User 1
On Sat, 11 Sep 2004, Jon Smirl wrote:
Coprocessor 3D mode is deeply pipelined
2D mode is immediate
Now it is _you_ who confuse 3D mode and 2D mode.
THERE IS NO SUCH THING.
There is only hardware.
How can you build a system that process swaps between these two modes?
You don't switch
On Sat, 11 Sep 2004, Alan Cox wrote:
On Sad, 2004-09-11 at 18:02, Linus Torvalds wrote:
My personal preference for this whole mess has always been the silly
driver that isn't even hardware-specific, and really does _nothing_ on
its own. This one would be the only thing that actually
On Sat, 11 Sep 2004, Alan Cox wrote:
On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
This is a good point - if we don't need DMA or 3d acceleration we can
reduce memory footprint. This would seem that current DRM driver would
need to be dependent on whatever driver contains the mode
On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
[EMAIL PROTECTED] wrote:
Jon, you want to get to that Final step is to integrate the chip specific
code from DRM and fbdev. Alan doesn't even want to get there. I think
Alan just wants some simple infrastructure to let everybody play
On Sat, 2004-09-11 at 13:13 -0400, Jon Smirl wrote:
Coprocessor 3D mode is deeply pipelined
2D mode is immediate
Have you looked at the radeon X driver acceleration code in the last
couple of years?
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software
On Sat, 11 Sep 2004 13:49:34 -0400 (EDT), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
On Sat, 11 Sep 2004, Alan Cox wrote:
On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
This is a good point - if we don't need DMA or 3d acceleration we can
reduce memory footprint. This would seem
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 Sat, 11 Sep 2004, Jon Smirl wrote:
My view was that PLL setting (and setting of a fixed mode) would be done
in DRM driver. This way it would be able to restore previous settings
after a lockup or respond to FB request to change modes.
However the decision of which mode to set, as well as where
On Sat, 11 Sep 2004 14:05:54 -0400 (EDT), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
All register writes would occur in the driver. There is nothing
stopping the code that computes those register values from running in
user space.
A example mode setting IO would take:
display buffer
On Sat, 11 Sep 2004, Jon Smirl wrote:
On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
[EMAIL PROTECTED] wrote:
Jon, you want to get to that Final step is to integrate the chip specific
code from DRM and fbdev. Alan doesn't even want to get there. I think
Alan just wants some
On Sat, 11 Sep 2004, Jon Smirl wrote:
On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
[EMAIL PROTECTED] wrote:
Jon, you want to get to that Final step is to integrate the chip specific
code from DRM and fbdev. Alan doesn't even want to get there. I think
Alan just wants some simple
On Sat, 2004-09-11 at 10:13, Jon Smirl wrote:
Coprocessor 3D mode is deeply pipelined
2D mode is immediate
How can you build a system that process swaps between these two modes?
The 3D pipeline has to be emptied before you can enter 2D immediate
mode.
My solution is to leave the
Alan, if you will commit Redhat to implementing all of the features
referenced in this message:
http://lkml.org/lkml/2004/8/2/111
then I'll back off and go work on the X server.
Use whatever mechanism you want, but implement all of the features.
There are two main goals:
#1) Get mesa-solo
On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote:
Alan, if you will commit Redhat to implementing all of the features
referenced in this message:
You definitly start sounding like Hans ;-)
---
This SF.Net email is sponsored by: YOU
Alan Cox 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.
User 1 queues up another 20ms.
User 2's editor is never going to
On Sat, 11 Sep 2004 22:06:14 +0100, Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote:
Alan, if you will commit Redhat to implementing all of the features
referenced in this message:
You definitly start sounding like Hans ;-)
Getting the
On Sat, 11 Sep 2004 13:29:33 -0700, Eric Anholt [EMAIL PROTECTED] wrote:
To summarize, there is no 2d mode and 3d mode. Please stop
referring to it. If you were actually trying to talk about
synchronization for MMIO vs DMA command submission (which is and would
You are right on all of this,
Marcello Maggioni wrote:
My card is a 3D prophet Radeon 8500LE with R200 ,My drivers are the
lastest taken yesterday from CVS.
I've downloaded the demo , and the game seemed to run fine at
least until I tried to shoot with a Shock Rifle .
Just after the laser beam started to run from my rifle
On Sun, 12 Sep 2004 00:34:01 +0200, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Marcello Maggioni wrote:
My card is a 3D prophet Radeon 8500LE with R200 ,My drivers are the
lastest taken yesterday from CVS.
I've downloaded the demo , and the game seemed to run fine at
least until I
On Sat, 11 Sep 2004 11:54:49 -0400, Jon Smirl [EMAIL PROTECTED] wrote:
On Sat, 11 Sep 2004 13:53:41 +0100, Alan Cox [EMAIL PROTECTED] wrote:
On Sad, 2004-09-11 at 00:36, Jon Smirl wrote:
inter_module can't be removed until we move to the drm_core design
with personality modules
Of
What about if you want to use fb when in text mode (Because you get
200x75 on a 1600x1200 screen) AND run DRI because the rest of the time
you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7
back forth between X fb... (i.e. how I currently use it but with
On Sad, 2004-09-11 at 22:37, Jon Smirl wrote:
But since I've written most of the code so far I get to pick the
details of the implementation.
Umm thats what happened to ruby and thats what happened to KGI.
If Alan would instead like to pick the
details I've offered to withdraw if he'll
On Sat, 11 Sep 2004, Jon Smirl wrote:
On Sat, 11 Sep 2004 11:13:17 -0700 (PDT), Linus Torvalds
[EMAIL PROTECTED] wrote:
So I'd much rather see the hey, somebody else might have stolen my
hardware, and now I need to re-initialize as the _basic_ model. That just
allows others to do their
--- Alan Cox [EMAIL PROTECTED] wrote:
On Sad, 2004-09-11 at 16:53, Vladimir Dergachev wrote:
Lastly, I am not saying you have to put all the code in the same
file.
All I am saying we can mandate that all Radeon HW specific code is
linked
in one module - and this would make things
On 12.09.2004, at 01:58, Jon Smirl wrote:
We know how to remove the DRM() macros and inter_module stuff by
switching to a drm_core library model. DaveA has already coded up a
prototype. We aren't switching because people are objecting to the
change. I'm not sure what the status of the objections
62 matches
Mail list logo
