folks,
are you looking for ways to make simple things complicated ?
date-based versioning (eg. -MM) only makes sense, when you
have an appropriate release schedule.
I'd really prefer semantic versioning - especially for stable distros
and embedded systems (here you dont wanna do arbitrary
On 10.08.2016 15:19, Nicolai Hähnle wrote:
> It would be nice to have something more concrete to go on, like what are
> the problems _really_ :)
Actually, I haven't understood who the other users of addrlib actually
are - is it just AMDs proprietary driver ?
> What pain do submodules give you
On 07.08.2016 12:50, Marek Olšák wrote:
> It would mainly be a futile task if it had to compete with their
> official Mesa driver.
Not quite. Would give us all of gallium's capabilities also for
the intel chips, for example having lots of different state trackers.
(coming back to my original
On 09.08.2016 16:59, Nicolai Hähnle wrote:
> So shared linking is right out.
Not exactly. Just everything needs to be linked against the matching
versions. More a dist-layer problem.
addrlibs folks should learn to introduce a proper versioning and
provide MVCC-capable build rules. That really
On 09.08.2016 15:47, Nicolai Hähnle wrote:
> I think the best way forward is to create a dedicated repository for
> addrlib which is then integrated into Mesa as a git submodule.
If you really wanna make a lot of people, especially dist-maintainers
very unhappy ...
> From initial experiments,
On 06.08.2016 19:17, Marek Olšák wrote:
> The lack of interest from Intel is the main reason.
And the other mesa folks also not interested ?
Would an conversion to gallium be a very complex task ?
--mtx
___
mesa-dev mailing list
On 06.08.2016 19:46, Emil Velikov wrote:
> You mentioned "cairo's gallium backend running again". Can you point
> to the said code ?
https://cgit.freedesktop.org/cairo/tree/src/drm/cairo-drm-gallium-surface.c
> Can you elaborate why you're thinking against having the cairo
> state-tracker in
On 06.08.2016 15:23, Marek Olšák wrote:
> I'd recommend moving the cairo rendering code into Mesa and have Mesa
> implement and export some kind of a low-level cairo library.
That would essentially create a circular dependency - and cairo's
surface backend API is also private.
> Please note
On 06.08.2016 13:16, Nicolai Hähnle wrote:
> Well, in your first mail it sounded like you wanted to stabilize the
> Gallium API itself.
Not actually stabilizing, but making it semi-public. (at dist level in
an separate package). Of course, external state trackers need to built
to the right
On 05.08.2016 17:36, Ilia Mirkin wrote:
> The idea is that gallium is an unstable unversioned API, and if you want
> something else, then you make a state tracker which exposes a stable
> API.
That's exactly what I intend: cario.
--mtx
___
mesa-dev
On 06.08.2016 04:05, ⚛ wrote:
> Question 2: Exists there a reason for _not_ linking radeonsi_dri.so,
> swrastg_dri.so, etc, directly to Mesa's libGL.so? The Gallium
> *_dri.so libraries are the same inode on the filesystem.
Sure about that ?
nekrad@orion:~/MESA/lib/dri$ ls -lai
total 508348
On 05.08.2016 06:48, Enrico Weigelt, metux IT consult wrote:
... replying to myself... ;-o
> Let's start w/ a simple DRM usecase (no X involved). The big steps
> would IMHO be:
> #1: open the DRM device, setup fb and crtc
If I'm correct, the first thing to do is to get a proper wins
Hi folks,
I'd like to get the cairo's gallium backend running again (hasn't been
maintained for a long time and doesn't fit at all to recent mesa).
The main problem I've got here is that gallium API is mesa-internal,
so I'd like to do some steps on making it (semi-)public. I'm aware that
it's
On 04.08.2016 17:10, Jason Ekstrand wrote:
Hi,
> The BSDs are still stuck at 4.2+patches for licensing reasons and they
> use Mesa for graphics. I think at some point, they'll get clang in core
> and they can start building with that. There are ancient RHEL versions
> where the GCC version is
On 04.08.2016 11:38, Jose Fonseca wrote:
> __FUNCTION__ has been around for a very long time (before 1999), so it's
> no surprise that MSVC has it. But not implementing __func__ does seem a
> oversight. I believe they fixed it on MSVC 2015.
hmm, okay. as long as we're supporting msvc'03, I'd
On 04.08.2016 11:21, Marek Olšák wrote:
> src/glx isn't gallium. src/glx isn't even used on Windows. That linked
> file is completely disconnected from everything this thread is about.
ups, I mixed up several threads ... I meant the shared glapi library.
(see the other thread "non-shared glapi
Hi folks,
which is the oldest gcc version we need to support ?
I see certain quirks for pre 4.4.5 - my Ubuntu Trusty box
(now over 2 years old) already has 4.8 ... can we remove
that stuff ?
(anyways, it's just for non-autoconf builds)
--mtx
___
On 03.08.2016 18:09, Marek Olšák wrote:
> It has always been statically linked as far as I remember.
> libgallium.so is a Ubuntu speciality that we don't support.
on win32 (using scons), it doesn't seem to be the case:
On 03.08.2016 12:20, Eric Engestrom wrote:
> BTW, c99_compat.h has a #define for __func__ where needed, so this
> change (removing use of __FUNCTION__) is a good one indeed :)
Did a few experiments w/ gcc vs msvc. The common denominator is
both define __FUNCTION__, so I moved there and dropped
On 03.08.2016 23:28, Jose Fonseca wrote:
Hi,
> There are minor inconsistencies. For example, it doesn't support
> __func__, but doing
>
> #define __func__ __FUNCTION__
>
> suffices to make __func__ work compatible.
Wait a second ... IIRC, __FUNCTION__ was a non-standard gcc'ism - now
msvc
On 03.08.2016 13:25, Rob Clark wrote:
> Probably it would be on a case-by-case basis. There are at least a
> few places with some useful debug code, ie. not the kind that you'd
> normally enable, but stuff you'd want if you were making changes in
> those areas..
In those cases, shouldn't we
Hi folks,
I've seen we're using __func__ as well as __FUNCTION__.
Should we consolidate that ?
--mtx
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi folks,
I've seen quite a lot of #if 0's - looks like dead code.
Should we remove that ?
--mtx
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi folks,
I'm currently backporting latest mesa to Ubuntu Trusty, starting
with their original deb files. One problem I stumbled across is that
libgallium.so isn't built/installed anymore - it seems that it's now
statically linked into all the drivers.
What happened to that so ? Why now
On 03.08.2016 09:47, Timothy Arceri wrote:
> The current requirement for Mesa is MSVC 2013 so any compat workarounds
> for functionality supported by that version can be dropped.
>
> A bunch of stuff has been dropped already but feel free to find any
> remaining code.
hmm, I dont have any msvc
Hi folks,
do we still need to support pre-c99 compilers or could we drop
that compat stuff ?
--mtx
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi folks,
is there still a real need for having non-shared glapi ?
Otherwise, should we remove it ?
--mtx
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
27 matches
Mail list logo
