Linus Torvalds wrote:
> Keith,
> I've got a silly question for you..
>
> Why do you need a kernel driver at all for the R200?
I go into your mail below, but the only good answer I have is:
1) To allow us to mmap the framebuffer, agp and mmio regions (or to handle
mmio
for us without u
On Tue, 2002-06-18 at 10:57, Keith Whitwell wrote:
>
> > - IOIO and IOMEM access
> >
> > iopl() gives access to IOIO
> > mmap() and AGP driver gives access to IOMEM/AGP
> >
> > IOIO is actualy slightly slower in CPL3 than in CPL0, but it's
> > slower in CPU cycles, not in IO cy
>HOWEVER, if you tied the GART mapping to the DRM lock, you might be ok.
>That gives you the required system exclusion, and if you make it an
>explicit "get my GART context" function that is only called under the DRM
>lock _and_ only called when you actually need the AGP access, you also
>avoid th
> - Interrupts
>
> You don't use these right now, and as far as I can tell the main
> reason for using them would be to just synchronize page flipping
> with the framerate. No?
Which would be nice to have proper frame-sync on interlaced display
(especially with Michel Danzer wor
Benjamin Herrenschmidt wrote:
>>HOWEVER, if you tied the GART mapping to the DRM lock, you might be ok.
>>That gives you the required system exclusion, and if you make it an
>>explicit "get my GART context" function that is only called under the DRM
>>lock _and_ only called when you actually need
>What are you actually saying, that pages mapped in agp can't be written
>by any
>means, or just that they can't be written through the agp address range?
Through the AGP address range. I work around this by hacking the DRM to
map the RAM pages directly in drmMap using specific vmops and a hacke
Quickly and
Easily
Improve YOUR Credit to
PERFECT 'Bank' Rated
Credit Status!
Click here now for FULL FREE details!
© 2002 All rights reserved.
Unsubscribe
--
Keith Whitwell wrote:
> Benjamin Herrenschmidt wrote:
>
>>> HOWEVER, if you tied the GART mapping to the DRM lock, you might be ok.
>>> That gives you the required system exclusion, and if you make it an
>>> explicit "get my GART context" function that is only called under
>>> the DRM
>>> lock
On Tue, 18 Jun 2002 [EMAIL PROTECTED] wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> To: Linus Torvalds <[EMAIL PROTECTED]>,
>
> > - Interrupts
> >
> > You don't use these right now, and as far as I can tell the main
> > reason for using them would be to just synchronize pa
Hi, I'm working at a University where they would like me to start the
development of video drivers for a ATI Radeon or 3Dlabs card to run on Alpha
Linux(Red Hat).
I've read all the documentation on your website, and some more general
information in other places but I'm having a problem seeing whe
On Tue, 2002-06-18 at 17:31, [EMAIL PROTECTED] wrote:
> Hi, I'm working at a University where they would like me to start the
> development of video drivers for a ATI Radeon or 3Dlabs card to run on Alpha
> Linux(Red Hat).
I'd expect the radeon driver to work on alpha, have you tried it?
> I've
On Mon, 17 Jun 2002, Benjamin Herrenschmidt wrote:
>
> > mmap() and AGP driver gives access to IOMEM/AGP
>
> That one is problematic. I don't support the mmap interface properly
> on Apple chipsets for example, because they don't support the AGP
> aperture beeing accessed by the CPU.
I assu
[EMAIL PROTECTED] wrote:
>
> Hi, I'm working at a University where they would like me to start the
> development of video drivers for a ATI Radeon or 3Dlabs card to run on Alpha
> Linux(Red Hat).
I see uwo.ca in your e-mail address. Is the University of Waterloo,
Onterio? Are you the only stud
On Tue, 18 Jun 2002, Linus Torvalds wrote:
>
> So moving pages that way is definitely not cheap either. Hmm.
In fact, considering the cache and multi-CPU overhead, it's likely to be
faster to just memcpy() the damn thing from a regular cached mapping to an
existing AGP-mapped page. Which is pr
On Mon, Jun 17, 2002 at 02:26:49AM +0200, Michel Dänzer wrote:
> - Portability fixes for the new driver:
> http://penguinppc.org/~daenzer/DRI/radeon-endianness.diff
> Feedback and testing appreciated as always, in particular on the changes
> to the x86 specific parts.
I've been running with this
Hi all
Finally, I've got my kernel built with gcc 3.1 (actually, my problems
were in some mystical gcc296 in some compat package). And - wow - mach64
0-0-4 branch works for me! Great thanks to everyone. Even 2D seems to be
OK these days. The only problem I noticed is VT switching. When I switch
t
No, its the University of Western Ontario
Its not a class assignment, I'm working for SHARCNet (see this for more info
http://www.sharcnet.ca/org_corner/) at UWO. I was hired for the summer by one of
the professors in charge of SHARCNet to get video drivers working and optimized
on Compaq ES45 se
No, its the University of Western Ontario
Its not a class assignment, I'm working for SHARCNet (see this for more info
http://www.sharcnet.ca/org_corner/) at UWO. I was hired for the summer by one
of
the professors in charge of SHARCNet to get video drivers working and optimized
on Compaq ES45 se
I think their visualizations interests cover a wide range of fields such as
fluids, astrophysics, molecular chemistry, etc.
They are primarly interested and want everything being open-source if possible.
I see that your also from HP, actually another person from HP is supposed to get
back to u
>
>
>On Mon, 17 Jun 2002, Benjamin Herrenschmidt wrote:
>>
>> >mmap() and AGP driver gives access to IOMEM/AGP
>>
>> That one is problematic. I don't support the mmap interface properly
>> on Apple chipsets for example, because they don't support the AGP
>> aperture beeing accessed by the CPU.
On Tue, 2002-06-18 at 18:57, Michael wrote:
> On Mon, Jun 17, 2002 at 02:26:49AM +0200, Michel Dänzer wrote:
> > - Portability fixes for the new driver:
> > http://penguinppc.org/~daenzer/DRI/radeon-endianness.diff
> > Feedback and testing appreciated as always, in particular on the changes
> > t
Linus Torvalds wrote:
> Yes, kernel support (or indirect rendering) is needed for untrusted
> applications, but it might actually be interesting to see what a
> direct-rendering all-user-land implementation looks like. It has some
> debugging advantages, and it may actually make sense to start fr
Jeff Hartmann wrote:
>
> Keith Whitwell wrote:
>
> > Benjamin Herrenschmidt wrote:
> >
> >>> HOWEVER, if you tied the GART mapping to the DRM lock, you might be ok.
> >>> That gives you the required system exclusion, and if you make it an
> >>> explicit "get my GART context" function that is onl
I was working on os-independence, starting with the r128 driver because
I have a linux machine ready with a r128 in it. It's a gentoo 1.1
system (2.4.18 vanilla), Rage128 Mobility M4 on Inspiron 8000 (i815),
and 4.2.0 was installed with no DRM.
I made World install with bsd-3-0-0-branch, and co
Jens Owen wrote:
> Linus Torvalds wrote:
>
>
>>Yes, kernel support (or indirect rendering) is needed for untrusted
>>applications, but it might actually be interesting to see what a
>>direct-rendering all-user-land implementation looks like. It has some
>>debugging advantages, and it may actuall
Eric Anholt wrote:
> I was working on os-independence, starting with the r128 driver because
> I have a linux machine ready with a r128 in it. It's a gentoo 1.1
> system (2.4.18 vanilla), Rage128 Mobility M4 on Inspiron 8000 (i815),
> and 4.2.0 was installed with no DRM.
>
> I made World instal
26 matches
Mail list logo
