>From: Brian Paul
>Sent: Friday, October 16, 2015 2:25 PM
>To: mesa-dev@lists.freedesktop.org
>Cc: Charmaine Lee; Jose Fonseca; Sinclair Yeh
>Subject: [PATCH 09/10] vbo: fix GL_LINE_LOOP stray line bug
>When long GL_LINE_LOOP primitives don't fit in one vertex buffer they
>have to be split acros
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Analogous to previous commit.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/Makefile.am| 6 --
src/gallium/auxiliary/vl/vl_winsys_dri.c | 8
src/gallium/targets/omx/Makefile.am | 7 +--
src/gallium/targets/omx/target.c | 2 +-
src/gallium/targets/va/
Cc: Axel Davy
Signed-off-by: Emil Velikov
---
src/gallium/targets/d3dadapter9/drm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/targets/d3dadapter9/drm.c
b/src/gallium/targets/d3dadapter9/drm.c
index dc040dc..c9559b9 100644
--- a/src/gallium/targets/d3dadapter9/drm.c
+++ b/s
i.e. plug some (hard to hit) memory leaks.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
b/src/gallium/auxiliary/pipe-loader/pipe_loade
Ported from an identically named commit in st/xa
commit 35cf3831d71770211f29da6608313dc1f6213d7b
Author: Thomas Hellstrom
Date: Thu Jul 3 02:07:36 2014 -0700
st/xa: Don't close the drm fd on failure v2
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/dri/dri2.c | 4 ++--
1 fil
We cannot use this C99 feature here quite yet, as the code needs to be
ok with MSVC prior to 2013.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_load
Already defined as such in struct pipe_loader_device::ops.
Cc: Tom Stellard
Cc: Francisco Jerez
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 4 ++--
src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 4 ++--
2 files changed, 4 insertions(+), 4 deleti
Add a list of driver descriptors and select one from the list, during
probe time.
As we'll need to have all the driver pipe_foo_screen_create() functions
provided externally (i.e. from another static lib) we need a separate
(non-inline) drm_helper, which contains the function declarations.
XXX: M
Covert DRI to use only the pipe-loader interface.
With drisw_create_screen and kms_swrast_create_screen replaced by their
pipe-loader equivalent, we can now drop them.
Linking notes:
- pipe-loader already links in the libloader
- we need GALLIUM_PIPE_LOADER_WINSYS_LIBS for the sw winsys'
XXX:
Analogous to previous commits.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/xa/Makefile.am | 5 -
src/gallium/state_trackers/xa/xa_tracker.c | 16 ++--
src/gallium/targets/xa/Makefile.am | 7 +--
src/gallium/targets/xa/target.c| 2 +-
4 f
Move the winsys into the pipe-target, bla bla bla
XXX: separate pipe-drivers are likely to be busted
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 94 +-
src/gallium/include/state_tracker/sw_driver.h | 21 +
src/gallium/targets
It is to be used in contrast of the dynamic one. The state-tracker does
not need to know if the pipe-driver is built into the final blob or
a separate object. This will allow us to move the logic to the final
step (in target) where the appropriate pipe-loader will be chosen.
Cc: Tom Stellard
Cc:
Analogous to previous commits.
Cc: Axel Davy
Signed-off-by: Emil Velikov
---
src/gallium/targets/d3dadapter9/Makefile.am | 13 -
src/gallium/targets/d3dadapter9/drm.c | 24 +++-
2 files changed, 7 insertions(+), 30 deletions(-)
diff --git a/src/gallium/tar
We delay the null check only to jump through hoops to work around that.
Check early to make our lives easier.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/dri/dri2.c | 22 --
src/gallium/state_trackers/dri/dri_screen.c | 5 -
src/gallium/state_tracker
Otherwise we risk things blowing up due to conflicting symbols.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/util/u_dl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_dl.c
b/src/gallium/auxiliary/util/u_dl.c
index aca435d..9b97d8d 1006
As of earlier all the targets use the non inline version. Don't forget
to remove the function prototypes/declarations.
Signed-off-by: Emil Velikov
---
.../auxiliary/target-helpers/inline_drm_helper.h | 339 -
src/gallium/include/state_tracker/drm_driver.h | 6 -
2 fil
Ported from an identically named commit in st/xa
commit 35cf3831d71770211f29da6608313dc1f6213d7b
Author: Thomas Hellstrom
Date: Thu Jul 3 02:07:36 2014 -0700
st/xa: Don't close the drm fd on failure v2
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/vl/vl_winsys_dri.c | 2 +-
1 fi
With the next commits we'll introduce a 'static' version, which will
essentially load the statically linked-in pipe-drivers, rather than the
standalone pipe-$foo.so ones.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/Makefile.am | 8
src/gallium/targets/d3dadapter9/M
Dead code since commit 8f50614910c40366d94964fe2c5da5772aff2f96
Cc: Axel Davy
Cc: Tiziano Bacocco
Signed-off-by: Emil Velikov
---
src/gallium/targets/d3dadapter9/drm.c | 36 ---
1 file changed, 36 deletions(-)
diff --git a/src/gallium/targets/d3dadapter9/drm.c
Cc: Axel Davy
Signed-off-by: Emil Velikov
---
src/gallium/targets/d3dadapter9/Makefile.am | 1 +
src/gallium/targets/d3dadapter9/drm.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/src/gallium/targets/d3dadapter9/Makefile.am
b/src/gallium/targets/d3dadapter9/Makefile.am
index ca4
Add a 'static' pipe-loader build, which will be used with follow-up
commits.
Signed-off-by: Emil Velikov
---
src/gallium/Android.mk | 1 +
src/gallium/auxiliary/pipe-loader/Android.mk | 49
2 files changed, 50 insertions(+)
create mode 100644
Add a 'static' pipe-loader build, which will be used with follow-up
commits.
Signed-off-by: Emil Velikov
---
src/gallium/SConscript| 1 +
src/gallium/auxiliary/pipe-loader/Makefile.am | 2 ++
src/gallium/auxiliary/pipe-loader/SConscript | 34 +++
Hi all,
Here goes a series (which is slightly overdue), that reworks the
target-helpers into a pipe-loader like interface. As such the
state-tracker do not need to know that there is a difference between the
two and it only uses the pipe-loader interface.
As we have the chance to build the tar
Signed-off-by: Emil Velikov
---
src/gallium/Automake.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/Automake.inc b/src/gallium/Automake.inc
index 095e6ec..6fe2e22 100644
--- a/src/gallium/Automake.inc
+++ b/src/gallium/Automake.inc
@@ -70,5 +70,6 @@ endif
Unlike the inline ones, we'd want to have an extern definition of
the functions. This is required as with follow-up commits, we'll
gradually start using the static pipe-loader. With the latter needing
the symbols.
These are copies directly from the inline version.
XXX: Open to suggestions if we c
Rather than giving false hopes that things might work, just check at
probe time. This allows us to remove the duplication and consolidate
the code wrt the upcomming static pipe-loader.
Cc: Tom Stellard
Cc: Francisco Jerez
Signed-off-by: Emil Velikov
---
.../auxiliary/pipe-loader/pipe_loader_dr
Rather than having all targets include the file, with only some defining
the relevant guard macro, just move things where they are used.
XXX: Can we use __alias__ ? Will it work considering the 'base' symbols
are/should be private ?
Signed-off-by: Emil Velikov
---
.../auxiliary/target-helpers/i
Analogous to previous commit with a small catch.
As the sw inline helpers are mere wrappers, and the screen <> winsys
split is more prominent (with the latter not being part of the final
pipe-driver), things will just work.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_
Due to the nature of the other sw winsys' we cannot use them during the
generic probe stage. As such there is little point in keeping the
abstraction layer.
Cc: Tom Stellard
Cc: Francisco Jerez
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 17
Currently every target makes sure that the screen is non-null prior to
using the debug (trace including) wrappers. If that no longer holds true
we want to know and fix this ASAP rather than silently bailing out.
Signed-off-by: Emil Velikov
---
src/gallium/drivers/trace/tr_screen.c | 3 ---
1 fil
The referenced variable(s) have been removed with commit abc20120e4a
(automake: pipe-loader: remove the 'client' pipe-loader)
Signed-off-by: Emil Velikov
---
configure.ac | 5 -
1 file changed, 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index b75f907..4b9e954 100644
--- a/confi
As of last commit we no longer need the defines in order to have the
function prototypes.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/Makefile.am | 1 -
src/gallium/state_trackers/clover/Makefile.am | 1 -
src/gallium/state_trackers/dri/Makefile.am| 1 -
src/gallium/sta
Will be used as a counterpart for target-helpers'
kms_swrast_create_screen().
XXX: Do we need the extra define ?
Signed-off-by: Emil Velikov
---
configure.ac | 4
src/gallium/Automake.inc | 5 +
src/gallium/auxiliary/pip
Currently the location is determined at configure/build time and
consistently copied across gallium. Just remove the extra argument, and
use PIPE_SEARCH_DIR where appropriate.
This will allow us to remove the duplication in the *configuration and
*screen_create APIs by moving util_dl_get_proc_addr
Allows us to fold the duplication in pipe_loader_sw_probe_*().
Cc: Tom Stellard
Cc: Francisco Jerez
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 38 ++
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/src/gallium/auxili
The tests don't (and shouldn't) need to have anything driver and/or
winsys specific.
Signed-off-by: Emil Velikov
---
src/gallium/tests/trivial/Makefile.am | 4
1 file changed, 4 deletions(-)
diff --git a/src/gallium/tests/trivial/Makefile.am
b/src/gallium/tests/trivial/Makefile.am
index 4
... in favour of HAVE_LIBDRM. After all we solely want to build the code
when the latter is available.
In the not too distant future we will remove the libudev/sysfs
dependency and simplify configure.ac even further.
XXX: Check this wrt the previous 1-2 commits.
Signed-off-by: Emil Velikov
---
Using HAVE_DRI2 to manage it seems counter-intuitive.
XXX: Do we really need this, keep it as is or just use HAVE_LIBDRM ?
Signed-off-by: Emil Velikov
---
configure.ac | 5 +
src/gallium/Makefile.am | 2 +-
src/gallium/drivers/softpipe/Automake
Since the up-streaming of nine, the static target was used by default.
The dynamic pipe-drivers being available only via manual tweak of
configure.ac.
As we'll be removing the library_path argument from the pipe-loader with
follow-up commits, we can remove D3D9_DRIVERS_PATH/D3D9_DRIVERS_DIR.
Every
Cc: Axel Davy
Signed-off-by: Emil Velikov
---
.../auxiliary/target-helpers/inline_sw_helper.h| 27 --
src/gallium/targets/d3dadapter9/Makefile.am| 1 -
src/gallium/targets/d3dadapter9/drm.c | 4 ++--
3 files changed, 2 insertions(+), 30 deletions(-)
As of last few commits we have a static and dynamic pipe-loader. Either
of which will be used with (almost) all targets..
We can look into allowing the user to select which way the targets are
built, be that 'static for all' or 'per target' in follow up commits.
After which we can look into buildi
They serve little to no purpose, as we don't need any additional
dependencies (headers and/or symbols). On the other hand dropping them
will allow us to use GALLIUM_PIPE_LOADER_DEFINES in only one single
place - the pipe-loader.
XXX: Should we provide dummy definition(s) ?
Signed-off-by: Emil Vel
src/mesa/drivers/dri/i965/brw_program.c:94:39:
warning: passing argument 1 of ‘_mesa_init_gl_program’ from incompatible
pointer type [-Wincompatible-pointer-types]
return _mesa_init_gl_program(&prog->program, target, id);
^
Runtime was unaffected a
Fixes regression cased by bb5aeb854915ba67abc56257f830d002c956439e
We don't care about the swizzle when building the name so just skip over it.
---
New piglit test: http://patchwork.freedesktop.org/patch/62111/
src/glsl/lower_ubo_reference.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --g
On Sat, Oct 17, 2015 at 4:31 PM, Ilia Mirkin wrote:
> On Sat, Oct 17, 2015 at 4:24 PM, Jan Vesely wrote:
>> On Sat, 2015-10-17 at 15:24 -0400, Ilia Mirkin wrote:
>>> "compute" in this context is "initialize the compute engine so that
>>> kernels may be executed", not "convert the llvm ir bitcode
On Sat, Oct 17, 2015 at 4:24 PM, Jan Vesely wrote:
> On Sat, 2015-10-17 at 15:24 -0400, Ilia Mirkin wrote:
>> "compute" in this context is "initialize the compute engine so that
>> kernels may be executed", not "convert the llvm ir bitcode that
>> clover
>> hands us into nv50 ir". The former has a
On Sat, 2015-10-17 at 15:24 -0400, Ilia Mirkin wrote:
> "compute" in this context is "initialize the compute engine so that
> kernels may be executed", not "convert the llvm ir bitcode that
> clover
> hands us into nv50 ir". The former has actually been around for
> years,
> Samuel just fixed up a
Reviewed-by: Marek Olšák
On Sat, Oct 17, 2015 at 4:53 PM, Glenn Kennard wrote:
> Supported on R700 and up.
>
> Signed-off-by: Glenn Kennard
> ---
> v2:
> Use correct register for R700, set from r600_emit_db_misc_state
> Added ps_conservative_z field to r600_db_misc_state
> Shrunk ps_cons
"compute" in this context is "initialize the compute engine so that
kernels may be executed", not "convert the llvm ir bitcode that clover
hands us into nv50 ir". The former has actually been around for years,
Samuel just fixed up a few fermi-specific bits.
On Sat, Oct 17, 2015 at 3:11 PM, Jan Ves
Does this mean it should be possible to hook up clover with nouveau?
Jan
On Fri, 2015-10-16 at 19:22 +0200, Samuel Pitoiset wrote:
> Compute support was not enabled by default because weird effects
> on 3D state happened, but I can't reproduce them anymore.
>
> This also enables MP performance c
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #19 from Brian Paul ---
(In reply to Brian Paul from comment #16)
> Unfortunately, after fixing the VBO code, there's still a bug somewhere in
> the gallium 'draw' code. See comments in the patch series for more
> information.
I've
When the draw module splits long line loops, the sections are emitted
as line strips. But the primitive type wasn't set correctly so each
section was being drawn as a loop, introducing extra line segments.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81174
---
src/gallium/auxiliary/dra
This seems surprising... could I convince you to trace a test that
executes both a graphics and compute pipeline, which both use
(different) uniforms?
Anyways, this patch is fine for now, this is Reviewed-by: Ilia Mirkin
On Sat, Oct 17, 2015 at 12:19 PM, Samuel Pitoiset
wrote:
> It looks like b
https://bugs.freedesktop.org/show_bug.cgi?id=90542
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Sat, Oct 17, 2015 at 6:45 PM, Laurent Carlier wrote:
> Le Saturday 17 October 2015, 15:09:13 Marek Olšák a écrit :
>> From: Marek Olšák
>>
>> All tests pass. We don't need to do much - just set CUBE if the view
>> target is CUBE or CUBE_ARRAY, otherwise set the resource target.
>>
>> The reaso
Le Saturday 17 October 2015, 15:09:13 Marek Olšák a écrit :
> From: Marek Olšák
>
> All tests pass. We don't need to do much - just set CUBE if the view
> target is CUBE or CUBE_ARRAY, otherwise set the resource target.
>
> The reason this is so simple can be that texture instructions
> have a g
On Sat, Oct 17, 2015 at 12:36 PM, Brian Paul wrote:
> On 10/17/2015 10:07 AM, Brian Paul wrote:
>>
>> On 10/17/2015 07:04 AM, Rob Clark wrote:
>>>
>>> On Fri, Oct 16, 2015 at 11:11 PM, Brian Paul wrote:
Hi Rob,
Your recent commit "nir: remove dependency on glsl" broke the buil
On 10/17/2015 10:07 AM, Brian Paul wrote:
On 10/17/2015 07:04 AM, Rob Clark wrote:
On Fri, Oct 16, 2015 at 11:11 PM, Brian Paul wrote:
Hi Rob,
Your recent commit "nir: remove dependency on glsl" broke the build
for MSVC
and MinGW.
For MSVC:
[...]
Linking
build\windows-x86-debug\gallium\t
On 10/17/2015 08:35 AM, Marek Olšák wrote:
Patches 2-9:
Reviewed-by: Marek Olšák
I can't comment on 10 without some additional research. Maybe someone
else will review it.
Thanks for the reviews. I think one of my coworkers can take a look.
I tested with a modified piglit lineloop test (pa
On Sat, Oct 17, 2015 at 12:17 PM, Brian Paul wrote:
> On 10/17/2015 10:13 AM, Rob Clark wrote:
>>
>> On Sat, Oct 17, 2015 at 12:07 PM, Brian Paul wrote:
>>>
>>> On 10/17/2015 07:04 AM, Rob Clark wrote:
On Fri, Oct 16, 2015 at 11:11 PM, Brian Paul wrote:
>
>
> Hi Rob,
>
On 10/17/2015 10:13 AM, Rob Clark wrote:
On Sat, Oct 17, 2015 at 12:07 PM, Brian Paul wrote:
On 10/17/2015 07:04 AM, Rob Clark wrote:
On Fri, Oct 16, 2015 at 11:11 PM, Brian Paul wrote:
Hi Rob,
Your recent commit "nir: remove dependency on glsl" broke the build for
MSVC
and MinGW.
For MS
https://bugs.freedesktop.org/show_bug.cgi?id=28130
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=81174
Brian Paul changed:
What|Removed |Added
CC||ideasma...@gmail.com
--- Comment #17 from B
https://bugs.freedesktop.org/show_bug.cgi?id=49779
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=81174
Brian Paul changed:
What|Removed |Added
CC||dongsheng.x...@intel.com
--- Comment #18 fr
On Sat, Oct 17, 2015 at 12:07 PM, Brian Paul wrote:
> On 10/17/2015 07:04 AM, Rob Clark wrote:
>>
>> On Fri, Oct 16, 2015 at 11:11 PM, Brian Paul wrote:
>>>
>>> Hi Rob,
>>>
>>> Your recent commit "nir: remove dependency on glsl" broke the build for
>>> MSVC
>>> and MinGW.
>>>
>>> For MSVC:
>>>
>>
On 10/17/2015 06:20 AM, Roland Scheidegger wrote:
FWIW this probably fixes
https://bugs.freedesktop.org/show_bug.cgi?id=49779 and
https://bugs.freedesktop.org/show_bug.cgi?id=28130 (in contrast to 81174
which as you noted suffers both from a vbo and draw issue). (I believe
the issue in draw is pr
It looks like binding a constant buffer on compute overwrites the 3D
state. To avoid that, we already re-bind all the 3D constant buffers
after launching a compute grid but this is not enough.
Binding the constant buffer of input parameters for the compute state at
initialization corrupts the 3D c
On 10/17/2015 06:23 AM, Marek Olšák wrote:
From: Marek Olšák
This allows removing FLUSH_VERTICES in MatrixMode.
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom_clip.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_a
On 10/17/2015 07:04 AM, Rob Clark wrote:
On Fri, Oct 16, 2015 at 11:11 PM, Brian Paul wrote:
Hi Rob,
Your recent commit "nir: remove dependency on glsl" broke the build for MSVC
and MinGW.
For MSVC:
[...]
Linking build\windows-x86-debug\gallium\tests\graw\occlusion-query.exe ...
Linkin
Supported on R700 and up.
Signed-off-by: Glenn Kennard
---
v2:
Use correct register for R700, set from r600_emit_db_misc_state
Added ps_conservative_z field to r600_db_misc_state
Shrunk ps_conservative_z to uint8 since only 2 bits are needed
Thanks Alex for noting the incorrect register on
Patches 2-9:
Reviewed-by: Marek Olšák
I can't comment on 10 without some additional research. Maybe someone
else will review it.
Marek
On Fri, Oct 16, 2015 at 11:25 PM, Brian Paul wrote:
> ---
> src/mesa/vbo/vbo_save_api.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff
On Fri, Oct 16, 2015 at 6:52 PM, Glenn Kennard wrote:
> Supported on R700 and up.
>
> Signed-off-by: Glenn Kennard
> ---
> Not exactly a commonly used extension, but might as well set the
> hardware registers rather than just dropping the hint on the floor.
>
> src/gallium/drivers/r600/evergreen
Patches 1-2:
Reviewed-by: Marek Olšák
On Thu, Oct 15, 2015 at 9:01 PM, Brian Paul wrote:
> ---
> src/mesa/state_tracker/st_cb_drawpixels.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
> b/src/mesa/state_tracker/st_cb_draw
For the series:
Reviewed-by: Marek Olšák
On Fri, Oct 16, 2015 at 11:58 AM, Iago Toral Quiroga wrote:
> Now that we have separate index spaces for UBOs and SSBOs we do not need
> to iterate through BufferInterfaceBlocks any more, we can just take the
> UBO count directly from NumUniformBlocks.
>
Reviewed-by: Marek Olšák
Marek
On Sat, Oct 17, 2015 at 12:52 AM, Glenn Kennard wrote:
> Supported on R700 and up.
>
> Signed-off-by: Glenn Kennard
> ---
> Not exactly a commonly used extension, but might as well set the
> hardware registers rather than just dropping the hint on the floor.
>
>
Reviewed-by: Marek Olšák
If you're interested, feel free to check out my radeonsi patch on
mesa-dev. It's simpler.
Marek
On Fri, Oct 16, 2015 at 1:53 AM, Glenn Kennard wrote:
> Signed-off-by: Glenn Kennard
> ---
> See also additional texture view piglit test case posted to piglit ml,
> which
From: Marek Olšák
All tests pass. We don't need to do much - just set CUBE if the view
target is CUBE or CUBE_ARRAY, otherwise set the resource target.
The reason this is so simple can be that texture instructions
have a greater effect on the target than the sampler view.
Thanks Glenn for the p
On Fri, Oct 16, 2015 at 11:11 PM, Brian Paul wrote:
> Hi Rob,
>
> Your recent commit "nir: remove dependency on glsl" broke the build for MSVC
> and MinGW.
>
> For MSVC:
>
> [...]
> Linking build\windows-x86-debug\gallium\tests\graw\occlusion-query.exe ...
> Linking build\windows-x86-debug\gal
From: Marek Olšák
This allows removing FLUSH_VERTICES in MatrixMode.
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_atom_clip.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_atom_clip.c
b/src/mesa/state_tracker/st_atom_cl
FWIW this probably fixes
https://bugs.freedesktop.org/show_bug.cgi?id=49779 and
https://bugs.freedesktop.org/show_bug.cgi?id=28130 (in contrast to 81174
which as you noted suffers both from a vbo and draw issue). (I believe
the issue in draw is pretty much the same, since things are split with
too
This looks like a sensible thing to do, but I don't remember all the
details of the vbo module.
Reviewed-by: Marek Olšák
Marek
On Thu, Oct 15, 2015 at 9:02 PM, Brian Paul wrote:
> Whenever we got a glColor, glNormal, glTexCoord, etc. call outside a
> glBegin/End pair, we'd immediately map a ve
Hi,
I've been using afl (http://lcamtuf.coredump.cx/afl/) on the standalone
glsl compiler.
It found four different crashes in the latest code in master and I have
minimised the test cases that cause the crashes. I spent a couple of hours
poking around but haven't managed to fix any of the issues.
This also removes the validation from the parser as it is not required
and once arb_enhanced_layouts comes along we wont be able to do validation
on the stream qualifier in the parser anyway as it adds constant expression
support to the stream qualifier.
Cc: Samuel Iglesias Gonsalvez
Cc: 11.0
--
85 matches
Mail list logo
