On 07/03/2015 12:20 PM, Chris Wilson wrote:
On Fri, Jul 03, 2015 at 10:00:31AM +0300, Abdiel Janulgue wrote:
+void
+gen7_enable_hw_binding_tables(struct brw_context *brw)
+{
+ if (!brw-use_resource_streamer)
+ return;
+
+ if (!brw-hw_bt_pool.bo) {
+ /* We use a single
On Sat, 4 Jul 2015 11:18:18 +0800
Boyan Ding boyan.j.d...@gmail.com wrote:
[snip]
+/* FIXME: Is this right? Seems problematic for WL_bind_wayland_display */
What seems to be the problem ?
Afaik xcb_dri3_open_reply_fds should return an FD which is ok (be that a
render_node device, or
This seems to be doing essentially the same thing as v1? Is it the
right patch?
The llvm pass was invoked in clover in v1. This patch relies on llvm
to perform that task (). What this patch does basically is that it
adds the image attributes to the end of the kernel input vector.
The commit
Since the workaround bo is used strictly as a write-only buffer, we need
only allocate one per screen and use the same one from all contexts.
(The caveat here is during extension initialisation, where we write into
and read back register values from the buffer, but that is performed only
once for
On LLC, all buffers are normally cache coherent between the CPU and the
GPU, giving both parties fast access to shared data.
However, older architectures or Atoms, do not implement LLC between the
CPU and GPU. Instead they utilise a snooping architecture where the GPU
can snoop the CPU cache when
No external users, so no need to export the symbol outside of our
compilation unit.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 36 +--
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 7 --
2 files changed,
Since the purpose of transform feedback tends to be for the client to
act upon the results to change the geometry in the scene, it is likely
that the client will soon be waiting upon the results. Flush the batch
early so that we don't build up a long queue of commands afterwards that
could delay
Avoid unrequired synchronization if the user requests to map an unused
range on active buffer, equivalent to BufferSubData.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 78 +---
1 file changed, 42 insertions(+),
Rather than allocating a fresh page every time we clear a buffer, keep
that page around between invocations by tracking the last used offset
and only allocating a fresh page when we wrap.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
src/mesa/drivers/dri/i965/brw_meta_fast_clear.c |
There are only a handful of distinct cache domains (less than 16), and
internally the kernel simply doesn't care other than whether the object
is a render target. We can therefore trim a parameter by coalescing the
relocation domains to a single unsigned bitfield without loss of
generality.
Move the query for the TIMESTAMP register from context init to the
screen, so that it is only queried once for all contexts.
On 32bit systems, some old kernels trigger a hw bug resulting in the
TIMESTAMP register being shifted and the low bits always zero. Detect
this by repeating the read a few
With the exception of gen8, the sole user of the workaround bo are for
emitting pipe controls. Move it out of the purview of the batchbuffer
and into the pipecontrol.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
src/mesa/drivers/dri/i965/brw_context.c | 7 +
Since we can distinguish when mapping between READ and WRITE, we can
pass along the map mode to avoid stalls and flushes where possible.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 28 ++-
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
index
ralloc's ability to track all pointers belonging to a context and free
them in a single call does not come cheap, and we can reduce the
overhead here by combining the array of BITSETs for a regset into a
single allocation.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Matt Turner
On Sun, Jul 5, 2015 at 3:47 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Sun, Jul 5, 2015 at 9:25 AM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
Other approaches are being considered:
1) Don't use resource wrappers (views) and pass all view parameters
On 4 July 2015 at 04:18, Boyan Ding boyan.j.d...@gmail.com wrote:
Hi Emil,
On 07/03/2015 10:36 PM, Emil Velikov wrote:
Hi Boyan,
Thank you for doing this ! A few suggestions which you might be interesting:
Considering that the backend has handled more than dri2 perhaps we can
do a
Since the last posting, it has grown a few superficial patches for
tweaks in the general area and a couple of drive-bys from looking at the
synmark profiles. As for the main patch, I've worked through the few
piglit regressions and it should be clean on ivb/byt/hsw/bdw to the best
of my knowledge,
All GEN GPU can bind to any piece of memory (thanks UMA), and so through
a special ioctl we can map a chunk of page-aligned client memory into
the GPU address space. However, not all GEN are equal. Some have
cache-coherency between the CPU and the GPU, whilst the others are
incoherent and rely on
Am 05.07.2015 um 15:47 schrieb Ilia Mirkin:
On Sun, Jul 5, 2015 at 9:25 AM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
Other approaches are being considered:
1) Don't use resource wrappers (views) and pass all view parameters
(format, layer range, level) to
Avoid frequent use of reralloc() for tracking the conflicts list, and
walking that list every time we add a transitive conflict, by making the
observation we apply the indirect conflicts by combining the conflicts
of a conflicting register in a second pass.
Reduces brw_compiler_create() from
The vertices require a large chunk of memory, currently allocated during
context creation. However, this memory is not required until use so we
can defer the allocation until the first swrast_Wakeup().
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Kenneth Graunke kenn...@whitecape.org
Since there was an ABI break and linking twice against libudev.so.0 and
libudev.so.1 causes the application to quickly crash, we first check if
the application is currently linked against libudev before dlopening a
local handle. However for backwards/forwards compatability, we need to
inspect the
Fixes regression from
commit 8c17d53823c77ac1c56b0548e4e54f69a33285f1
Author: Kenneth Graunke kenn...@whitecape.org
Date: Wed Apr 15 03:04:33 2015 -0700
i965: Make intel_emit_linear_blit handle Gen8+ alignment restrictions.
which adjusted the coordinates to be relative to the nearest
Zoltán Gilián zoltan.gil...@gmail.com writes:
This seems to be doing essentially the same thing as v1? Is it the
right patch?
The llvm pass was invoked in clover in v1. This patch relies on llvm
to perform that task (). What this patch does basically is that it
adds the image attributes to
From: Michel Dänzer michel.daen...@amd.com
This eliminates the error prone logic in si_shader_vs recalculating this
value.
It also fixes TGSI_SEMANTIC_CLIPDIST outputs incorrectly not being
counted for VS exports, since they are passed to the fragment shader as
varyings as well.
Bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=90821
Philip Derrin philip+freedesk...@breakawayconsulting.com.au changed:
What|Removed |Added
CC|
I thought your patch does something else, but after re-reading it, it
seems to do the right thing.
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Mon, Jul 6, 2015 at 1:38 PM, Marek Olšák mar...@gmail.com wrote:
Hi Michel,
VS_EXPORT_COUNT shouldn't include POS exports (POSITION, MISC
https://bugs.freedesktop.org/show_bug.cgi?id=90466
Emil Velikov emil.l.veli...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On 03/07/15 15:35, Timothy Arceri wrote:
On Fri, 2015-07-03 at 15:08 +0300, Martin Peres wrote:
On 03/07/15 13:55, Timothy Arceri wrote:
This change removes multiple functions designed to validate an array
subscript and replaces them with a call to a single function.
The change also means
On 06/07/15 13:33, Chris Wilson wrote:
Move the query for the TIMESTAMP register from context init to the
screen, so that it is only queried once for all contexts.
On 32bit systems, some old kernels trigger a hw bug resulting in the
TIMESTAMP register being shifted and the low bits always zero.
https://bugs.freedesktop.org/show_bug.cgi?id=69874
Emil Velikov emil.l.veli...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=89131
Emil Velikov emil.l.veli...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Hi Michel,
VS_EXPORT_COUNT shouldn't include POS exports (POSITION, MISC (psize,
edgeflag, layer, viewport), and CLIPDIST/CULLDIST), it should only
count PARAM exports. Setting higher VS_EXPORT_COUNT doesn't affect
correctness but it allocates more parameter memory. CLIPDIST is
special in that
https://bugs.freedesktop.org/show_bug.cgi?id=90905
Emil Velikov emil.l.veli...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=89068
Emil Velikov emil.l.veli...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=45348
Emil Velikov emil.l.veli...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, Jul 06, 2015 at 03:10:48PM +0300, Martin Peres wrote:
On 06/07/15 13:33, Chris Wilson wrote:
Move the query for the TIMESTAMP register from context init to the
screen, so that it is only queried once for all contexts.
On 32bit systems, some old kernels trigger a hw bug resulting in
On 06/07/15 16:15, Martin Peres wrote:
On 06/07/15 16:13, Chris Wilson wrote:
On Mon, Jul 06, 2015 at 03:10:48PM +0300, Martin Peres wrote:
On 06/07/15 13:33, Chris Wilson wrote:
Move the query for the TIMESTAMP register from context init to the
screen, so that it is only queried once for
On 06/07/15 13:33, Chris Wilson wrote:
Since the workaround bo is used strictly as a write-only buffer, we need
only allocate one per screen and use the same one from all contexts.
(The caveat here is during extension initialisation, where we write into
and read back register values from the
https://bugs.freedesktop.org/show_bug.cgi?id=79706
Bug 79706 depends on bug 45348, which changed state.
Bug 45348 Summary: [swrast] piglit fbo-drawbuffers-arbfp regression
https://bugs.freedesktop.org/show_bug.cgi?id=45348
What|Removed |Added
On 06/07/15 13:33, Chris Wilson wrote:
With the exception of gen8, the sole user of the workaround bo are for
emitting pipe controls. Move it out of the purview of the batchbuffer
and into the pipecontrol.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Martin Peres
On 06/07/15 16:13, Chris Wilson wrote:
On Mon, Jul 06, 2015 at 03:10:48PM +0300, Martin Peres wrote:
On 06/07/15 13:33, Chris Wilson wrote:
Move the query for the TIMESTAMP register from context init to the
screen, so that it is only queried once for all contexts.
On 32bit systems, some old
On 04/07/15 07:15, Vinson Lee wrote:
On Fri, Jul 3, 2015 at 6:05 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
The expansion should always be to the same width as the input arguments
no matter what, since these functions should work with any bit width of
the
Just skipping to interesting comments for the moment.
On Mon, Jul 06, 2015 at 12:34:00PM -0700, Kenneth Graunke wrote:
While I really like this idea in principle, the current patch is rather
huge, making it difficult to review; bisectability would also suffer.
Would it be possible to split it
On Mon, Jul 06, 2015 at 11:18:00AM -0700, Kenneth Graunke wrote:
In the kernel, this is called __must_check; all our attribute macros in
Mesa appear to be uppercase, so I went with that.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: ch...@chris-wilson.co.uk
Cc: matts...@gmail.com
On Monday, July 06, 2015 11:33:20 AM Chris Wilson wrote:
The vertices require a large chunk of memory, currently allocated during
context creation. However, this memory is not required until use so we
can defer the allocation until the first swrast_Wakeup().
Signed-off-by: Chris Wilson
On Monday, July 06, 2015 12:18:18 PM Matt Turner wrote:
On Mon, Jul 6, 2015 at 9:55 AM, Kenneth Graunke kenn...@whitecape.org wrote:
It looks like this was forgotten in commit 3c9dc2d31b80fc73bffa1f40a
(i965: Make a brw_stage_prog_data for storing the SURF_INDEX
information.) In other
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
I think this only gets called for copy_region, which in turn probably
can't be reached by MS surfaces. Not sure, but this is definitely
right anyways.
On Mon, Jul 6, 2015 at 4:06 PM, Samuel Pitoiset
samuel.pitoi...@gmail.com wrote:
According to
On 07/06/2015 01:11 PM, Matt Turner wrote:
On Mon, Jul 6, 2015 at 3:33 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
The vertices require a large chunk of memory, currently allocated during
context creation. However, this memory is not required until use so we
can defer the allocation until
On Monday, July 06, 2015 09:27:12 PM Chris Wilson wrote:
On Mon, Jul 06, 2015 at 11:18:00AM -0700, Kenneth Graunke wrote:
In the kernel, this is called __must_check; all our attribute macros in
Mesa appear to be uppercase, so I went with that.
Signed-off-by: Kenneth Graunke
On Mon, Jul 06, 2015 at 04:29:49PM +0300, Martin Peres wrote:
On 06/07/15 13:33, Chris Wilson wrote:
Since the workaround bo is used strictly as a write-only buffer, we need
only allocate one per screen and use the same one from all contexts.
(The caveat here is during extension
That's right. Except really what might have happend was
occl query;
write X;
more drawing;
write X+1;
and then on the CPU, you see X+1. So the tests are always for = X.
And if you have more than 2^32 submits, you cry, because I'm *sure*
that nothing implements wraparound properly :)
On Mon, Jul
According to nv50, this should be src-ms_y instead of src-ms_x. This
code is here since 2012, so it's probably a typo error which has never
been detected since a long time. I didn't do a full piglit run to check
if it fixes some other weird issues.
Signed-off-by: Samuel Pitoiset
Am 06.07.2015 um 19:54 schrieb Ilia Mirkin:
That's right. Except really what might have happend was
occl query;
write X;
more drawing;
write X+1;
and then on the CPU, you see X+1. So the tests are always for = X.
And if you have more than 2^32 submits, you cry, because I'm *sure*
that
Before validating vertex arrays we need to check if a VBO is present.
Checking if vb-buffer is not NULL fixes the issue.
Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com
---
src/gallium/drivers/nouveau/nv50/nv50_vbo.c | 5 +
1 file changed, 5 insertions(+)
diff --git
On Fri, Jul 3, 2015 at 5:15 AM, Neil Roberts n...@linux.intel.com wrote:
On Gen9+ there is a new bit in 3DSTATE_PS_EXTRA that must be set if
the shader sends a message to the pixel interpolator. This fixes the
interpolateAt* tests on SKL, apart from interpolateatsample-nonconst
but that is not
Ilia, thanks a lot for the info.
So basically if I submit to GPU's command stream:
perform occlusion query,
write X to Y.
I know that query is completed when after reading Y address I get X.
Regards,
Vyacheslav
On Mon, Jul 6, 2015 at 9:13 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
I'm only
On Monday, July 06, 2015 05:12:10 PM Chris Wilson wrote:
On Mon, Jul 06, 2015 at 04:19:36PM +0300, Martin Peres wrote:
On 06/07/15 16:15, Martin Peres wrote:
On 06/07/15 16:13, Chris Wilson wrote:
On Mon, Jul 06, 2015 at 03:10:48PM +0300, Martin Peres wrote:
On 06/07/15 13:33, Chris
On Monday, July 06, 2015 11:33:11 AM Chris Wilson wrote:
Since we can distinguish when mapping between READ and WRITE, we can
pass along the map mode to avoid stalls and flushes where possible.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
On Monday, July 06, 2015 11:33:08 AM Chris Wilson wrote:
Since the workaround bo is used strictly as a write-only buffer, we need
only allocate one per screen and use the same one from all contexts.
(The caveat here is during extension initialisation, where we write into
and read back
This was probably disabled due to a combination of several bugs in the
generator code (fixed earlier in this series) and a misunderstanding
of the hardware spec. The documentation for most control flow
instructions mentions among other restrictions:
Instruction compression is not allowed.
This
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sat, Jul 4, 2015 at 2:40 PM, Neil Roberts n...@linux.intel.com wrote:
In this bit of code point_five can be NULL if the expression is not a
constant. This fixes it to match the pattern of the rest of the chunk
of code so that it checks for NULLs.
Cc: Matt Turner matts...@gmail.com
Cc:
The hardware docs don't mention explicitly what these fields should
be, but I've verified experimentally on ILK that using a GRF as
destination causes the register to be corrupted when the execution
size of an ENDIF instruction is higher than 8 -- and because the
destination we were using was g0,
From the hardware docs for the DO instruction:
Execution size is ignored for this instruction.
My observation on ILK hardware contradicts the spec though, channels
over the execution size of a DO instruction won't enter the loop, and
channels over the execution size of a WHILE instruction will
On Monday, July 06, 2015 04:24:12 PM Emil Velikov wrote:
Hello gents,
On 2 July 2015 at 08:45, Kenneth Graunke kenn...@whitecape.org wrote:
On Wednesday, July 01, 2015 10:16:28 AM Mike Stroyan wrote:
When there are no color buffer render targets, gen6 and gen7 still
use the first
On Mon, Jul 6, 2015 at 11:29 AM, Vyacheslav Gonakhchyan
ytri...@gmail.com wrote:
Hi, everyone.
Trying to understand method radeonQueryGetResult (more broadly GPU-CPU
sync).
static void radeonQueryGetResult(struct gl_context *ctx, struct
gl_query_object *q)
{
struct radeon_query_object
On Monday, July 06, 2015 11:33:07 AM Chris Wilson wrote:
With the exception of gen8, the sole user of the workaround bo are for
emitting pipe controls. Move it out of the purview of the batchbuffer
and into the pipecontrol.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by:
On Monday, July 06, 2015 11:33:10 AM Chris Wilson wrote:
Rather than allocating a fresh page every time we clear a buffer, keep
that page around between invocations by tracking the last used offset
and only allocating a fresh page when we wrap.
Signed-off-by: Chris Wilson
Ilia, thanks for the gallium link.
Do you know any links to high level info with broad strokes about how this
sync works? Frankly I do not know driver terminology and wanted to know
more about how this sync is performed for my research. I'm using mesa as a
reference because it has open
On Mon, Jul 06, 2015 at 04:19:36PM +0300, Martin Peres wrote:
On 06/07/15 16:15, Martin Peres wrote:
On 06/07/15 16:13, Chris Wilson wrote:
On Mon, Jul 06, 2015 at 03:10:48PM +0300, Martin Peres wrote:
On 06/07/15 13:33, Chris Wilson wrote:
Move the query for the TIMESTAMP register from
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #32 from Matt Whitlock freedesk...@mattwhitlock.name ---
(In reply to Matt Whitlock from comment #29)
Also, for what it's worth, this problem seems to have disappeared for me. I
have rebuilt Mesa 10.5.6 without the revert of
On Monday, July 06, 2015 11:33:12 AM Chris Wilson wrote:
No external users, so no need to export the symbol outside of our
compilation unit.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Good call.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
signature.asc
Description: This
It looks like this was forgotten in commit 3c9dc2d31b80fc73bffa1f40a
(i965: Make a brw_stage_prog_data for storing the SURF_INDEX
information.) In other words, it's been missing since we moved to
dynamic binding table slot assignments.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by:
I'm only really familiar with nouveau, but I think all GPU hardware
works in roughly the same way. Basically you have some way of
inserting write X to address Y into the command stream (aka a
fence), after which you insert write X+1 to address Y and so on.
If you want the CPU to wait on a given
On Mon, Jul 6, 2015 at 11:03 AM, Francisco Jerez curroje...@riseup.net wrote:
This was probably disabled due to a combination of several bugs in the
generator code (fixed earlier in this series) and a misunderstanding
of the hardware spec. The documentation for most control flow
instructions
On Monday, July 06, 2015 11:33:09 AM Chris Wilson wrote:
When submitting commands to the GPU every cycle of latency counts;
mutexes, spinlocks, even atomics quickly add to substantial overhead.
This batch manager acts as thread-local shim over the buffer manager
(drm_intel_bufmgr_gem). As we
On Mon, Jul 6, 2015 at 11:03 AM, Francisco Jerez curroje...@riseup.net wrote:
The hardware docs don't mention explicitly what these fields should
be, but I've verified experimentally on ILK that using a GRF as
destination causes the register to be corrupted when the execution
size of an ENDIF
https://bugs.freedesktop.org/show_bug.cgi?id=91226
Neil Roberts n...@linux.intel.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, Jul 6, 2015 at 11:18 AM, Kenneth Graunke kenn...@whitecape.org wrote:
In the kernel, this is called __must_check; all our attribute macros in
Mesa appear to be uppercase, so I went with that.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: ch...@chris-wilson.co.uk
Cc:
On Mon, Jul 6, 2015 at 3:33 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
The vertices require a large chunk of memory, currently allocated during
context creation. However, this memory is not required until use so we
can defer the allocation until the first swrast_Wakeup().
Makes sense to
On Monday, July 06, 2015 11:33:15 AM Chris Wilson wrote:
Since the purpose of transform feedback tends to be for the client to
act upon the results to change the geometry in the scene, it is likely
that the client will soon be waiting upon the results. Flush the batch
early so that we don't
On Mon, Jul 6, 2015 at 11:03 AM, Francisco Jerez curroje...@riseup.net wrote:
From the hardware docs for the DO instruction:
Execution size is ignored for this instruction.
My observation on ILK hardware contradicts the spec though, channels
/facepalm
over the execution size of a DO
In the kernel, this is called __must_check; all our attribute macros in
Mesa appear to be uppercase, so I went with that.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: ch...@chris-wilson.co.uk
Cc: matts...@gmail.com
---
configure.ac | 1 +
src/util/macros.h | 6 ++
2 files
On Monday, July 06, 2015 09:03:35 PM Francisco Jerez wrote:
The hardware docs don't mention explicitly what these fields should
be, but I've verified experimentally on ILK that using a GRF as
destination causes the register to be corrupted when the execution
size of an ENDIF instruction is
On Mon, Jul 6, 2015 at 9:55 AM, Kenneth Graunke kenn...@whitecape.org wrote:
It looks like this was forgotten in commit 3c9dc2d31b80fc73bffa1f40a
(i965: Make a brw_stage_prog_data for storing the SURF_INDEX
information.) In other words, it's been missing since we moved to
dynamic binding
+ } else
+ if (!vb-buffer) {
Should the else and if be on the same line?
The general style elsewhere is to do it in this weird way. Can't say
I'm a big fan, but I prefer consistency.
I'd happily take a change that undid that oddity.
Odd, okay.
signature.asc
On Mon, Jul 6, 2015 at 7:50 PM, Dylan Baker baker.dyla...@gmail.com wrote:
On Mon, Jul 06, 2015 at 11:34:23PM +0200, Samuel Pitoiset wrote:
Before validating vertex arrays we need to check if a VBO is present.
Checking if vb-buffer is not NULL fixes the issue.
Signed-off-by: Samuel Pitoiset
On Sun, Jul 5, 2015 at 4:45 PM, Francisco Jerez curroje...@riseup.net wrote:
Hi Matt,
Matt Turner matts...@gmail.com writes:
On Fri, Jul 3, 2015 at 3:46 AM, Francisco Jerez curroje...@riseup.net
wrote:
Heh, I happened to come across this comment yesterday while looking for
the remaining
On Mon, Jul 06, 2015 at 11:34:23PM +0200, Samuel Pitoiset wrote:
Before validating vertex arrays we need to check if a VBO is present.
Checking if vb-buffer is not NULL fixes the issue.
Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com
---
src/gallium/drivers/nouveau/nv50/nv50_vbo.c
On Mon, Jul 6, 2015 at 7:55 PM, Dylan Baker baker.dyla...@gmail.com wrote:
+ } else
+ if (!vb-buffer) {
Should the else and if be on the same line?
The general style elsewhere is to do it in this weird way. Can't say
I'm a big fan, but I prefer consistency.
I'd happily take
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
But please change the commit title to mention the actual effect, like
avoid segfault with enabled but unbound vertex attrib or something.
The piglit fix should be mentioned in the body of the message -- it's
a nice side-effect, but not really
https://bugs.freedesktop.org/show_bug.cgi?id=85203
--- Comment #17 from Michel Dänzer mic...@daenzer.net ---
http://lists.freedesktop.org/archives/dri-devel/2015-July/085663.html should
fix this.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=85203
Aaron B aaronbotte...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On 07.07.2015 01:32, Ilia Mirkin wrote:
On Mon, Jul 6, 2015 at 11:29 AM, Vyacheslav Gonakhchyan
ytri...@gmail.com wrote:
Hi, everyone.
Trying to understand method radeonQueryGetResult (more broadly GPU-CPU
sync).
static void radeonQueryGetResult(struct gl_context *ctx, struct
On 06.07.2015 20:41, Marek Olšák wrote:
I thought your patch does something else, but after re-reading it,
it seems to do the right thing.
Yeah, si_llvm_export_vs's param_count only counts parameter exports.
Reviewed-by: Marek Olšák marek.ol...@amd.com
Thanks.
On Mon, Jul 6, 2015 at 1:38
On Mon, Jul 6, 2015 at 12:36 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On Monday, July 06, 2015 11:33:15 AM Chris Wilson wrote:
Since the purpose of transform feedback tends to be for the client to
act upon the results to change the geometry in the scene, it is likely
that the client
Hi, everyone.
Trying to understand method radeonQueryGetResult (more broadly GPU-CPU
sync).
static void radeonQueryGetResult(struct gl_context *ctx, struct
gl_query_object *q)
{
struct radeon_query_object *query = (struct radeon_query_object *)q;
uint32_t *result;
int i;
On 06/07/15 13:33, Chris Wilson wrote:
No external users, so no need to export the symbol outside of our
compilation unit.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Martin Peres martin.pe...@linux.intel.com
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 36
1 - 100 of 105 matches
Mail list logo
