FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 04-13-2011, 06:08 PM
Adam Williamson
 
Default rfc/headsup: graphics driver packaging in F16+

On Tue, 2011-04-12 at 13:17 -0400, Adam Jackson wrote:
> On Tue, 2011-04-12 at 09:34 -0700, Adam Williamson wrote:
> > On Tue, 2011-04-12 at 12:12 -0400, Adam Jackson wrote:
> >
> > > And input is even briefer (evdev, synaptics, wacom, vmmouse). I'd like
> > > to chop the -drivers metapackage down to just this set, and either make
> > > a new metapackage in optional for -drivers-retrocomputing or simply list
> > > all the drivers there individually. Note that since we're keeping
> > > drivers for fbdev and vesa we should still get graphics on most devices
> > > even if the user doesn't explicitly ask for a native driver.
> > >
> > > So that's the rough plan. Comments appreciated if I'm overlooking
> > > anything.
> >
> > Well, the less intrusive alternative is just to make graphics drivers a
> > comps group rather than using a metapackage. Metapackages are generally
> > 'frowned upon' in Fedora anyway, and you're supposed to do stuff with
> > comps groups. Doing it that way would remove the critical path
> > implications; we could then just add the important drivers to critpath
> > individually.
>
> Not that I object, but that's just moving the goalposts from "which
> drivers in the metapackage" to "which drivers in comps". It doesn't
> address the construction of the list.

Well, I was focusing on this part of your mail:

"For 2D we've got an xorg-x11-drivers metapackage that includes, well,
pretty much everything, and which is included in comps as a default.
This is lame, because it means a bunch of backwater drivers end up as
critical path and can never possibly get tested."

Which suggests the major reason to change this is the critpath
implications. My point being that if we do this with comps groups, it
completely removes the critpath issue, meaning we could still choose to
install lots of drivers by default and not worry about critpath.

It seems you have other good reasons to want to de-emphasize some
drivers, but still, if we make the comps change too, it means we don't
have to worry about drivers that are well maintained but for niche
hardware: we can keep them installed by default and 'fully supported',
but still not have to worry about them being critpath. We can still not
install by default drivers that we really want to stop caring about.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-13-2011, 09:43 PM
Kevin Kofler
 
Default rfc/headsup: graphics driver packaging in F16+

Adam Jackson wrote:
> On 4/12/11 11:58 PM, John Reiser wrote:
>> On 04/12/2011 09:12 AM, Adam Jackson wrote:
>>> For comparison, the baseline for the GPU in the phone in your pocket -
>>> and that platform layers like clutter more or less expect - is GLES 2.0,
>>> which is roughly comparable to DirectX 9. We're rapidly approaching the
>>> point where the software renderer is going to be a more satisfying
>>> experience than hardware 3d support for these chips, both for features
>>> and for performance.
>>
>> How rapidly? Today, which one leads in "satisfying experience", and by
>> how much?
>
> F16 timeframe? That's kind of why I bring it up now.

Will F16 finally ship the llvmpipe as the default software renderer?

(I can see the llvmpipe beat ancient cards easily, judging from the
benchmarks I've seen so far, but the existing software pipes are really
really slow.)

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-13-2011, 10:26 PM
Adam Jackson
 
Default rfc/headsup: graphics driver packaging in F16+

On 4/13/11 5:43 PM, Kevin Kofler wrote:

> Will F16 finally ship the llvmpipe as the default software renderer?

If by F16, you mean F15, then yes.

http://fedoraproject.org/wiki/Docs/Beats/Xorg

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-13-2011, 11:17 PM
Kevin Kofler
 
Default rfc/headsup: graphics driver packaging in F16+

Adam Jackson wrote:

> On 4/13/11 5:43 PM, Kevin Kofler wrote:
>
>> Will F16 finally ship the llvmpipe as the default software renderer?
>
> If by F16, you mean F15, then yes.
>
> http://fedoraproject.org/wiki/Docs/Beats/Xorg

Hmmm, really?

When I look at upstream mesa's code, I see this:
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/targets/dri-swrast/Makefile

This sure looks like it builds swrastg using the softpipe, not the llvmpipe.
I also don't see any Fedora patch which would be changing this.

Now I'm not going to claim that I know my way around the Mesa codebase, so
what am I missing?

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-13-2011, 11:57 PM
Adam Jackson
 
Default rfc/headsup: graphics driver packaging in F16+

On 4/13/11 7:17 PM, Kevin Kofler wrote:
> Adam Jackson wrote:
>> On 4/13/11 5:43 PM, Kevin Kofler wrote:
>>> Will F16 finally ship the llvmpipe as the default software renderer?
>>
>> If by F16, you mean F15, then yes.
>
> Hmmm, really?

I don't know. Let's ask the machine:

synephrine:~% DISPLAY=:0 LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep renderer
OpenGL renderer string: Gallium 0.4 on llvmpipe
synephrine:~% rpm -q mesa-dri-drivers
mesa-dri-drivers-7.11-0.6.20110412.0.fc15.x86_64

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-14-2011, 03:58 AM
Adam Williamson
 
Default rfc/headsup: graphics driver packaging in F16+

On Wed, 2011-04-13 at 19:57 -0400, Adam Jackson wrote:
> On 4/13/11 7:17 PM, Kevin Kofler wrote:
> > Adam Jackson wrote:
> >> On 4/13/11 5:43 PM, Kevin Kofler wrote:
> >>> Will F16 finally ship the llvmpipe as the default software renderer?
> >>
> >> If by F16, you mean F15, then yes.
> >
> > Hmmm, really?
>
> I don't know. Let's ask the machine:
>
> synephrine:~% DISPLAY=:0 LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep renderer
> OpenGL renderer string: Gallium 0.4 on llvmpipe
> synephrine:~% rpm -q mesa-dri-drivers
> mesa-dri-drivers-7.11-0.6.20110412.0.fc15.x86_64

In the interests of general public enlightenment, it would've been nice
if you'd answered KK's question "what am I missing", i.e., where's the
magic bit which makes llvmpipe the default? Knowledge is always a good
thing
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-14-2011, 06:02 AM
Adam Jackson
 
Default rfc/headsup: graphics driver packaging in F16+

On 4/13/11 11:58 PM, Adam Williamson wrote:

> In the interests of general public enlightenment, it would've been nice
> if you'd answered KK's question "what am I missing", i.e., where's the
> magic bit which makes llvmpipe the default? Knowledge is always a good
> thing

The specfile contains this stanza, after it has built OSMesa:

# now build the rest of mesa
%configure %{common_flags}
--disable-glw
--disable-glut
--disable-gl-osmesa
--with-driver=dri
--with-dri-driverdir=%{_libdir}/dri
--with-state-trackers=dri,glx
--enable-egl
--enable-gles1
--enable-gles2
--disable-gallium-intel
--disable-gallium-svga
--disable-gallium-egl
%if %{with_hardware}
--enable-gallium-llvm
--enable-gallium-radeon
--enable-gallium-r600
--enable-gallium-nouveau
%else
--disable-gallium-llvm
--disable-gallium-radeon
--disable-gallium-r600
--disable-gallium-nouveau
%endif
%{?dri_drivers}

The --enable-gallium-llvm bit, in particular, is key. There's some
small magic later where it renames swrastg_dri.so to be swrast_dri.so
because that's the name the X server and libGL are expecting, and that's
not perfect yet in that the debuginfo search gets a little confused, but
in the main I've tried to be pretty clear in the operation of the Mesa
spec, despite the utter malignancy of the Mesa buildsystem (any of them,
take your pick, there's like five now). If I've failed in any way to
document sufficiently our work in the specfile, please, do let me know.

But - as an aside - you're right. I was a little irked at being asked
whether I'd actually done the thing I'd said I'd done, had tested that
I'd done, had documented that I'd done, had claimed in public that I'd
done, and had been doubted of without any evidence of the inquisitor
having made even cursory investigation into the matter. It was wrong of
me to assume that someone reading the spec would look for the string
/llvm/i when looking for how to enable the LLVM support in Mesa, to
assume that someone would read the spec to learn how the package was
built, or to assume that someone would try to test a software GL path
like Xvfb or vesa to see if I was in fact telling the truth before
doubting my honesty. I was unnecessarily short in my reply, and for
that, I apologize. In the future I'll be less succinct.

(No, I won't.)

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 09:38 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org