Ian Romanick wrote:
Holger Waechtler wrote:
Jon Smirl wrote:
Sharing graphics contexts is not the same thing as allowing two
completely
different device drivers access to the hardware on VT swap. Two
different device
drivers may have completely different contents in all of the
registers, CP
On Sul, 2004-05-09 at 14:32, Jon Smirl wrote:
I would like to see a single device drver always controlling the GPU and
VRAM/AGP memory management. Then it is easy to switch graphics contexts on VT
swap.
VRAM/AGP most of the time can probably be a generic library but yes I
agree, and at times
Sharing graphics contexts is not the same thing as allowing two completely
different device drivers access to the hardware on VT swap. Two different device
drivers may have completely different contents in all of the registers, CP
running or not, VRAM and AGP space. With two device drivers you
Alan Cox wrote:
On Iau, 2004-05-06 at 20:57, Jon Smirl wrote:
Simple example, DRM starts GPU coprocessor running. VT swap happens. New user
stops coprocessor. VT swap back to DRM. Now DRM thinks it left the coprocessor
running but that's not true now. DRM and FB conflict when FB is using the
Jon Smirl wrote:
Sharing graphics contexts is not the same thing as allowing two completely
different device drivers access to the hardware on VT swap. Two different device
drivers may have completely different contents in all of the registers, CP
running or not, VRAM and AGP space. With two
Holger Waechtler wrote:
Jon Smirl wrote:
Sharing graphics contexts is not the same thing as allowing two
completely
different device drivers access to the hardware on VT swap. Two
different device
drivers may have completely different contents in all of the
registers, CP
running or not, VRAM
On Sun, May 09, 2004 at 08:14:59PM -0700, Ian Romanick wrote:
| ... I very seriously doubt that you can halt and restart an
| in-progress shader. That would require extra logic, reduce performance,
| and wouldn't help games. What makes you think any of the current cards
| are designed
On Iau, 2004-05-06 at 18:57, Jens Owen wrote:
If mmapping is okay, then we're still able to touch hardware from user
space drivers. I'm fine with that.
Basically the kernel needs to know you are working with the frame
buffer, and it needs to be able to revoke that from under you on a
hot
On Iau, 2004-05-06 at 20:57, Jon Smirl wrote:
Simple example, DRM starts GPU coprocessor running. VT swap happens. New user
stops coprocessor. VT swap back to DRM. Now DRM thinks it left the coprocessor
running but that's not true now. DRM and FB conflict when FB is using the
coprocessor for
why do I get the impression we are discussing kgi or at least the goals of
kgi? without mentioning it ..is kgi a bad word around these parts? :-)
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
Another request is that this work be compared to the kgi work so that we don't
repeat the same mistakes. I wasn't around for that debate, can someone explain
what was learned from attempt?
I'll start reworking the proposal to include the feedback I have so far and get
it ready for the next round.
Jon,
This issue of whether or not to use kgi goes all the way back to design
decisions we made in 1998. Based on my recollection, I believe these
were the top issues:
1) kgi was Linux specific. We needed a kernel level module that was
more portable.
2) We wanted the bare minimum
On Thu, 6 May 2004, Jon Smirl wrote:
--- Jens Owen [EMAIL PROTECTED] wrote:
2) We wanted the bare minimum services in the kernel layer for
efficient and fast graphics support, and felt as much of the
driver code as possible should stay in user space.
Linux kernel people
John,
You can think of me as Old School, and take my feedback in that
context. My main reason for participating in this discussion is to give
some historical perspective.
Jon Smirl wrote:
--- Jens Owen [EMAIL PROTECTED] wrote:
2) We wanted the bare minimum services in the kernel layer for
Around 9 o'clock on May 6, Jens Owen wrote:
If you would like to get a flavor for the issue I'm writing about, simply
unmap the framebuffer from your Mesa-solo 3D driver and give it a go. I
think you'll find many difficult issues crop up related to software fall
backs and efficient readback
--- Jens Owen [EMAIL PROTECTED] wrote:
Six years ago, most devices could not handle this type of restriction
efficiently. Things have improved on the high end; but the low end
devices, are still very similar to what we had back in the day. Even
today, I would be very cautious of deploying
Jon Smirl wrote:
Framebuffer access follows the rules; kernel calls are used to map it into user
space. The major violations in X are in PCI bus and graphics chip probing.
If mmapping is okay, then we're still able to touch hardware from user
space drivers. I'm fine with that.
I don't see any
Jon Smirl wrote:
--- Jens Owen [EMAIL PROTECTED] wrote:
Six years ago, most devices could not handle this type of restriction
efficiently. Things have improved on the high end; but the low end
devices, are still very similar to what we had back in the day. Even
today, I would be very
Vladimir Dergachev wrote:
Also, I would venture an opinion that, at the moment, the only Unices we
care about is Linux, BSD and Hurd - all open source. The current design
of XFree86 (with everything done in userspace) was motivated by the need
to support commercial Unices (like Solaris or
Martin Spott wrote:
Vladimir Dergachev wrote:
Also, I would venture an opinion that, at the moment, the only Unices we
care about is Linux, BSD and Hurd - all open source. The current design
of XFree86 (with everything done in userspace) was motivated by the need
to support commercial Unices
On Thu, 6 May 2004, Keith Whitwell wrote:
Jon Smirl wrote:
--- Jens Owen [EMAIL PROTECTED] wrote:
Six years ago, most devices could not handle this type of restriction
efficiently. Things have improved on the high end; but the low end
devices, are still very similar to what we had back
On Thu, 6 May 2004, Martin Spott wrote:
Vladimir Dergachev wrote:
Also, I would venture an opinion that, at the moment, the only Unices we
care about is Linux, BSD and Hurd - all open source. The current design
of XFree86 (with everything done in userspace) was motivated by the need
--- Vladimir Dergachev [EMAIL PROTECTED] wrote:
As far as acceleration - either 2d or 3d - it makes sense for it to stay
in userspace.
X and everything else needs to stop mapping the registers to user space and
instead start using an IOCTL interface to a driver. The problem is that X or
23 matches
Mail list logo
