On Mon, Jun 24, 2002 at 10:08:42AM -0700, Ian Romanick wrote:
On Tue, Jun 18, 2002 at 12:09:02AM +0100, José Fonseca wrote:
On 2002.06.17 23:19 Keith Whitwell wrote:
We could overcome the GLX difficulties in the same way we do now in
libGL with the direct rendering.
But I still
On Tue, Jun 18, 2002 at 12:09:02AM +0100, José Fonseca wrote:
On 2002.06.17 23:19 Keith Whitwell wrote:
We could overcome the GLX difficulties in the same way we do now in
libGL with the direct rendering.
But I still don't understand why vertex arrays would be such a problem
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 us
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 cycles. And
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 the
- 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 work on
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 the AGP
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 hacked
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 _and_ only called
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
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 assume you
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 from
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 only called under
the
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 actually make
14 matches
Mail list logo
