On 04-Jun-2004, Mike Mestnik wrote:
Right, but thay must not EVER step on each other. From the time one
uploades a texture and then later unloads it, that space can't be used.
After an unload the memory can be maped back to system use.
I think the kernel's memory subsystem should be the
in DRM(agp_acquire) should be removed altogether in a 2.6 kernel
because its vmap() takes 4 arguments; however, only the guards seem to
have been removed, which causes this function to erroneously fail if
the AGP aperture can't be directly accessed by the CPU.
Looks like. Removing it
Mike Mestnik schrieb:
http://www.eff.org/IP/Video/DVDCCA_case/20040227_eff_pr.php
I found this article amusing, it showes that the DeCSS DVD decryption
computer code is in the public domain and no longer a trade secret. It
dose also say that there will be an appeal.
I was wondering where we where
lr, 05.06.2004 kl. 06.26 skrev Mike Mestnik:
http://www.eff.org/IP/Video/DVDCCA_case/20040227_eff_pr.php
I found this article amusing, it showes that the DeCSS DVD decryption
computer code is in the public domain and no longer a trade secret. It
dose also say that there will be an appeal.
On Sat, Jun 05, 2004 at 03:09:54AM -0400, Patrick McFarland wrote:
Which brings me to mention something else: I fully believe that the
kernel should be completely managing all aspects of memory and state
management of both 2D and 3D hardware. The kernel's portion of DRI
should be providing
On Sat, 2004-06-05 at 12:21 +0300, Ville Syrjl wrote:
On Sat, Jun 05, 2004 at 03:09:54AM -0400, Patrick McFarland wrote:
expose 2D and 3D hardware acceleration
functions, allow applications (DirectFB, xservers) to query the
available acceleration methods,
I disagree.
This part of
On Sat, Jun 05, 2004 at 12:41:33PM +0200, Michel Dänzer wrote:
On Sat, 2004-06-05 at 12:21 +0300, Ville Syrjälä wrote:
On Sat, Jun 05, 2004 at 03:09:54AM -0400, Patrick McFarland wrote:
expose 2D and 3D hardware acceleration
functions, allow applications (DirectFB, xservers) to query
On Sat, 2004-06-05 at 14:09 +0300, Ville Syrjl wrote:
On Sat, Jun 05, 2004 at 12:41:33PM +0200, Michel Dnzer wrote:
On Sat, 2004-06-05 at 12:21 +0300, Ville Syrjl wrote:
On Sat, Jun 05, 2004 at 03:09:54AM -0400, Patrick McFarland wrote:
expose 2D and 3D hardware acceleration
On 05-Jun-2004, Michel D?nzer wrote:
On Sat, 2004-06-05 at 12:21 +0300, Ville Syrj??l?? wrote:
This part of the kernel should be as dumb as possible. I think the best
interface would be simply one accepting almost complete DMA buffers. The
only thing missing from these buffers would be
On 05-Jun-2004, Ville Syrj?l? wrote:
On Sat, Jun 05, 2004 at 12:41:33PM +0200, Michel D?nzer wrote:
I'm not sure about that; pseudo-command buffers that the DRM parses and
generates the actual DMA buffers from on the fly might be better for
security and/or performance reasons.
Quite
--- Patrick McFarland [EMAIL PROTECTED] wrote:
On 05-Jun-2004, Michel D?nzer wrote:
On Sat, 2004-06-05 at 12:21 +0300, Ville Syrj??l?? wrote:
The client should just use a surface id (handed out by the memory
allocator)
instead of a real address. The kernel would then check if the
--- Patrick McFarland [EMAIL PROTECTED] wrote:
On 05-Jun-2004, Ville Syrj?l? wrote:
On Sat, Jun 05, 2004 at 12:41:33PM +0200, Michel D?nzer wrote:
I'm not sure about that; pseudo-command buffers that the DRM parses
and
generates the actual DMA buffers from on the fly might be better for
Ville Syrjälä wrote:
This part of the kernel should be as dumb as possible. I think the best
interface would be simply one accepting almost complete DMA buffers. The
only thing missing from these buffers would be real memory addresses. The
client should just use a surface id (handed out by the
Mathieu Lacage wrote:
The dri wiki suggests that the documentation for the clgd 5464 chipset
is publicly available. However, thoroughful googling did not turn up any
pdf file. Maybe it would make sense to update the wiki and remove this
statement...
Some creative googling revealed that the
--- Ian Romanick [EMAIL PROTECTED] wrote:
Mathieu Lacage wrote:
The dri wiki suggests that the documentation for the clgd 5464
chipset
is publicly available. However, thoroughful googling did not turn
up any
pdf file. Maybe it would make sense to update the wiki and remove
this
15 matches
Mail list logo
