dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2
Date: Tue, 06 Dec 2016 12:38:09 +0000	[thread overview]
Message-ID: <bug-98964-502-gDelAWVLjA@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-98964-502@http.bugs.freedesktop.org/>


[-- Attachment #1.1: Type: text/plain, Size: 1528 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98964

--- Comment #12 from Zoltán Böszörményi <zboszor@pr.hu> ---
(In reply to Emil Velikov from comment #11)
> Above all: yes using hard links is nasty.

Thanks for confirming. :-)

> If you're having a single (or multiple fixed) GPU system then building
> multiple drivers is a _very_ bad idea. If you're doing that for embedded
> systems then it gets even worse. Thus having separate $driver subpackages
> makes no sense :-(

I never said it is the same machine all across the board. All of them are
single GPU ones, but historically we have systems with:
AMD RS780
NVIDIA (ION1, ION2 and some third one, for our workload, Nouveau is enough)
AMD Kabini
AMD Kaveri
Intel D525
Most recently Intel J1900

The same OS must run on all of them, so it does make sense to build different
drivers into Mesa but it was also a necessity to save space where we can. Hence
the symlink solution. Custom made OS based on Yocto.

Even if the hardlinks are used, bitbake in Yocto has a separate packaging stage
after "make install" that copies files instead of moving them so even a single
subpackage containing all drivers would end up with broken hardlinks, thus
requiring multiples of what is needed solely for the gallium_dri.so and
mesa_dri_drivers.so megadrivers. Maybe the megadrivers idea is the elephant in
the room. I know it was created for a miniscule performance gain.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2445 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2016-12-06 12:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-02  9:31 [Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2 bugzilla-daemon
2016-12-02  9:32 ` bugzilla-daemon
2016-12-02 19:40 ` bugzilla-daemon
2016-12-03  5:47 ` bugzilla-daemon
2016-12-05 21:58 ` bugzilla-daemon
2016-12-05 22:00 ` bugzilla-daemon
2016-12-06  5:18 ` bugzilla-daemon
2016-12-06  5:39 ` bugzilla-daemon
2016-12-06 12:02 ` bugzilla-daemon
2016-12-06 12:38 ` bugzilla-daemon [this message]
2016-12-06 13:20 ` bugzilla-daemon
2016-12-06 14:45 ` bugzilla-daemon
2019-09-18 19:40 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-98964-502-gDelAWVLjA@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon@freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).