A small update:
I also made a r300_demo program that paints some triangles - it
should be easier to setup than drmtest. This program should work on Radeon
Mobility M10 cards (i.e. RV350).
best
Vladimir Dergachev
On Sat, 11 Sep 2004
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 is
--- 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 mak
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 t
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 w
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 own thing, and play well together. More
> 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
> unacce
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 module
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 a
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 rifl
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 o
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 ;-)
Gett
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 f
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: YO
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 runni
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 c
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 in
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 wa
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:
> > di
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
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
fai
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
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 DÃnzer | Debian (powerpc), X and DRI developer
Libre software e
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 pla
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 setting
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 act
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 swi
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.
>
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
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
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 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
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 DM
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 de
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
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
>
> Th
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 b
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 stea
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
> >
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 developers.
And if I want dri but
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 ha
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 decisio
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_g
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 informati
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 co
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.
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 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.
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 F
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).
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 pat
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 the
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 anyw
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.
-
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=detail&atid=100387&aid=1026326&group_id=387
Category: None
Group: None
Status: Open
Priority: 5
Submit
--- 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
> 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 els
--- 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 wo
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 p
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 drivin
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 devi
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 c
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 other
64 matches
Mail list logo
