On Thu, Aug 28, 2014 at 12:50 PM, Matt Turner wrote:
> On Tue, Aug 12, 2014 at 9:48 AM, Kenneth Graunke
> wrote:
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> index d3509a0..19f7ef8 100644
>> --- a/src/mesa/drivers/dri/i965
On 05.11.2014 20:14, Joonas Lahtinen wrote:
Modified not refer to DRI3, just uses the present extension to get rid
of the excess buffer invalidations.
AFAICT there's no fallback from your changes to the current behaviour if
the X server doesn't support the Present extension. There probably ne
https://bugs.freedesktop.org/show_bug.cgi?id=84566
--- Comment #49 from Iago Toral ---
Jason you had this commit in your original branch: "MAYBEREVERT: Fill X
components with 1"
That basically makes packing to padded formats (like RGBX) set X=1. In the
commit message you mention that you are not
On 05.11.2014 21:21, Ian Romanick wrote:
> On 11/04/2014 01:24 PM, Roland Scheidegger wrote:
>> Am 04.11.2014 um 13:05 schrieb Juha-Pekka Heikkila:
>>> + for(i = 0; i < n; i++) {
>>> + _mesa_clamp_float_rgba(rgba_src[i], temp, min, max);
>>> +
>>> + *operand = _mm_mul_ps(multiplier, *op
On to, 2014-11-06 at 18:12 +0900, Michel Dänzer wrote:
> On 05.11.2014 20:14, Joonas Lahtinen wrote:
> >
> > Modified not refer to DRI3, just uses the present extension to get rid
> > of the excess buffer invalidations.
>
> AFAICT there's no fallback from your changes to the current behaviour if
On ke, 2014-11-05 at 15:19 +, Emil Velikov wrote:
> Hi Joonas,
>
> Does getting rid of the viewport hack give you any noticeable
> performance improvement?
Yes, it significantly reduces the CPU load when multiple glViewport
calls are made per frame (4x4 grid or so).
> Is there any interest i
https://bugs.freedesktop.org/show_bug.cgi?id=74563
Tapani Pälli changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Signed-off-by: Timothy Arceri
---
configure.ac | 6 ++
src/mesa/x86/common_x86.c | 4
src/mesa/x86/common_x86_features.h | 4 +++-
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 03f1bca..cc0a661 100644
--- a
Also cleans up some if statements in the *faster functions.
Callgrind cpu usage results from pts benchmarks:
For ytile_copy_faster()
Nexuiz 1.6.1: 2.16% -> 1.20%
Signed-off-by: Timothy Arceri
---
src/mesa/Makefile.am | 8 +++
src/mesa/drivers/dri/i965/intel_tex_subi
On 05/11/14 21:11, Jose Fonseca wrote:
>> How many people/companies use EGL for Windows/fbdev, how about OpenVG on
> any platform ?
>
> I already said this privately to Marek when he was RFC'ing on this change:
> I'm fine if Linux-specific drivers abandon st/egl to focus solely on st/dri,
> but
Hi Frank,
On 31/10/14 01:11, Frank Henigman wrote:
> I was too hasty with my "Tested-by." While it worked in a
> shared-glapi configuration, it broke the build with the following:
>
> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
> --host=x86_64-cros-linux-gnu --mandir=/usr/share/man
> -
Humble ping x2
On 14/10/14 15:25, Emil Velikov wrote:
> Humble ping.
>
> On 23/09/14 01:25, Emil Velikov wrote:
>> From: Sjoerd Simons
>>
>> When using RGBA EGLConfigs allow both RGB and RGBA X visuals, such that
>> application can decide whether they want to use RGBA (and have the
>> compositor
On 29.10.2014 14:05, Timothy Arceri wrote:
> Makes use of SSE to speed up compute of min and max elements
>
> Callgrind cpu usage results from pts benchmarks:
>
> Openarena 0.8.8: 3.67% -> 1.03%
> UrbanTerror: 2.36% -> 0.81%
>
> V5:
> - actually make use of the optimisation in android (Emil Veli
Hi David,
Just a few nitpicks which I've missed the previously
On 02/11/14 18:31, David Heidelberg wrote:
> Implement pipe_loader_sw_probe_wrapped which allows to use the wrapped
> software renderer backend when using the pipe loader.
>
> Signed-off-by: David Heidelberg
> ---
> src/gallium/aux
On 05.11.2014 17:25, Emil Velikov wrote:
> Hi Juha-Pekka,
>
> On 04/11/14 12:05, Juha-Pekka Heikkila wrote:
> [snip]
>> I made 'x86' folder under
>> src/mesa/main. The idea here being if there is optimization targeting
>> architecture it'd exist directly under the place where it was used, in its
>
Hi Ken,
From what I've gathered the proposed patch is incorrect and is (most
likely) working around a buggy application behaviour. Afaics Ian
suggested that we add a driconf option for such applications.
Should I consider this patch for the stable branch or the above sounds
about right and we can
https://bugs.freedesktop.org/show_bug.cgi?id=85918
--- Comment #4 from Emil Velikov ---
Roland,
Indeed this issue is not related (does not seem) to the verison of msvc yet
it's a nice reminder about the topic, plus an humble ping for Michael :)
--
You are receiving this mail because:
You are th
https://bugs.freedesktop.org/show_bug.cgi?id=85918
Emil Velikov changed:
What|Removed |Added
Status|NEW |RESOLVED
Version|unspecified
I'd say it's a spec bug. ARB_texture_buffer_range should say that the
offset should be a multiple of an element size, but it doesn't. The
question is, what should the element size be? One component or the
whole pixel?
Marek
On Wed, Nov 5, 2014 at 9:08 PM, Roland Scheidegger wrote:
> Trying to fi
https://bugs.freedesktop.org/show_bug.cgi?id=85918
--- Comment #6 from Michael Bachmann ---
Thank you for taking care about this issue and for including the fix in Version
10.3.3.
--
You are receiving this mail because:
You are the assignee for the bug.
_
Am 06.11.2014 um 16:15 schrieb Marek Olšák:
> I'd say it's a spec bug. ARB_texture_buffer_range should say that the
> offset should be a multiple of an element size, but it doesn't. The
> question is, what should the element size be? One component or the
> whole pixel?
Imho whole pixel (for block c
Signed-off-by: Jan Vesely
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index e953822..3a4fcf0 100644
--- a/src/galliu
For radeonsi, I think only x8, x8y8, and x16 fetches can be
byte-aligned. Everything else is dword-aligned (the 2 lowest bits are
ignored). I guess the cap should be 4 then.
Marek
On Thu, Nov 6, 2014 at 4:55 PM, Roland Scheidegger wrote:
> Am 06.11.2014 um 16:15 schrieb Marek Olšák:
>> I'd say i
In general, it seems as if this can miss several things. For instance, it
checks that all the predicessors are valid but never that we have all the
predecessors. Same for successors. If we really want to be able to
validate a CFG, maybe a stack-based approach like calculate_cfg would work
better
On Thu, Nov 06, 2014 at 11:46:41AM -0500, Jan Vesely wrote:
> Signed-off-by: Jan Vesely
I've pushed this, thanks!
-Tom
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.c
1 and 4 are Reviewed-by: Jason Ekstrand
On Wed, Nov 5, 2014 at 4:13 PM, Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i965/brw_cfg.h | 74
> +
> 1 file changed, 74 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
> b/src/mesa/drivers/dri/
From: Michael Varga
If the VOP and GOV headers were truncated they will be regenerated.
Signed-off-by: Michael Varga
---
src/gallium/state_trackers/va/picture.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/p
On Thu, Nov 6, 2014 at 4:18 AM, Timothy Arceri wrote:
> Signed-off-by: Timothy Arceri
> ---
> configure.ac | 6 ++
> src/mesa/x86/common_x86.c | 4
> src/mesa/x86/common_x86_features.h | 4 +++-
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff -
From: Michael Varga
Signed-off-by: Michael Varga
---
src/gallium/state_trackers/va/picture.c| 72 ++
src/gallium/state_trackers/va/va_private.h | 9
2 files changed, 81 insertions(+)
diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state
On Thu, Nov 6, 2014 at 4:20 AM, Timothy Arceri wrote:
> Also cleans up some if statements in the *faster functions.
>
> Callgrind cpu usage results from pts benchmarks:
>
> For ytile_copy_faster()
>
> Nexuiz 1.6.1: 2.16% -> 1.20%
>
> Signed-off-by: Timothy Arceri
> ---
> src/mesa/Makefile.am
On Wed, Nov 5, 2014 at 4:13 PM, Matt Turner wrote:
> When the earlier block ended with control flow, we'd mistakenly remove
> some of its links to its children. The same happened with the later
> block.
> ---
> src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp | 10
> +++---
> 1
https://bugs.freedesktop.org/show_bug.cgi?id=84566
--- Comment #50 from Jason Ekstrand ---
(In reply to Iago Toral from comment #49)
> Jason you had this commit in your original branch: "MAYBEREVERT: Fill X
> components with 1"
>
> That basically makes packing to padded formats (like RGBX) set X
From: Michael Varga
This patch cleans the function handleVASliceDataBufferType() for better
readability.
Signed-off-by: Michael Varga
---
src/gallium/state_trackers/va/picture.c | 75 ++---
1 file changed, 40 insertions(+), 35 deletions(-)
diff --git a/src/gallium/
From: Michael Varga
Also, Implemented a small locally used interface for writing bits to a buffer.
Signed-off-by: Michael Varga
---
src/gallium/state_trackers/va/picture.c | 92 +
1 file changed, 92 insertions(+)
diff --git a/src/gallium/state_trackers/va/pictu
From: Michael Varga
Signed-off-by: Michael Varga
---
src/gallium/state_trackers/va/picture.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index 327c33d..ff13bc6 100644
--- a/src/gallium/state_tracker
From: Michael Varga
Signed-off-by: Michael Varga
---
src/gallium/state_trackers/va/picture.c | 16
1 file changed, 16 insertions(+)
diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index a4eb26b..327c33d 100644
--- a/src/gallium/s
If there's no feedback for so long, I suggest you commit the patch
without review. If it fixes a bug, that's one more reason to commit
it.
Marek
On Thu, Nov 6, 2014 at 2:12 PM, Emil Velikov wrote:
> Humble ping x2
>
> On 14/10/14 15:25, Emil Velikov wrote:
>> Humble ping.
>>
>> On 23/09/14 01:25
On Thu, Nov 6, 2014 at 9:41 AM, Jason Ekstrand wrote:
> In general, it seems as if this can miss several things. For instance, it
> checks that all the predicessors are valid but never that we have all the
> predecessors.
I'm not sure what you mean. That we don't validate that if A -> B then
B h
On Thu, Nov 6, 2014 at 10:07 AM, Jason Ekstrand wrote:
>
>
> On Wed, Nov 5, 2014 at 4:13 PM, Matt Turner wrote:
>>
>> When the earlier block ended with control flow, we'd mistakenly remove
>> some of its links to its children. The same happened with the later
>> block.
>> ---
>> src/mesa/drivers
On Wed, Nov 5, 2014 at 5:12 PM, Jason Ekstrand wrote:
>
>
> On Wed, Nov 5, 2014 at 2:46 PM, Matt Turner wrote:
>>
>> On Wed, Nov 5, 2014 at 2:00 PM, Jason Ekstrand
>> wrote:
>> > This can be very useful for trying to debug list corruptions.
>> >
>> > Signed-off-by: Jason Ekstrand
>> > Cc: Ian R
On Wed, Oct 22, 2014 at 11:11 AM, wrote:
> From: José Fonseca
>
> JITMemoryManager was removed in LLVM 3.6, and replaced by its base
> class RTDyldMemoryManager.
>
> This change fixes our JIT memory managers specializations to derive
> from RTDyldMemoryManager in LLVM 3.6 instead of JITMemoryMan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello list,
Barring a slight delay, during which I was expecting more
non-freedreno patches, it's time for yet another 10.3 stable
candidate. Currently we have:
- 102 queued (89 of which are for freedreno)
- 4 nominated (outstanding)
- and 3 reject
On 06/11/14 19:20, Matt Turner wrote:
> On Wed, Oct 22, 2014 at 11:11 AM, wrote:
>> From: José Fonseca
>>
>> JITMemoryManager was removed in LLVM 3.6, and replaced by its base
>> class RTDyldMemoryManager.
>>
>> This change fixes our JIT memory managers specializations to derive
>> from RTDyldMe
On Thursday, November 06, 2014 02:55:25 PM Emil Velikov wrote:
> Hi Ken,
>
> From what I've gathered the proposed patch is incorrect and is (most
> likely) working around a buggy application behaviour. Afaics Ian
> suggested that we add a driconf option for such applications.
>
> Should I conside
On Thu, Nov 6, 2014 at 11:27 AM, Emil Velikov wrote:
> On 06/11/14 19:20, Matt Turner wrote:
>> On Wed, Oct 22, 2014 at 11:11 AM, wrote:
>>> From: José Fonseca
>>>
>>> JITMemoryManager was removed in LLVM 3.6, and replaced by its base
>>> class RTDyldMemoryManager.
>>>
>>> This change fixes our
On 06/11/14 19:29, Kenneth Graunke wrote:
> On Thursday, November 06, 2014 02:55:25 PM Emil Velikov wrote:
>> Hi Ken,
>>
>> From what I've gathered the proposed patch is incorrect and is (most
>> likely) working around a buggy application behaviour. Afaics Ian
>> suggested that we add a driconf opt
On Wed, Nov 5, 2014 at 12:54 PM, Matt Turner wrote:
> On Wed, Nov 5, 2014 at 12:50 PM, Timothy Arceri wrote:
>> There have been quite a few eyes over this now but nobody has given it a
>> reviewed by yet.
>>
>> Would be nice to get it in before the code freeze. Any takers?
>
> Yes, I'll make sure
https://bugs.freedesktop.org/show_bug.cgi?id=84566
--- Comment #51 from Jason Ekstrand ---
(In reply to Samuel Iglesias from comment #48)
> (In reply to Jason Ekstrand from comment #34)
> > (In reply to Samuel Iglesias from comment #33)
> > > Jason, I would like to know your opinion about the int
But even dword offsets aren't translatable right now to
pipe_sampler_view first_elements if the format has more than 32 bits.
Roland
Am 06.11.2014 um 18:21 schrieb Marek Olšák:
> For radeonsi, I think only x8, x8y8, and x16 fetches can be
> byte-aligned. Everything else is dword-aligned (the 2 lo
I thought Eric and Chad already NAKed it in bugzilla. The problem is
that applications ask for an RGBA visual for GL blending. They use the
alpha channel to generate their images, but the final alpha values are,
basically, random... and the composited result would be pure garbage.
As Chad points
On Thu, 2014-11-06 at 09:59 -0800, Matt Turner wrote:
> On Thu, Nov 6, 2014 at 4:18 AM, Timothy Arceri wrote:
> > Signed-off-by: Timothy Arceri
> > ---
> > configure.ac | 6 ++
> > src/mesa/x86/common_x86.c | 4
> > src/mesa/x86/common_x86_features.h | 4 +
On Thu, 2014-11-06 at 10:03 -0800, Matt Turner wrote:
> On Thu, Nov 6, 2014 at 4:20 AM, Timothy Arceri wrote:
> > Also cleans up some if statements in the *faster functions.
> >
> > Callgrind cpu usage results from pts benchmarks:
> >
> > For ytile_copy_faster()
> >
> > Nexuiz 1.6.1: 2.16% -> 1.20
From: Frank Henigman
Dri driver libs are not linked to pull in libglapi so gbm_create_device()
fails when it tries to dlopen them (unless the application is linked
with something that does pull in libglapi, like libGL).
Until dri drivers can be fixed properly, dlopen libglapi before trying
to dlo
On 11/06/2014 04:18 AM, Timothy Arceri wrote:
> Signed-off-by: Timothy Arceri
> ---
> configure.ac | 6 ++
> src/mesa/x86/common_x86.c | 4
> src/mesa/x86/common_x86_features.h | 4 +++-
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/c
On Thu, Nov 6, 2014 at 8:09 AM, Emil Velikov wrote:
> Indeed. static-glapi does not get too much testing, plus it seems that
> it's broken (in a way) for a lng time.
> It seems that we'll have to (temporary) resolve with shoving
> dlopen(libglapi.so) into gbm, so that in time programs can nuk
On Thu, Nov 6, 2014 at 1:22 PM, Timothy Arceri wrote:
> On Thu, 2014-11-06 at 10:03 -0800, Matt Turner wrote:
>> On Thu, Nov 6, 2014 at 4:20 AM, Timothy Arceri wrote:
>> > Also cleans up some if statements in the *faster functions.
>> >
>> > Callgrind cpu usage results from pts benchmarks:
>> >
>
On 11/06/2014 02:12 PM, Matt Turner wrote:
> On Thu, Nov 6, 2014 at 1:22 PM, Timothy Arceri wrote:
>> On Thu, 2014-11-06 at 10:03 -0800, Matt Turner wrote:
>>> On Thu, Nov 6, 2014 at 4:20 AM, Timothy Arceri
>>> wrote:
+#include
+#include
+#include
>>>
>>> I don't think you need
Am Donnerstag, 6. November 2014, 11:55:59 schrieb Matt Turner:
> On Wed, Nov 5, 2014 at 12:54 PM, Matt Turner wrote:
> > On Wed, Nov 5, 2014 at 12:50 PM, Timothy Arceri
wrote:
> >> There have been quite a few eyes over this now but nobody has given it a
> >> reviewed by yet.
> >>
> >> Would be
On Thu, Nov 6, 2014 at 2:33 PM, Marc Dietrich wrote:
> So this is only a problem with Link-Time-Opt.
I don't actually know how you're getting to this point in the build
with LTO. It fails for me in src/mapi.
I think LTO is something we should make work at some point, but I
don't think we should
On Thu 06 Nov 2014, Timothy Arceri wrote:
Also cleans up some if statements in the *faster functions.
I have comments about the cleanup below.
diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index cb5738a..0deeb75 100644
--- a/src/
I tested your patch with the "teximage" program in mesa demos, the
same thing I used to benchmark when I developed this code.
As Matt and Chad point out, the odd-looking _faster functions are
there for a reason. Your change causes a huge slowdown.
I tested on a sandybridge system with a "Intel(R)
On Thu, Nov 6, 2014 at 7:30 PM, Frank Henigman wrote:
> Also I couldn't configure the build after your patch. I think you
> left out a change to configure.ac to define SSSE3_SUPPORTED.
Ah, that was in patch 1/2.
___
mesa-dev mailing list
mesa-dev@list
How and when is "cpu_has_sse4_1" true? Is it controllable at runtime
through setting some environmental variable? or is it set once during
startup by detecting CPU features?
I guess checking for "cpu_has_sse4_1" is unnecessary if it isn't
controllable by user at runtime; because "USE_SSE41" is
On Thu, Nov 6, 2014 at 1:30 AM, Siavash Eliasi wrote:
> How and when is "cpu_has_sse4_1" true? Is it controllable at runtime through
> setting some environmental variable? or is it set once during startup by
> detecting CPU features?
It's actually a macro, but yes, see the end of
src/mesa/x86/com
On Tue, Nov 4, 2014 at 8:40 AM, Chris Forbes wrote:
> Two things were broken here:
> - The depth/stencil surface dimensions were broken for MSAA.
> - Sample count was programmed incorrectly.
>
> Result was the depth resolve didn't work correctly on MSAA surfaces, and
> so sampling the surface lat
On 06.11.2014 19:18, Joonas Lahtinen wrote:
On to, 2014-11-06 at 18:12 +0900, Michel Dänzer wrote:
On 05.11.2014 20:14, Joonas Lahtinen wrote:
Modified not refer to DRI3, just uses the present extension to get rid
of the excess buffer invalidations.
AFAICT there's no fallback from your chang
Thanks for the review. Ken has a slightly cleaner version of the patch
which avoids adding the helper function.
On Nov 7, 2014 2:29 AM, "Anuj Phogat" wrote:
>
>
> On Tue, Nov 4, 2014 at 8:40 AM, Chris Forbes wrote:
>
>> Two things were broken here:
>> - The depth/stencil surface dimensions were
The function is not called by platform_drm. As such one needs to
pay special attention at teardown.
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/egl_dri2.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 609af
Earlier commit failed to attribure that for drm platforms one does not
call dri2_create_screen, thus it does not create the screen and
driver_configs but inherits them from the "display" - gbm.
As such wrap cleanup in Platform != _EGL_PLATFORM_DRM to prevent
the issue and still cleanup correctly f
During teardown we free the driver_configs list pointer, but we forget
to deallocate each config in that list.
Signed-off-by: Emil Velikov
---
src/gbm/backends/dri/gbm_dri.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
ind
While working on some other things, I came across some bounds checking
code in _mesa_validate_DrawElements (and related functions) in
api_validate.c.
/* use indices in the buffer object */
/* make sure count doesn't go outside buffer bounds */
if (index_bytes(type, count) > ctx->
On Thu, Nov 6, 2014 at 8:56 PM, Siavash Eliasi wrote:
> Then I do recommend removing the "if (cpu_has_sse4_1)" from this patch and
> similar places, because there is no runtime CPU dispatching happening for
> SSE optimized code paths in action and just adds extra overhead (unnecessary
> branches)
On 11/06/2014 06:16 PM, Michel Dänzer wrote:
> On 06.11.2014 19:18, Joonas Lahtinen wrote:
>> On to, 2014-11-06 at 18:12 +0900, Michel Dänzer wrote:
>>> On 05.11.2014 20:14, Joonas Lahtinen wrote:
Modified not refer to DRI3, just uses the present extension to get rid
of the excess bu
From: Ian Romanick
It appears to be completely unused since f9be8543 (February 2012).
Signed-off-by: Ian Romanick
Cc: Kenneth Graunke
---
src/mesa/main/api_validate.c | 46
src/mesa/main/api_validate.h | 6 --
2 files changed, 52 deletions(-)
On Thursday, November 06, 2014 08:09:18 PM Ian Romanick wrote:
> While working on some other things, I came across some bounds checking
> code in _mesa_validate_DrawElements (and related functions) in
> api_validate.c.
>
> /* use indices in the buffer object */
> /* make sure count doe
On Thursday, November 06, 2014 11:00:13 PM Ian Romanick wrote:
> From: Ian Romanick
>
> It appears to be completely unused since f9be8543 (February 2012).
>
> Signed-off-by: Ian Romanick
> Cc: Kenneth Graunke
Yep, looks unused to me.
Reviewed-by: Kenneth Graunke
My 2012 commit message in f
On Friday, November 07, 2014 03:50:42 AM Emil Velikov wrote:
> Earlier commit failed to attribure that for drm platforms one does not
> call dri2_create_screen, thus it does not create the screen and
> driver_configs but inherits them from the "display" - gbm.
>
> As such wrap cleanup in Platform
77 matches
Mail list logo
