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 winsys, right ?
From: Mathias Fröhlich
Hi Brian,
As requested with the initial creation of util/bitscan.h
now move other bitscan related functions into util.
Make use of win32 intrinsics for util_last_bit/fls if present.
Signed-off-by: Mathias Fröhlich
Any testing especially on win32 is apprechiated.
Pleas
From: Mathias Fröhlich
Hi all,
The below was found by inspection.
Please review.
Thanks
Mathias
On gl{Push,Pop}Attrib(GL_CLIENT_VERTEX_ARRAY_BIT) take
care that gl_vertex_array_object::VertexAttribBufferMask
matches the bound buffer object in the
gl_vertex_array_object::VertexBinding array.
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 st
Drp... There's more work to do here to get the behavior 100% correct on
gen7 but this fixes a bug and is a step in the right direction.
Reviewed-by: Jason Ekstrand
Unfortunately, gen7 is a bit crazy so the simple solution doesn't cover all
the cases. For the full fix take a look at
https://cgi
---
src/compiler/nir/nir_opt_dead_cf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_opt_dead_cf.c
b/src/compiler/nir/nir_opt_dead_cf.c
index 81c1b65..3551124 100644
--- a/src/compiler/nir/nir_opt_dead_cf.c
+++ b/src/compiler/nir/nir_opt_dead_cf.c
@@ -
On 08/04/2016 02:28 PM, Martin Peres wrote:
On 05/08/16 00:24, Mark Janes wrote:
I saw no regressions from these tests. However, I wasn't able to run
the dEQP-EGL tests the last time I tried. What branch of dEQP are you
running?
InternalError (Runtime check failed: '(m_capabilities &
On 08/04/2016 02:24 PM, Mark Janes wrote:
I saw no regressions from these tests. However, I wasn't able to run
the dEQP-EGL tests the last time I tried. What branch of dEQP are you
running?
InternalError (Runtime check failed: '(m_capabilities &
CAPABILITY_GET_DISPLAY_PLATFORM) == 0' at
On 08/05/2016 05:42 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> Some ideas copied from Jakob Sinclair's implementation, but the color
> clearing is completely different.
>
> v2: remove leftover code, disable conditional rendering
> ---
> docs/GL3.txt | 2 +-
>
On Thu, 2016-08-04 at 18:36 +0200, Alejandro Piñeiro wrote:
> Hi,
>
> these days I have been trying to fix a test that uses transform
> feedback
> on the out varying of a tessellation shader. The relevant part on
> that
> shader is like this:
>
> layout (vertices=4) out;
>
> out block { ve
According to the IVB PRM Vol2 P1, this bit must be set if a pixel shader
contains a discard instruction.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97207
Cc: "12.0"
Signed-off-by: Nanley Chery
---
src/intel/vulkan/gen7_pipeline.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/s
On Thursday, August 4, 2016 11:28:28 AM PDT Jason Ekstrand wrote:
> > > - No cut index (GS is supposed to be fine and Tess looks OK too)
> >
> > I'd be OK with dropping GS and Tess support for rectangles.
>
> I don't know that we need to but the docs say cut index doesn't work.
Perhaps we should
This should have no effect, as all drivers which support BLORP also
support ES 3.0 - so ES 2.0 would be promoted and follow the ES 3 rules.
ES 1.0 doesn't have BlitFramebuffer.
This is purely to clarify the next patch a bit.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_blor
Just avoid whacking GL_FRAMEBUFFER_SRGB altogether, so we respect
the application's setting. This appears to work.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/common/meta_blit.c | 80 +
1 file changed, 28 insertions(+), 52 deletions(-)
Metaaa
I've never quite understood the purpose of this hack - supposedly,
doing resolves in the sRGB colorspace is slightly more accurate.
Currently, BlitFramebuffer() ignores sRGB encoding and decoding
on OpenGL, although it encodes and decodes in GLES 3.x.
The updated OpenGL 4.4 rules also allow for e
Modern OpenGL BlitFramebuffer require sRGB encode/decode when
GL_FRAMEBUFFER_SRGB is enabled. The blitter can't handle this,
so we need to bail. On Gen4-5, this means falling back to Meta,
which should handle it.
We allow sRGB <-> sRGB blits, as decode then encode ought to be a noop
(other than
OpenGL 4.4 specifies that BlitFramebuffer should perform sRGB encode
and decode like ES 3.x does, but only when GL_FRAMEBUFFER_SRGB is
enabled. This is technically incompatible in certain cases, but is
more consistent across GL, ES, and WebGL, and more flexible.
The NVIDIA 367.35 drivers appear t
This reverts commit 4e549ddb500cf677b6fa16d9ebdfa67cc23da097,
dropping the hack from Gallium that I just deleted from i965.
See the previous commit for rationale.
---
src/mesa/state_tracker/st_cb_blit.c | 32
1 file changed, 32 deletions(-)
diff --git a/src/mesa/
For a long time, the Mesa i965 driver has contained a hack to override
color spaces to sRGB when doing multisample resolves, with the following
justification:
* It has been observed that mulitisample resolves produce slightly better
* looking images when averaging is done using destination format.
OpenGL originally never did sRGB decode/encode for BlitFramebuffer.
OpenGL ES 3.x has always done sRGB decode/encode for BlitFramebuffer.
OpenGL 4.x specifications attempted to unify this behavior, and
ultimately settled on doing decode/encode if GL_FRAMEBUFFER_SRGB is
enabled, which allows the fu
This appears to be redundant with spec/arb_framebuffer_srgb/blit
which tests many more configurations.
---
tests/all.py| 1 -
tests/fbo/CMakeLists.gl.txt | 1 -
tests/fbo/fbo-srgb-blit.c | 145
3 files changed, 147 deletions(-)
de
Hello,
This combined patch series updates both Piglit and Mesa to implement
the modern GL 4.4+ rules for sRGB encoding/decoding in BlitFramebuffer().
The new GL 4.4 rules make it possible to match the behavior of ES 3.x
(always encode and decode), and the old behavior (never encode or decode).
If
OpenGL 4.4 specifies that BlitFramebuffer should perform sRGB encode
and decode like ES 3.x does, but only when GL_FRAMEBUFFER_SRGB is
enabled. This is technically incompatible in certain cases, but is
more consistent across GL, ES, and WebGL, and more flexible.
The NVIDIA 367.35 drivers appear t
On Thu, 2016-08-04 at 23:55 +0300, Andres Gomez wrote:
> When an argument for a structure constructor or initializer doesn't
> match the expected type, only Section 4.1.10 “Implicit Conversions”
> are allowed to try to match that expected type.
>
> From page 32 (page 38 of the PDF) of the GLSL 1.2
On 04/08/16 19:04, Eric Anholt wrote:
Martin Peres writes:
This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and
fixes many applications when using DRI3:
- Totem with libva on hw-accelerated decoding
- obs-studio, using Window Capture (Xcomposite) as a Source
- gstreamer wi
On Thu, Aug 4, 2016 at 2:54 PM, Sam Halliday wrote:
> Thanks Jan,
>
> This is what it comes up with
> https://gist.github.com/fommil/c97d4c8fb2790e28ecaf8d334ebf1746
>
> Are there any demo apps I could expect to run with this? What is
> involved in writing missing functionality?
>
I'll let other
On 05/08/16 00:24, Mark Janes wrote:
I saw no regressions from these tests. However, I wasn't able to run
the dEQP-EGL tests the last time I tried. What branch of dEQP are you
running?
InternalError (Runtime check failed: '(m_capabilities &
CAPABILITY_GET_DISPLAY_PLATFORM) == 0' at egl
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 so
I saw no regressions from these tests. However, I wasn't able to run
the dEQP-EGL tests the last time I tried. What branch of dEQP are you
running?
InternalError (Runtime check failed: '(m_capabilities &
CAPABILITY_GET_DISPLAY_PLATFORM) == 0' at egluNativeDisplay.cpp:70)
-Mark
Chad Versa
When an argument for a structure constructor or initializer doesn't
match the expected type, only Section 4.1.10 “Implicit Conversions”
are allowed to try to match that expected type.
From page 32 (page 38 of the PDF) of the GLSL 1.20 spec:
" The arguments to the constructor will be used to set
v2: Refactor also the conversion to constant and replacement code
(Timothy).
Signed-off-by: Andres Gomez
---
src/compiler/glsl/ast_function.cpp | 166 +++--
1 file changed, 86 insertions(+), 80 deletions(-)
diff --git a/src/compiler/glsl/ast_function.cpp
b/s
Hi,
On Thu, 2016-08-04 at 20:54 +0100, Sam Halliday wrote:
> Thanks Jan,
>
> This is what it comes up with
> https://gist.github.com/fommil/c97d4c8fb2790e28ecaf8d334ebf1746
looks OK.
>
> Are there any demo apps I could expect to run with this?
I was able to successfully run GEGL(GIMP) image m
On Tue, Aug 2, 2016 at 4:38 PM, Nicolai Hähnle wrote:
> On 29.07.2016 23:42, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> ---
>> src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 2 +-
>> src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
I'll test it.
Chad Versace writes:
> Hi Intel folks, could one of you please run this through Jenkins?
> I verified manually that it fixes the listed dEQP tests on Skylake.
>
> Chad Versace (2):
> i965: Fix miptree layout for EGLImage-based renderbuffers
> i965: Respect miptree offsets in in
When glEGLImageTargetRenderbufferStorageOES() was given an EGLImage
created from the non-base slice of a miptree,
intel_image_target_renderbuffer_storage() forgot to apply the intra-tile
offsets __DRIimage::tile_x,tile_y to the miptree layout.
This patch fixes the problem with a quick hack suitabl
Hi Intel folks, could one of you please run this through Jenkins?
I verified manually that it fixes the listed dEQP tests on Skylake.
Chad Versace (2):
i965: Fix miptree layout for EGLImage-based renderbuffers
i965: Respect miptree offsets in intel_readpixels_tiled_memcpy()
src/mesa/drivers/
Respect intel_miptree_slice::x_offset,y_offset and
intel_mipmap_tree::offset. All three may be non-zero when glReadPixels
is called on an EGLImage created from the non-base slice of a miptree.
Patch 2/2 that fixes test
'dEQP-EGL.functional.image.create.gles2_cubemap_*'.
Reported-by: Haixia Shi
D
Thanks Jan,
This is what it comes up with
https://gist.github.com/fommil/c97d4c8fb2790e28ecaf8d334ebf1746
Are there any demo apps I could expect to run with this? What is
involved in writing missing functionality?
Number of platforms 1
Platform Name Clover
Platform Vendor Mesa
Platform Version O
From: Marek Olšák
Some ideas copied from Jakob Sinclair's implementation, but the color
clearing is completely different.
v2: remove leftover code, disable conditional rendering
---
docs/GL3.txt | 2 +-
docs/relnotes/12.1.0.html | 1 +
src/gallium/
On Aug 4, 2016 13:17, "Marek Olšák" wrote:
>
> On Thu, Aug 4, 2016 at 8:04 PM, Ilia Mirkin wrote:
> > I believe that clear depth stencil is meant to respect the render
condition,
> > while clear texture is not. In nouveau I "solved" this by ignoring the
> > render condition in the clear depth ste
On Aug 4, 2016 10:33 AM, "Marek Olšák" wrote:
>
> On Thu, Aug 4, 2016 at 3:31 PM, Jason Ekstrand
wrote:
> > Hey Marek, Thanks for working on this!
> >
> > On Aug 4, 2016 7:39 AM, "Marek Olšák" wrote:
> >>
> >> Hi,
> >>
> >> This is my definition so far, which is an intersection of AMD and NV
>
On Thu, Aug 4, 2016 at 8:04 PM, Ilia Mirkin wrote:
> I believe that clear depth stencil is meant to respect the render condition,
> while clear texture is not. In nouveau I "solved" this by ignoring the
> render condition in the clear depth stencil function too, since nothing in
> Mesa relied on i
I believe that clear depth stencil is meant to respect the render
condition, while clear texture is not. In nouveau I "solved" this by
ignoring the render condition in the clear depth stencil function too,
since nothing in Mesa relied on it iirc.
On Aug 4, 2016 12:57, "Marek Olšák" wrote:
> From
On Thu, Aug 4, 2016 at 7:56 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Some ideas copied from Jakob Sinclair's implementation, but the color
> clearing is completely different.
> ---
> docs/GL3.txt | 2 +-
> docs/relnotes/12.1.0.html | 1 +
> sr
From: Marek Olšák
Some ideas copied from Jakob Sinclair's implementation, but the color
clearing is completely different.
---
docs/GL3.txt | 2 +-
docs/relnotes/12.1.0.html | 1 +
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/driver
Hi Eric,
after your question:
[snip]
I expect, with enums having varying size, that this cast will
not always work.
[snip]
I started a script for testing with variable enum sizes and compilers...
If does makes sense to you, I'll try to loop from 1 to n (suggestions?) and
build with gcc and clang
On 2016-08-02 03:46:27, Tomasz Figa wrote:
> As a preparation to use the lookup in more than once place, move the
> code that looks up given KMS/GEM handle to a separate function. This
> change should not introduce any functional changes.
>
> v2: Split into separate patch.
> Move lookup code i
Hi Andy,
On Thu, Aug 4, 2016 at 8:48 PM, Andy Furniss wrote:
> Nayan Deshmukh wrote:
>
>> Hi Andy,
>>
>> Thanks for testing my patches.
>>
>
> NP
>
>
> The scaling happens after CSC.
>>>
>>
> OK, thanks.
>
>
> I believe there is some misunderstanding here, I was able to see the
>> artifacts in
On 08/04/2016 10:40 AM, Miklós Máté wrote:
On 07/14/2016 10:43 PM, Miklós Máté wrote:
On 07/07/2016 07:11 PM, Miklós Máté wrote:
On 06/26/2016 09:48 PM, Miklós Máté wrote:
Only include the ones that can be used by the shader.
This fixes texture coordinates, which were completely wrong,
becaus
On 07/14/2016 10:43 PM, Miklós Máté wrote:
On 07/07/2016 07:11 PM, Miklós Máté wrote:
On 06/26/2016 09:48 PM, Miklós Máté wrote:
Only include the ones that can be used by the shader.
This fixes texture coordinates, which were completely wrong,
because WPOS was included in the list of attribs.
Hi,
these days I have been trying to fix a test that uses transform feedback
on the out varying of a tessellation shader. The relevant part on that
shader is like this:
layout (vertices=4) out;
out block { vec4 value; } user_out[];
The test tries to use block.value as the varying name whe
Martin Peres writes:
> This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and
> fixes many applications when using DRI3:
> - Totem with libva on hw-accelerated decoding
> - obs-studio, using Window Capture (Xcomposite) as a Source
> - gstreamer with VAAPI
>
> Cc: mesa-sta...@lists
On Thu, Aug 4, 2016 at 3:31 PM, Jason Ekstrand wrote:
> Hey Marek, Thanks for working on this!
>
> On Aug 4, 2016 7:39 AM, "Marek Olšák" wrote:
>>
>> Hi,
>>
>> This is my definition so far, which is an intersection of AMD and NV
>> rectangles:
>>
>> Definition and behavior:
>> - The rectangle pr
Nayan Deshmukh wrote:
Hi Andy,
Thanks for testing my patches.
NP
The scaling happens after CSC.
OK, thanks.
I believe there is some misunderstanding here, I was able to see the
artifacts in the video that you sent me previously. But I was not
able to replicate them
Yea, I got that -
On Aug 4, 2016 2:57 AM, "Enrico Weigelt, metux IT consult" <
enrico.weig...@gr13.net> wrote:
>
> 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
On Thu, Aug 4, 2016 at 10:43 PM, Martin Peres
wrote:
>
>
> On 04/08/16 15:17, Nicolas Boichat wrote:
>>
>> On Thu, Aug 4, 2016 at 7:17 PM, Martin Peres
>> wrote:
>>>
>>>
>>>
>>> On 04/08/16 13:08, Nicolas Boichat wrote:
On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres
wrote:
On 04/08/16 15:17, Nicolas Boichat wrote:
On Thu, Aug 4, 2016 at 7:17 PM, Martin Peres
wrote:
On 04/08/16 13:08, Nicolas Boichat wrote:
On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres
wrote:
On 04/08/16 05:07, Nicolas Boichat wrote:
egl/x11 fixup has already be sent here:
https://patch
On 08/04/2016 07:56 AM, Jason Ekstrand wrote:
On Aug 4, 2016 12:46 AM, "Enrico Weigelt, metux IT consult"
mailto:enrico.weig...@gr13.net>> wrote:
>
> 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 o
Although malloc is unlikely to fail check its return value nevertheless.
Signed-off-by: Frank Binns
Reviewed-by: Eric Engestrom
---
src/egl/wayland/wayland-drm/wayland-drm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c
b/src/egl/wayland/waylan
When trying to get a device name for an fd using sysfs, it would always fail
as it was expecting key/value pairs to be delimited by '\0', which is not the
case.
Signed-off-by: Frank Binns
Reviewed-by: Eric Engestrom
---
src/loader/loader.c | 6 --
1 file changed, 4 insertions(+), 2 deletion
On Aug 4, 2016 12:46 AM, "Enrico Weigelt, metux IT consult" <
enrico.weig...@gr13.net> wrote:
>
> 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 exper
On 20/06/16 12:05, Axel Davy wrote:
Hi,
The three patches make sense to me.
Reviewed-by: Axel Davy
Can someone push these patches for me?
Thanks
Frank
On 17/06/2016 19:41, Frank Binns wrote :
Up until now, DRI3 was only used for devices that have render nodes,
unless
overridden via an e
Hey Marek, Thanks for working on this!
On Aug 4, 2016 7:39 AM, "Marek Olšák" wrote:
>
> Hi,
>
> This is my definition so far, which is an intersection of AMD and NV
rectangles:
>
> Definition and behavior:
> - The rectangle primitive is defined by its first 3 vertices.
> - The 4th vertex is deri
This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and
fixes many applications when using DRI3:
- Totem with libva on hw-accelerated decoding
- obs-studio, using Window Capture (Xcomposite) as a Source
- gstreamer with VAAPI
Cc: mesa-sta...@lists.freedesktop.org
Bugzilla: https://b
For the series:
Reviewed-by: Marek Olšák
Marek
On Wed, Aug 3, 2016 at 10:56 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> ---
> src/gallium/drivers/radeonsi/si_shader.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shade
Hi,
This is my definition so far, which is an intersection of AMD and NV rectangles:
Definition and behavior:
- The rectangle primitive is defined by its first 3 vertices.
- The 4th vertex is derived (extrapolated) during rasterization.
- It's treated as a triangle by all stages before rasterizat
https://bugs.freedesktop.org/show_bug.cgi?id=97136
Nicolas Boichat changed:
What|Removed |Added
CC|nico...@boichat.ch |
--
You are receiving this mail becau
https://bugs.freedesktop.org/show_bug.cgi?id=97136
Nicolas Boichat changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
On Thu, Aug 4, 2016 at 7:17 PM, Martin Peres
wrote:
>
>
> On 04/08/16 13:08, Nicolas Boichat wrote:
>>
>> On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres
>> wrote:
>>>
>>> On 04/08/16 05:07, Nicolas Boichat wrote:
egl/x11 fixup has already be sent here:
https://patchwork.freedesk
On 04/08/16 13:08, Nicolas Boichat wrote:
On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres
wrote:
On 04/08/16 05:07, Nicolas Boichat wrote:
egl/x11 fixup has already be sent here:
https://patchwork.freedesktop.org/patch/101934/
Compile-tested only (on android only).
I was first thinking of mo
Hi Andy,
Thanks for testing my patches.
On Thu, Aug 4, 2016 at 5:23 AM, Andy Furniss wrote:
> Nayan Deshmukh wrote:
>
>> Hi Christian
>>
>> On Wed, Aug 3, 2016 at 6:16 PM, Christian König
>> wrote:
>>
>> Sorry for the delay I've been on vacation for a week.
>>>
>>> Good to hear back from you !
On 04/08/16 11:25, Enrico Weigelt, metux IT consult wrote:
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.
On 08/04/2016 09:57 AM, Enrico Weigelt, metux IT consult wrote:
> 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
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 su
On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres
wrote:
> On 04/08/16 05:07, Nicolas Boichat wrote:
>>
>> egl/x11 fixup has already be sent here:
>> https://patchwork.freedesktop.org/patch/101934/
>>
>> Compile-tested only (on android only).
>>
>> I was first thinking of modifying most functions in eg
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 st
On 04/08/16 05:07, Nicolas Boichat wrote:
egl/x11 fixup has already be sent here:
https://patchwork.freedesktop.org/patch/101934/
Compile-tested only (on android only).
I was first thinking of modifying most functions in egl_dri2.c to take in
dri2_egl_display *dri2_dpy instead of _EGLDisplay *d
On 04/08/16 01:48, Enrico Weigelt, metux IT consult wrote:
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,
On Thu, Aug 4, 2016 at 7:48 AM, Enrico Weigelt, metux IT consult
wrote:
> 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:
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
___
mes
80 matches
Mail list logo
