Yeah, agree adding SDNodes for every intrinsic sounds odd.
SDNodes should be the source of the selection process, not it's destination.
Christian.
Am 17.06.2014 03:51, schrieb Marek Olšák:
Is there any specific reason for using SDNodes for everything?
Using intrinsics directly in patterns see
https://bugs.freedesktop.org/show_bug.cgi?id=80069
--- Comment #3 from luigi ---
hi.i have similar but harmless here.
i see a black screen with movable cursor about 10-15 seconds before kde
desktop.
its make a retard to meet kde.
mesa:10.2.1 kde:4.13.2 system: archlinux-64
device: 8086:016
Hi Ian,
On Mon, 2014-06-16 at 12:20 -0700, Ian Romanick wrote:
> On 04/21/2014 04:38 AM, Iago Toral Quiroga wrote:
> > Currently it only considers the cases of gl_ModelViewProjectionMatrix and
> > gl_TextureMatrix. The same optimization can be done also for
> > gl_ModelViewMatrix, gl_ProjectionMat
On Mon, Jun 16, 2014 at 12:22:43PM -0700, Ian Romanick wrote:
> Yeah, that looks right.
>
> Reviewed-by: Ian Romanick
>
> Did you notice if other drivers have the same off-by-one issue?
I didn't spot similar problems elsewhere.
>
> On 06/16/2014 11:22 AM, ville.syrj...@linux.intel.com wrote:
From: Roland Scheidegger
Such conversions (which are most likely rather pointless in practice) were
resulting in shifts with negative shift counts and shifts with counts the same
as the bit width. This was always undefined in llvm, the code generated was
rather horrendous but happened to work.
So
On 06/16/2014 07:34 PM, Ian Romanick wrote:
From: Ian Romanick
Previously, calling
glGenTextures(1, &t);
glBindTexture(GL_TEXTURE_2D, t);
glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, 0xDEADBEEF, &value);
would not generate an error.
Signed-off-by: Ian Romanick
Cc: "10.2"
---
On 06/16/2014 07:34 PM, Ian Romanick wrote:
From: Ian Romanick
There are no texture borders in any version of OpenGL ES or desktop
OpenGL core profile.
Fixes piglit's gl-3.2-texture-border-deprecated.
Signed-off-by: Ian Romanick
Cc: "10.2
---
src/mesa/main/texparam.c | 4
1 file cha
On 06/16/2014 07:34 PM, Ian Romanick wrote:
From: Ian Romanick
There are no queries for GL_TEXTURE_LUMINANCE_SIZE,
GL_TEXTURE_INTENSITY_SIZE, GL_TEXTURE_LUMINANCE_TYPE, or
GL_TEXTURE_INTENSITY_TYPE in any version of OpenGL ES or desktop OpenGL
core profile.
NOTE: Without changes to piglit, thi
https://bugs.freedesktop.org/show_bug.cgi?id=80115
--- Comment #2 from luigi ---
hi.i set environment vars like:
MESA_DEBUG=1 LIBGL_DEBUG=verbose
i cannot see any libgl error in my kwin.log [1] for mesa-10.2.1
But this was slightly happen to me:
https://bugs.freedesktop.org/show_bug.cgi?id
On Mon, Jun 16, 2014 at 09:19:59PM +0200, Marek Olšák wrote:
> Why are there SDNodes for the other "sample" intrinsics then?
>
The reason there are SDnodes for sample intrinsics is because at one point he
had
to modify the type of the resource description and the easiest way to do that
was by re
On Thu, Jun 12, 2014 at 3:11 AM, Carl Worth wrote:
> Previously, the test suite was expecting the compiler to allow a redefintion
> of a macro with whitespace added, but gcc is more strict and allows only for
> changes in the amounts of whitespace, (but insists that whitespace exist or
> not in ex
On 17/06/14 13:58, srol...@vmware.com wrote:
From: Roland Scheidegger
Such conversions (which are most likely rather pointless in practice) were
resulting in shifts with negative shift counts and shifts with counts the same
as the bit width. This was always undefined in llvm, the code generated
This is for reporting whether or not double precision floating-point
operations are supported.
---
src/gallium/auxiliary/gallivm/lp_bld_limits.h | 2 ++
src/gallium/auxiliary/tgsi/tgsi_exec.h| 2 ++
src/gallium/docs/source/screen.rst| 2 ++
src/gallium/drivers/r300/r300_screen.
From: Matt Arsenault
---
src/gallium/state_trackers/clover/api/device.cpp | 11 +--
src/gallium/state_trackers/clover/core/device.cpp | 24 +++
src/gallium/state_trackers/clover/core/device.hpp | 3 +++
3 files changed, 36 insertions(+), 2 deletions(-)
diff --git a
---
src/gallium/state_trackers/clover/api/device.cpp | 4 +++-
src/gallium/state_trackers/clover/core/device.cpp | 6 ++
src/gallium/state_trackers/clover/core/device.hpp | 1 +
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/api/device.cpp
b/
An LLVMContext should only be accessed by a single and using the global
context was causing crashes in multi-threaded environments. Now we use
a separate context for each compile.
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 15 +--
1 file changed, 9 insertions(+), 6 de
From: Matt Arsenault
If there were only warnings, they would not be added to the log.
Also fixes valgrind use after free errors.
---
src/gallium/state_trackers/clover/core/compiler.hpp | 3 ++-
src/gallium/state_trackers/clover/core/error.hpp | 2 +-
src/gallium/state_trackers/clover/co
On Tue, Jun 10, 2014 at 4:41 PM, Matt Turner wrote:
> On Tue, May 27, 2014 at 6:47 PM, Matt Turner wrote:
>> Here's a respin of my load_payload series from mid-April with some
>> feedback from Ken addressed and some bugs fixed.
>>
>>git://people.freedesktop.org/~mattst88/mesa tex-sources
>
>
Similar to previous commits, this allows us to minimise some
of the duplication by compacting all vdpau targets into a
single library.
v2:
- Include the radeon winsys only when there is a user for it.
Cc: Christian König
Signed-off-by: Emil Velikov
---
configure.ac
The r600 equivalent of previous commit.
v2:
- Correctly include the radeon winsys/radeon_common.
Cc: Christian König
Signed-off-by: Emil Velikov
---
configure.ac | 3 +-
src/gallium/Automake.inc | 20 -
src/gallium/targets/Makefile.
The r600 counterpart of previous commit - now the libomx-r600 is
built into the libomx-mesa library. Providing a single library per API.
v2:
- Include the radeon winsys only when there is a user for it.
Cc: Leo Liu
Cc: Christian König
Signed-off-by: Emil Velikov
---
configure.ac
The radeonsi counterpart of previous commit - now libomx-radeonsi is
built into the libomx-mesa library. Providing a single library per API.
v2:
- Include the radeon winsys only when there is a user for it.
Cc: Leo Liu
Cc: Christian König
Signed-off-by: Emil Velikov
---
configure.ac
Similar to previous commit, this allows us to minimise some
of the duplication by compacting all vdpau targets into a
single library.
v2:
- Include the radeon winsys only when there is a user for it.
Cc: Christian König
Signed-off-by: Emil Velikov
---
configure.ac
https://bugs.freedesktop.org/show_bug.cgi?id=80115
--- Comment #3 from jpsinthe...@verizon.net ---
(In reply to comment #2)
> hi.i set environment vars like:
>
> MESA_DEBUG=1 LIBGL_DEBUG=verbose
>
> i cannot see any libgl error in my kwin.log [1] for mesa-10.2.1
>
> But this was slightly happ
From: Ian Romanick
Commit c1c1cf5f9 added infrastructure for saving and restoring draw
buffer state. However, it universially used MAX_DRAW_BUFFERS, but many
drivers support far fewer than that at limit. For example, the radeon
and i915 drivers only support 1. Using MAX_DRAW_BUFFERS causes met
https://bugs.freedesktop.org/show_bug.cgi?id=80115
Ian Romanick changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|mesa-dev@list
On 06/17/2014 05:07 AM, Iago Toral wrote:
> Hi Ian,
>
> On Mon, 2014-06-16 at 12:20 -0700, Ian Romanick wrote:
>> On 04/21/2014 04:38 AM, Iago Toral Quiroga wrote:
>>> Currently it only considers the cases of gl_ModelViewProjectionMatrix and
>>> gl_TextureMatrix. The same optimization can be done
On 12/06/14 20:56, Emil Velikov wrote:
> Hi all,
>
> These patches add support for building (grouping) the various targets per
> API, meaning that only one library will be created for e.g. vdpau
> (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink
> to it.
>
> This allows u
Hi all,
As a follow up to the static/shared pipe-drivers series here is the final
series (if anyone is interested I may take a look at egl + opencl) of
refactoring the gallium dri targets into a single library/provider.
In a nutshell:
- Convert one target per patch.
- Merge the drm and sw backe
With this commit we add a couple of DEFINES making the ST code
conditional, in a way that we can use it to gradually convert
the dri-targets from separate libraries into a single one.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/dri/common/dri_screen.c | 17 +-
src/gall
Identical to previous commits - will bring us a step closer
to megadrivers.
Cc: Chia-I Wu
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/target-helpers/inline_drm_helper.h | 12
src/gallium/targets/dri/Makefile.am | 5 +
2 files changed, 17 insertio
Related to previous commit, merge the separate dri targets to a single
one.
This is essentially all the buildsystem mayhem required for megaradeon.
Cc: Marek Olšák
Cc: Michel Dänzer
Cc: Christian König
Signed-off-by: Emil Velikov
---
configure.ac | 9 +--
Convert the final hardware driver to a single dri provider which
includes all the pipe-drivers.
Update the scons build and drop the unused vmw_powf.c.
Cc: José Fonseca
Cc: Brian Paul
Cc: Jakob Bornecrantz
Signed-off-by: Emil Velikov
---
configure.ac | 3
Will be used to create the single dri target library, on our
way to convert all the dri targets during the conversion to
to static/shared pipe-drivers.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/dri/drm/Makefile.am | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
Cc: Jose Fonseca
Cc: Brian Paul
Cc: Jakob Bornecrantz
Signed-off-by: Emil Velikov
---
src/gallium/targets/dri/SConscript | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/targets/dri/SConscript
b/src/gallium/targets/dri/SConscript
index 9908b51..5b5ddc6 100644
--- a/src/gal
Signed-off-by: Emil Velikov
---
configure.ac| 18 +-
src/gallium/targets/dri-swrast/Makefile.am | 13 +++--
src/gallium/targets/dri-swrast/swrast_drm_api.c | 2 +-
3 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/co
Now we don't need a second dri module when using kgsl :)
Cc: Rob Clark
Signed-off-by: Emil Velikov
---
configure.ac| 3 +-
src/gallium/targets/Makefile.am | 6 ---
src/gallium/targets/dri-freedreno/Makefile.am | 59
With all the hw drivers converted, we can remove the no longer used library.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/dri/drm/Makefile.am | 13 +++--
src/gallium/targets/dri/Makefile.am| 2 +-
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/
The symbol is introduced by the mesa megadrivers, and
adding gallium support for it will allow us to merge
st/dri/drm and st/dri/sw. Resulting in a single dri library
across all of gallium.
Signed-off-by: Emil Velikov
---
.../auxiliary/target-helpers/inline_drm_helper.h | 36 ++
Identical to previous commits - will bring us a step closer
to megadrivers.
Cc: Jose Fonseca
Cc: Brian Paul
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/target-helpers/inline_drm_helper.h | 12
src/gallium/targets/dri/Makefile.am | 5 +
2 files c
Identical to previous two commits - will bring us a step closer
to megadrivers.
Cc: Rob Clark
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/target-helpers/inline_drm_helper.h | 12
src/gallium/targets/dri/Makefile.am | 5 +
2 files changed, 17 inse
Similiar to other targets, we'd like to convert all the separate
targets into a single one, thus we'll minimize the duplication and
overall size of mesa. The conversion per API basis, with the drivers
available either statically or shared. Currently the former is the
default.
Signed-off-by: Emil V
Cc: Stephane Marchesin
Signed-off-by: Emil Velikov
---
configure.ac | 3 +-
src/gallium/targets/Makefile.am | 6
src/gallium/targets/dri-i915/Makefile.am | 59
src/gallium/targets/dri-i915/target.c| 29 -
The symbol is introduced by the mesa megadrivers, and adding
gallium support for it will allow us to merge st/dri/drm and
st/dri/sw. Resulting in a single dri library across gallium.
Signed-off-by: Emil Velikov
---
.../auxiliary/target-helpers/inline_drm_helper.h| 12
src/galliu
Cc: Chia-I Wu
Signed-off-by: Emil Velikov
---
configure.ac| 3 +-
src/gallium/targets/Makefile.am | 6
src/gallium/targets/dri-ilo/Makefile.am | 52 -
src/gallium/targets/dri-ilo/target.c| 44 -
Identical to previous commits - will bring us a step closer
to megadrivers.
Cc: Stephane Marchesin
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/target-helpers/inline_drm_helper.h | 12
src/gallium/targets/dri/Makefile.am | 5 +
2 files changed, 17
Move the driver_name to dri2/drisw and remove all the SPLIT_TAGETS
mayhem. In the next step we'll unify the dri and dri-swrast targets,
completing the gallium DRI megadriver.
Signed-off-by: Emil Velikov
---
src/gallium/Automake.inc | 2 +-
src/gallium/state_trackers/dr
Convert the final dri target to the single DRI (megadriver) library.
Cleanup all the automake leftovers from the conversion stage and
update the scons build.
Signed-off-by: Emil Velikov
---
configure.ac | 3 +-
src/gallium/Automake.inc
Export the approapriate new symbol, and keep backwards compat
via the megadriver_stub helper library.
Our next and final step would be to unify dri/drm and dri/sw,
leading to a complete megadrivers solution, and having a single
library that provides dri across all targets.
Signed-off-by: Emil Vel
With all the users converted to __driGetExtensions_* we can
have only a single inclusion of the required header + define.
Signed-off-by: Emil Velikov
---
.../auxiliary/target-helpers/inline_drm_helper.h | 11 +++-
src/gallium/targets/dri/Makefile.am| 31 +---
... and use libmegadriver_stub as their provider.
Teach scons how to build the library archive and use it.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/dri/drm/dri2.c | 21 -
src/gallium/targets/dri/Makefile.am | 1 +
src/gallium/targets/dri/SConscript
Rather than building two identical ones for dri-vmwgfx and dri-swrast
build a single library, and drop some duplication in the build.
Signed-off-by: Emil Velikov
---
src/gallium/targets/dri-swrast/SConscript | 4 +--
src/gallium/targets/dri/SConscript| 2 +-
src/mesa/drivers/dri/common
On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov wrote:
> Hi all,
>
> These patches add support for building (grouping) the various targets per
> API, meaning that only one library will be created for e.g. vdpau
> (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink
> to it.
>
>
On 17/06/14 19:39, Ilia Mirkin wrote:
> On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov
> wrote:
>> Hi all,
>>
>> These patches add support for building (grouping) the various targets per
>> API, meaning that only one library will be created for e.g. vdpau
>> (libvdpau_gallium) with individual one
This looks ok to me though since tgsi currently doesn't have any double
opcodes (well the docs have them...) it doesn't really apply to most
drivers (at least I assume you don't want to add support for it for tgsi).
Roland
Am 17.06.2014 18:44, schrieb Tom Stellard:
> This is for reporting whethe
On Tue, Jun 17, 2014 at 3:05 PM, Emil Velikov wrote:
> On 17/06/14 19:39, Ilia Mirkin wrote:
>> On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov
>> wrote:
>>> Hi all,
>>>
>>> These patches add support for building (grouping) the various targets per
>>> API, meaning that only one library will be cre
Hi Roshan,
I've just gotten into the game myself, so I guess i can provide some
newbie-info.
I guess by "the list" you are referring to the suggestions for GSoC
projects posted.
I think the application date for GSoC is long passed (so no pay :/ ),
but I don't think anyone will bash you for taking
On 06/17/14 12:35 PM, Thomas Helland wrote:
I think the application date for GSoC is long passed (so no pay :/ ),
Yes - we're about to hit the midpoint of GSoC - applications were done months
ago, selections made already, and students should be making good progress by
now.
The X.Org Foundation
Ping? I'm not sure if this is completely correct, but this code path is
only excercised by VDPAU and it seems to work fine on SI.
Grigori
On 04.06.2014 18:54, Grigori Goronzy wrote:
> This makes 4:2:2 video surfaces work in VDPAU.
> ---
> src/gallium/drivers/radeon/r600_texture.c | 5 +-
> src/
From: Marek Olšák
---
docs/GL3.txt | 2 +-
docs/relnotes/10.3.html | 1 +
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
src/gallium/drivers/radeonsi/si_shader.c | 63
4 files changed, 42 insertions(+), 26 deletio
On 17/06/14 20:25, Ilia Mirkin wrote:
> On Tue, Jun 17, 2014 at 3:05 PM, Emil Velikov
> wrote:
>> On 17/06/14 19:39, Ilia Mirkin wrote:
>>> On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov
>>> wrote:
Hi all,
These patches add support for building (grouping) the various targets per
>
This looks good to me.
Reviewed-by: Marek Olšák
Marek
On Wed, Jun 4, 2014 at 6:54 PM, Grigori Goronzy wrote:
> This makes 4:2:2 video surfaces work in VDPAU.
> ---
> src/gallium/drivers/radeon/r600_texture.c | 5 +-
> src/gallium/drivers/radeonsi/si_blit.c| 91
> ++--
On Tue, Jun 17, 2014 at 4:25 PM, Emil Velikov wrote:
> On 17/06/14 20:25, Ilia Mirkin wrote:
>> On Tue, Jun 17, 2014 at 3:05 PM, Emil Velikov
>> wrote:
>>> On 17/06/14 19:39, Ilia Mirkin wrote:
On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov
wrote:
> Hi all,
>
> These patch
Sorry if this is a stupid question, but are you only talking about
gallium-gbm? What is the purpose of the gbm state tracker and how is
it different from the default one in src/gbm?
Thanks,
Marek
On Tue, Jun 17, 2014 at 10:25 PM, Emil Velikov wrote:
> On 17/06/14 20:25, Ilia Mirkin wrote:
>> On
On 17/06/14 21:30, Marek Olšák wrote:
> Sorry if this is a stupid question, but are you only talking about
> gallium-gbm? What is the purpose of the gbm state tracker and how is
> it different from the default one in src/gbm?
>
The whole of these series (in the various forms that have been on the
Sure. Can you give me a git link and a branch name?
Marek
On Tue, Jun 17, 2014 at 11:06 PM, Emil Velikov wrote:
> On 17/06/14 21:30, Marek Olšák wrote:
>> Sorry if this is a stupid question, but are you only talking about
>> gallium-gbm? What is the purpose of the gbm state tracker and how is
>>
On 17/06/14 22:09, Marek Olšák wrote:
> Sure. Can you give me a git link and a branch name?
>
Great, branch static-or-shared-pipe-drivers-v2 at
https://github.com/evelikov/Mesa/
Thanks
Emil
> Marek
>
> On Tue, Jun 17, 2014 at 11:06 PM, Emil Velikov
> wrote:
>> On 17/06/14 21:30, Marek Olšák w
On Tuesday, June 17, 2014 11:17:57 AM Ian Romanick wrote:
> From: Ian Romanick
>
> Commit c1c1cf5f9 added infrastructure for saving and restoring draw
> buffer state. However, it universially used MAX_DRAW_BUFFERS, but many
> drivers support far fewer than that at limit. For example, the radeon
Hi,
I have a couple of questions about this patch:
1) Could you please also change how the results of the
'CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE' and
'CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE' queries are generated?
According to the spec, if 'cl_khr_fp64' is not supported, they should be
0.
2) Whe
https://bugs.freedesktop.org/show_bug.cgi?id=80069
--- Comment #4 from Kenneth Graunke ---
(In reply to comment #3)
> hi.i have similar but harmless here.
@luigi: Ivybridge is a totally different GPU than 855GM. Please file a
separate bug.
--
You are receiving this mail because:
You are the a
From: Roland Scheidegger
Such conversions (which are most likely rather pointless in practice) were
resulting in shifts with negative shift counts and shifts with counts the same
as the bit width. This was always undefined in llvm, the code generated was
rather horrendous but happened to work.
So
On 18 June 2014 05:08, Roland Scheidegger wrote:
> This looks ok to me though since tgsi currently doesn't have any double
> opcodes (well the docs have them...) it doesn't really apply to most
> drivers (at least I assume you don't want to add support for it for tgsi).
I've mostly forward ported
Okay I've been writing this in the background, but I've hit a point I
think I'd like to seek advice on,
So doubles in all SM5 hardware appear to be done using two channels of
floats to store the double value in, the SM5 assembly opcodes all take
xy, zw swizzles etc.
However at the GLSL level I ju
On Jun 17, 2014, at 3:11 PM, Bruno Jimenez wrote:
> Hi,
>
> I have a couple of questions about this patch:
>
> 1) Could you please also change how the results of the
> 'CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE' and
> 'CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE' queries are generated?
> According to t
Signed-off-by: Ilia Mirkin
Cc: "10.2"
---
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 6 ++
src/gallium/drivers/nouveau/nv30/nvfx_fragprog.c | 1 +
2 files changed, 7 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
b/src/gallium/drivers/nouveau/nv30/nv30_sc
Signed-off-by: Ilia Mirkin
Cc: "10.2"
---
src/gallium/drivers/nouveau/nv30/nv30_context.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_context.c
b/src/gallium/drivers/nouveau/nv30/nv30_context.c
index f325c5c..617b088 100644
--- a/src/gallium/driv
This is just a hack, it should be possible to create a temporary zeta
surface and render to that instead. However that's more complicated and
this avoids the render being entirely broken and errors being reported
by the card.
Signed-off-by: Ilia Mirkin
Cc: "10.2"
---
src/gallium/drivers/nouveau
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 33 +-
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 4baabaf..5c3d783 10
On 18.06.2014 05:23, Marek Olšák wrote:
> - emit_data->args[3] = lp_build_const_int32(gallivm, 1 <<
> gather_comp); /* dmask */
> + emit_data->args[3] = lp_build_const_int32(gallivm, dmask); /*
> dmask */
This comment is redundant now. Either way though,
Reviewed-by: Mic
On Tuesday, June 10, 2014 10:51:40 AM Jon TURNEY wrote:
> Nearly all the error cases in *createScreen() issue an error message to
diagnose
> the failure to initialize before branching to handle_error. The few
remaining
> error cases which don't should probably do the same.
>
> (At the moment, i
On Monday, June 09, 2014 05:50:21 PM Ian Romanick wrote:
> On 06/08/2014 03:17 PM, Jordan Justen wrote:
> > This will allow us to utilize the early MESA_EXTENSION_OVERRIDE
> > parsing at the later extension string initialization step.
> >
> > Signed-off-by: Jordan Justen
> > ---
> > src/mesa/mai
81 matches
Mail list logo
