lkml.org 
[lkml]   [2004]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Merging DRM and fbdev


On Sun, 3 Oct 2004, Alan Cox wrote:

> On Sul, 2004-10-03 at 16:50, Vladimir Dergachev wrote:
>> In particular, I can contribute the code that does Framebuffer->System Ram
>> transfers over PCI/AGP. It is currently GPL licensed, but there is no
>> problem if BSD folks want it too.
>
> This will do *wonders* to X render performance if used properly on those
> cards we can't do render in hardware.
>
>> This is also potentially useful for any Mesa functions that want to
>> transfer data back from video RAM - using plain reads for this is really slow.
>
> Agreed - and Mesa tends to skip even tricks like SSE2 that can quadruple
> read performance.

I am glad to see such enthusiasm :)

The code I have only does it on ATI cards (all radeons, all rage128, some
mach64). The radeon code is the one that is known to work well.

My personal interest is that Framebuffer -> System Ram transfer is needed
if one wants to use Radeon GPUs for numerical computation. Thus, if there
is an agreement on what needs to be done and what modifications are
acceptable I can make this a priority.

What kind of interface would different projects want ? Should I wait for
Jon's modifications to complete ? What people should we include on CC list ?

Also here is a short description of current km design:

* km.[c,h] - this provides module registration and DMA queue
virtualization (note: this is GUI_DMA queue, different from what
DRM uses)

* radeon.c, rage128.c, mach64.c - these are hardware specific
functions

* km_memory.[c,h] - this is v4l code for reverse mapping, I guess
it is obsolete in 2.6.x kernels

* km_api.[c,h] km_api_data.[c,h] - this is a new interface for
video (and similar devices), an experiment to implement features
not present in v4l or v4l2.
** I am not suggesting this be included. **

* km_v4l.c - this is a client of km_api that provides v4l
interface.

The first two pieces can be ported with ease - there are few modifications
to be made, just cut the code that registers the driver.

The km_api piece will need to be replaced with interface everyone agrees
on.

Please let me know your comments !

best

Vladimir Dergachev



>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.066 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site