Hello,
I would like to ask what are the proposed projects for Gsoc 2017.
Specifically I want to know if someone proposed something to the Driconf
replacement idea.
Can anyone point me out?
Thanks in advance.
PS: I'm not elegible to the program, so please, don't reply saying that the
subscript
On Tue, 2017-04-04 at 19:21 -0700, Jason Ekstrand wrote:
> Before, we were just looking at whether or not the user wanted us to
> wait and waiting on the BO. This instead makes us busy-loop on each
> query until it's available. This reduces some of the pipeline
> bubbles
> we were getting and imp
Reviewed-by: Iago Toral Quiroga
On Tue, 2017-04-04 at 15:38 -0700, Jason Ekstrand wrote:
> We already provide a default LOD for textureQueryLevels and texture()
> on
> non-fragment stages. However, there are more cases where one is
> needed
> such as textureSize(gsampler2DMS*) in SPIR-V. Instea
On Tue, Apr 04, 2017 at 03:56:35PM -0700, Jason Ekstrand wrote:
> ---
> src/intel/Makefile.sources | 7 ++
> src/intel/isl/isl.c| 93
> src/intel/isl/isl.h| 82 ++
> src/intel/isl/isl_emit_depth_stencil.c | 189
>
On 05/04/17 16:41, gregory hainaut wrote:
On Wed, 5 Apr 2017 09:09:45 +1000
Timothy Arceri wrote:
On 05/04/17 02:29, Gregory Hainaut wrote:
Context:
Nouveau uses NULL strings for unnamed parameter of texture gather
offsets opcode.
Fix piglit crashes of the 'texturegatheroffsets' tests on N
On Tue, Apr 04, 2017 at 03:56:35PM -0700, Jason Ekstrand wrote:
> ---
> src/intel/Makefile.sources | 7 ++
> src/intel/isl/isl.c| 93
> src/intel/isl/isl.h| 82 ++
> src/intel/isl/isl_emit_depth_stencil.c | 189
>
On Tue, Apr 04, 2017 at 03:56:29PM -0700, Jason Ekstrand wrote:
> This little series adds support to ISL for emitting the packets required
> for depth and stencil buffers:
>
> - 3DSTATE_DEPTH_BUFFER
> - 3DSTATE_STENCIL_BUFFER
> - 3DSTATE_HIER_DEPTH_BUFFER
> - 3DSTATE_CLEAR_PARAMS
>
> The appr
Hi Jean,
On 04.04.2017 01:52, Jean Hertel wrote:
I would like to ask what are the proposed projects for Gsoc 2017.
Specifically I want to know if someone proposed something to the Driconf
replacement idea.
If you haven't already, try installing driconf and playing around with
it a bit. This s
On Tue, Apr 04, 2017 at 07:21:38PM -0700, Jason Ekstrand wrote:
> Before, we were just looking at whether or not the user wanted us to
> wait and waiting on the BO. This instead makes us busy-loop on each
> query until it's available. This reduces some of the pipeline bubbles
> we were getting an
On Tue, Apr 04, 2017 at 05:09:51PM -0700, Kenneth Graunke wrote:
> On modern systems with 4GB apertures, the size in bytes is 4294967296,
> or (1ull << 32). The kernel gives us the aperture size as a __u64,
> which works out great.
>
> Unfortunately, libdrm "helpfully" returns the data as a size_
On Tue, Apr 04, 2017 at 05:09:52PM -0700, Kenneth Graunke wrote:
> This does nothing on Gen4+, which is the only hardware we support.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-
On Tue, Apr 04, 2017 at 05:09:53PM -0700, Kenneth Graunke wrote:
> Using an incoherent CPU map on the active scanout buffer is really
> sketchy - we may need extra flushing via GEM_SW_FINISH, or using
> drmModeDirtyFB() and kernel commit a6a7cc4b7db6d (4.10+).
>
> Chris suggests "never ever do tha
On Tue, Apr 04, 2017 at 05:09:54PM -0700, Kenneth Graunke wrote:
> This imports commit 19c4cfc54918d361f2535aec16650e9f0be667cd of
> libdrm/intel/*.[ch], minus a few files that we're never going to use
> (and would immediately delete), plus a few necessary dependencies.
>
> We rename intel_bufmgr.
On Tue, Apr 04, 2017 at 05:09:55PM -0700, Kenneth Graunke wrote:
> We never imported any of this code, so drop the prototypes, unused
> enums, and defines.
>
> Based on patches by Emil Velikov.
Hah, I'd been wondering if you might instead revive the aub debugging
infrastructure for post-mortem de
On Tue, Apr 04, 2017 at 05:09:56PM -0700, Kenneth Graunke wrote:
> typeof doesn't seem to exist. This code is going to die soon anyway.
Hmm. Presumably libdrm_lists.h isn't compiled at this point in the
series? Just checking!
#ifndef typeof
#define typeof __typeof__
#endif
Slightly less invasiv
On Tue, Apr 04, 2017 at 05:09:57PM -0700, Kenneth Graunke wrote:
> i965 doesn't use drm_intel_get_aperture_sizes(), so we can delete
> support for it. This avoids a build dependency on libpciaccess.
\o/
There's a really old bug that hopefully has been closed already
(although as far as I can tel
Am 04.04.2017 um 18:40 schrieb Andy Furniss:
Well it's a tricky situation with cabac which would be a shame to loose.
Yeah, completely agree.
Currently I guess it's a bit strange advertising main/high - but then
others do without having mbaff support
As noted before mbaff isn't so much
On 04/04/17 19:49, Jordan Justen wrote:
On 2017-04-04 06:21:04, Lionel Landwerlin wrote:
On 04/04/17 00:22, Jordan Justen wrote:
From BDW PRM, Volume 6: Command Stream Programming, 'Render Command
Header Format'.
Signed-off-by: Jordan Justen
---
src/intel/common/gen_decoder.c | 12 ++
On Tue, Apr 04, 2017 at 05:10:00PM -0700, Kenneth Graunke wrote:
> Drop xf86atomic.h in favor of Mesa's util/u_atomic.h. We replace the
> atomic_t wrapper struct with a bare integer, switch to the 'p_atomic'
> naming conventions, and move over the one extra helper.
>
> Signed-off-by: Kenneth Grau
Reviewed-by: Lionel Landwerlin
On 04/04/17 23:38, Jason Ekstrand wrote:
We already provide a default LOD for textureQueryLevels and texture() on
non-fragment stages. However, there are more cases where one is needed
such as textureSize(gsampler2DMS*) in SPIR-V. Instead of trying to list
out a
https://bugs.freedesktop.org/show_bug.cgi?id=100569
--- Comment #1 from Nicolai Hähnle ---
Most likely caused by the recent change to make pipe_box smaller. Changing the
affected cast from (int) to (int16_t) should be sufficient to fix this.
--
You are receiving this mail because:
You are the Q
On 05.04.2017 05:56, Rhys Kidd wrote:
Signed-off-by: Rhys Kidd
Acked-by: Nicolai Hähnle
---
.travis.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index aa212b1..c0b2c1f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -114,7 +114,7 @@ script
On 05.04.2017 03:41, Timothy Arceri wrote:
This avoids validation and looking up the buffer for a second time.
s/buffer/buffer target/? The buffer itself isn't looked up. Apart from
this, the series is
Reviewed-by: Nicolai Hähnle
---
src/mesa/main/bufferobj.c | 32 --
On Tue, Apr 04, 2017 at 05:10:01PM -0700, Kenneth Graunke wrote:
> Both are kernel style lists, so this is trivial.
>
> Signed-off-by: Kenneth Graunke
> ---
> @@ -1928,10 +1928,10 @@ drm_bacon_bufmgr_gem_destroy(drm_bacon_bufmgr *bufmgr)
> &bufmgr_gem->cache_bucket[i];
>
On 05.04.2017 05:56, Timothy Arceri wrote:
In the following patch we will stop pre-processing shaders before
hashing them, so we just disable the cache if MESA_EXTENSION_OVERRIDE
is set.
Why can't you add the value of MESA_EXTENSION_OVERRIDE to the hash of
shaders?
Cheers,
Nicolai
Tested-
On 05.04.2017 05:56, Timothy Arceri wrote:
Due to a max limit of 65,536 entries on the index table that we use to
decide if we can skip compiling individual shaders, it is very likely
we will have collisions.
To avoid doing too much work when the linked program may be in the
cache this patch del
On Tue, Apr 04, 2017 at 05:10:02PM -0700, Kenneth Graunke wrote:
> Based on a patch by Kristian Høgsberg.
Even a token explanation "These functions are unused, remove them from
the build. More to come later after refactoring!" ?
Seems small!
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, In
On Tue, Apr 04, 2017 at 05:10:04PM -0700, Kenneth Graunke wrote:
> execbuf2 has been around for years.
since v2.6.33, comformtably older than the current minimum supported
kernel version.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Hello All,
Could someone please send a link to a comprehensive document on
enabling the various DEBUG levels within mesa, I've already tried :
https://www.mesa3d.org/debugging.html , however this just mentions MESA_DEBUG
(which only dumps errors) , is there any option which can give me
On Tue, Apr 04, 2017 at 05:10:03PM -0700, Kenneth Graunke wrote:
> Based on a patch by Kristian Høgsberg.
I'd prefer if this was "Remove gen2/3 fence accounting"
Since gen4, we do not use fence registers for any GPU access and so
never have to account for the fence during batch construction. All
On 01.04.2017 11:42, Gregory Hainaut wrote:
In gl core, buffer must be reserved first by CreateBuffers/GenBuffers
to be valid.
Signed-off-by: Gregory Hainaut
---
src/mesa/main/marshal.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/sr
On Tue, Apr 04, 2017 at 05:10:05PM -0700, Kenneth Graunke wrote:
> ROUND_UP_TO handles a NPOT alignment, but all the alignments we use
> are power of two anyway, so there's no need.
Slightly better than the kernel's roundup and round_up!
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel
On Tue, Apr 04, 2017 at 05:10:06PM -0700, Kenneth Graunke wrote:
Replace the duplicated macros imported from libdrm:
ARRAY_SIZE, MAX2, ALIGN
and remove the unused one. Hmm, I think the remove should perhaps be the
previous patch where it's last user was removed.
Reviewed-by: Chris Wilson
On 01.04.2017 11:42, Gregory Hainaut wrote:
Improve speed on PCSX2
v2:
Add ppbo/ubpo status in XML file
Disable variable parameter (as the pointer would be a fixed offset)
v3:
split buffer tracking into separate patches.
use 'goto fallback_to_sync' when asynchronous transfer isn't supported
Si
On Tue, Apr 04, 2017 at 05:10:07PM -0700, Kenneth Graunke wrote:
> Eliminates some API around this, and more importantly, the last
> field in one bufmgr class.
Nice. Some quirms that it is using DEBUG_BUFMGR for batch tracking
rather than buffer handling, but
Reviewed-by: Chris Wilson
-Chris
--
On Tue, Apr 04, 2017 at 05:10:08PM -0700, Kenneth Graunke wrote:
> libdrm_bacon used to have a GEM-based bufmgr and a legacy fake bufmgr,
> but that's long since dead (and we never imported it to i965). So,
> drop the extra layer of function pointers.
\o/ (Cheating though! By importing the old cr
On Tue, Apr 04, 2017 at 05:10:09PM -0700, Kenneth Graunke wrote:
> Legacy DRI1 leftovers.
Do you want to convert intel_batch.c to only using one exec function,
then remove all the others in one fell swoop?
Nevertheless,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Techno
On Tue, Apr 04, 2017 at 05:10:10PM -0700, Kenneth Graunke wrote:
> This moves us one step closer to killing off intel_bufmgr_priv.h.
And please hint you will be killing drm_bacon_context!
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
On Tue, Apr 04, 2017 at 05:10:11PM -0700, Kenneth Graunke wrote:
The distinction was required when the bufmgr was virtualised, now there
is only one class, we no longer need the distraction of pretending it is
a subclass.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Tech
On 01.04.2017 11:42, Gregory Hainaut wrote:
Hello,
Please find a new version to handle invalid buffer handles.
Allow to handle this kind of case:
genBuffer(&pbo);
DeleteBuffer(pbo);
BindBuffer(pbo)
TexSubImage2D(user_memory_pointer); // Data transfer will be synchronous
There are v
On Tue, Apr 04, 2017 at 05:10:12PM -0700, Kenneth Graunke wrote:
> This query has been available since 2.6.28. We require 3.6.
Sure, get-aperture is still misleading though ;)
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Hello,
I would like to ask what are the proposed projects for Gsoc 2017.
Specifically I want to know if someone proposed something to the Driconf
replacement idea.
Can anyone point me out?
Thanks in advance.
PS: I'm not elegible to the program, so please, don't reply saying that the
subscript
On Tue, Apr 04, 2017 at 05:10:13PM -0700, Kenneth Graunke wrote:
> We require Kernel 3.6 and fail screen creation if this doesn't exist.
The wait-ioctl was introduced in kernel v3.6 (20120930) and that is our
current minimum requirement for screen creation.
Reviewed-by: Chris Wilson
-Chris
--
On Tue, Apr 04, 2017 at 05:10:14PM -0700, Kenneth Graunke wrote:
> This field was the wrong size, so we replaced it with offset64.
Reviewed-by: Chris Wilson
> ---
> src/mesa/drivers/dri/i965/brw_bufmgr.h | 6 --
> src/mesa/drivers/dri/i965/intel_bufmgr_gem.c | 3 ---
> src/mesa/drivers
# Classify fixed and variable parameters.
self.fixed_params = []
self.variable_params = []
for p in self.parameters:
if p.is_padding:
continue
-if p.is_variable_length():
+if se
On Tue, Apr 04, 2017 at 05:10:15PM -0700, Kenneth Graunke wrote:
> This moves the PCI ID detection to intel_screen.c and makes
> drm_bacon_bufmgr_gem_init() take a devinfo pointer.
>
> We also drop the HAS_LLC query stuff - devinfo has that info already,
> without kernel queries, and it makes no s
On Tue, Apr 04, 2017 at 05:10:16PM -0700, Kenneth Graunke wrote:
> This is basically handholding to prevent a bogus caller from trying to
> execbuffer on a bogus engine. i965 already does this correctly.
Too true.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology C
Christian König wrote:
Am 04.04.2017 um 18:40 schrieb Andy Furniss:
Well it's a tricky situation with cabac which would be a shame to loose.
Yeah, completely agree.
Currently I guess it's a bit strange advertising main/high - but then
others do without having mbaff support
As noted be
On Tue, Apr 04, 2017 at 05:10:17PM -0700, Kenneth Graunke wrote:
> We'll probably want this someday, but let's simplify now and add it back
> when we actually intend to use it.
You do, but not in this form. Other than AMD_pinned_memory, zero-copy
TexImage (and esp reads) are a lot faster using the
On Tue, Apr 04, 2017 at 05:10:18PM -0700, Kenneth Graunke wrote:
> We may want this eventually, but simplify for now. We can add it back
> later when we actually intend to use it.
Yup, this is not how to do relocations, so rip out the chaff and build
it back up correctly.
Reviewed-by: Chris Wils
On Tue, Apr 04, 2017 at 05:10:20PM -0700, Kenneth Graunke wrote:
> It's always zero now.
Reviewed-by: Kenneth Graunke
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.fr
On Tue, Apr 04, 2017 at 05:10:19PM -0700, Kenneth Graunke wrote:
> Mesa doesn't use this yet. We'll almost certainly want to, but we can
> add the functionality back after we clean up the messy drm code.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
On Tue, Apr 04, 2017 at 05:10:21PM -0700, Kenneth Graunke wrote:
> No performance data has been gathered about this choice. I just don't
> want that many hash tables.
Yup. This is not performance critical either, you simply should not be
recreating that many handles from scratch - scalablity is f
> Still, I believe there is the following bug in the series:
> glGenBuffers(1, &pbo);
> glBindBuffer(..., pbo);
> glDeleteBuffers(1, &pbo);
> glTexSubImage2D(...); // will be asynchronous, but refers to user memory
> because the pbo was implicitly unbound
I unbound the buffer when it is deleted
On Tue, Apr 04, 2017 at 05:10:22PM -0700, Kenneth Graunke wrote:
> This used to have another field, but now it's just a BO pointer.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev
On Tue, Apr 04, 2017 at 05:10:23PM -0700, Kenneth Graunke wrote:
> This functionality was added by libdrm commit
> 743af59669386cb6e063fa4bd85f0a0b2da86295 (intel: make bufmgr_gem
> shareable from different API) in an attempt to solve libva/mesa buffer
> sharing problems. Specifically, this was wo
Add missing GFX9 files in the EXTRA_DIST.
---
src/amd/Makefile.sources | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/Makefile.sources b/src/amd/Makefile.sources
index 46da0fb..816e7e4 100644
--- a/src/amd/Makefile.sources
+++ b/src/amd/Makefile.sources
@@ -21,12 +21,14 @@ ADDRLIB_F
`codegen/gen_common.py` is missed in EXTRA_DIST.
---
src/gallium/drivers/swr/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/swr/Makefile.am
b/src/gallium/drivers/swr/Makefile.am
index 515a908..5309311 100644
--- a/src/gallium/drivers/swr/Makefile.am
+++ b/src/
Several files are missed in their proper EXTRA_DIST Makefile.am. And thus `make
distcheck` fails.
These commits fix it.
I've split them in 3 because the missing files are in different sections. But I
can squash them in just one commit if preferred.
Juan A. Suarez Romero (3):
amd: fix distchec
On Tue, Apr 04, 2017 at 05:10:24PM -0700, Kenneth Graunke wrote:
> This is only useful when doing an incoherent CPU mapping of the current
> scanout buffer. That's a terrible plan, so we never do it. We always
> use an uncached GTT map.
(Or WC mmap ;)
> So, this is useless. Drop the code.
Re
`genxml/gen_bits_header.py` is missed in EXTRA_DIST.
---
src/intel/Makefile.genxml.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
index e34536d..d379df0 100644
--- a/src/intel/Makefile.genxml.am
+++ b/src/intel/Makefile.genxml.am
On Tue, Apr 04, 2017 at 05:10:25PM -0700, Kenneth Graunke wrote:
> This renames intel_batchbuffer_reloc to brw_emit_reloc and changes the
> parameter naming and ordering to match drm_intel_bo_emit_reloc().
>
> For now, it's a trivial wrapper that accesses batch->bo. When we
> rework relocations,
42aaa548 changed the renderbuffer initialisation of RefCount from
1 to 0.
This is inconsitent with how we use RefCount elsewhere. Also every
driver implementation of NewRenderbuffer() calls
_mesa_init_renderbuffer() so its safe to set it there.
---
src/mesa/drivers/common/meta.c | 2 --
src/mesa/
On Tue, Apr 04, 2017 at 05:10:26PM -0700, Kenneth Graunke wrote:
> I'm about to make brw_emit_reloc do actual work, so everybody needs
> to start using it and not the raw drm_bacon function.
Too much u32. Are those limitations part of future plans? Certainly
needs a comment about why the bugs are
On Tue, Apr 04, 2017 at 05:10:27PM -0700, Kenneth Graunke wrote:
> We'll want to change the implementation of this shortly.
Is batch_references the interface you want though? You are actually
either asking whether the buffer is busy (being under construction is
part of that) or to flush the bo.
A
On Tue, Apr 04, 2017 at 05:10:28PM -0700, Kenneth Graunke wrote:
> This is the threshold after which drm_intel_bufmgr_check_aperture_space
> returns -ENOSPC, signalling that it thinks an execbuf is likely to fail
> and we need to roll back and flush the batch.
>
> We'll need this when we rewrite a
This series is :
Acked-by: Lionel Landwerlin
On 05/04/17 12:00, Juan A. Suarez Romero wrote:
Several files are missed in their proper EXTRA_DIST Makefile.am. And thus `make
distcheck` fails.
These commits fix it.
I've split them in 3 because the missing files are in different sections. But I
On Tue, Apr 04, 2017 at 05:10:29PM -0700, Kenneth Graunke wrote:
> I'm about to rewrite how relocation handling works, at which point
> drm_bacon_bo_emit_reloc() and drm_bacon_bo_mrb_exec() won't exist
> anymore. This code is already largely not using the batchbuffer
> infrastructure, so just go a
Hi,
On 05.04.2017 11:27, Chris Wilson wrote:
On Tue, Apr 04, 2017 at 07:21:38PM -0700, Jason Ekstrand wrote:
Before, we were just looking at whether or not the user wanted us to
wait and waiting on the BO. This instead makes us busy-loop on each
query until it's available. This reduces some o
On Tue, Apr 04, 2017 at 05:10:30PM -0700, Kenneth Graunke wrote:
> The execbuf2 kernel API requires us to construct two kinds of lists.
> First is a "validation list" (struct drm_i915_gem_exec_object2[])
> containing each BO referenced by the batch. (The batch buffer itself
> must be the last entr
On Tue, Apr 04, 2017 at 05:10:31PM -0700, Kenneth Graunke wrote:
> These fields are the same value. In the bad old days, bo->handle could
> have been an identifier from the pre-GEM fake bufmgr, but that's long
> gone. Keep the "gem_handle" name for clarity.
Earlier? Is there a reason why the drm
On Tue, Apr 04, 2017 at 05:10:32PM -0700, Kenneth Graunke wrote:
> The separate class gives us a bit of extra encapsulation, but I don't
> know that it's really worth the boilerplate. I think we can reasonably
> expect the rest of the driver to be responsible.
Reviewed-by: Chris Wilson
I would
On Tue, Apr 04, 2017 at 05:10:33PM -0700, Kenneth Graunke wrote:
> The only difference is that it takes an explicit bufmgr rather than
> using bo->bufmgr, but there is only one bufmgr per screen so they
> should be identical anyway.
It was purely due to the inconvenience of casting.
Reviewed-by: C
On Tue, Apr 04, 2017 at 05:10:34PM -0700, Kenneth Graunke wrote:
> Mesa style is to not use lengthy prefixes for static functions.
All the types are wrong. :( Please fix this inherited mess.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
On Tue, Apr 04, 2017 at 05:10:35PM -0700, Kenneth Graunke wrote:
> No need for a prefix as this struct is local to the .c file.
>
> Less bacon.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing
On Tue, Apr 04, 2017 at 05:10:36PM -0700, Kenneth Graunke wrote:
Even a small justification?
I would have kept the bare ioctl wrapper
static int get_reset_stats(int fd, struct *stats)
{
int err;
err = 0;
if (drmIoctl(fd, DRM_IOCTL_
On Tue, Apr 04, 2017 at 05:10:37PM -0700, Kenneth Graunke wrote:
> drm_bacon_context is a malloc'd struct containing a uint32_t context ID
> and a pointer back to the bufmgr. The bufmgr pointer is pretty useless,
> as everybody already has brw->bufmgr. At that point...we may as well
> just use th
On Tue, Apr 04, 2017 at 05:10:39PM -0700, Kenneth Graunke wrote:
> Less bacon.
brw_reg_read() now doesn't need to be part of the bufmgr.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.or
On Tue, Apr 04, 2017 at 05:10:40PM -0700, Kenneth Graunke wrote:
> The stupid reason for eliminating these functions is that I'm about
> to rename drm_bacon_bo_map() to brw_bo_map(), which makes the real
> function have the short name, rather than the wrapper.
>
> I'm also planning on reworking ou
On Tue, Apr 04, 2017 at 05:09:50PM -0700, Kenneth Graunke wrote:
> I apologize that it may be difficult to review: most people aren't
> familiar with this code (I learned a lot myself), and it's kind of
> huge. I tried.
One thing I will mention is that I put a lot of effort into trying to
explain
From: Emil Velikov
Honour the LIBUNWIND_CFLAGS and include the header only where needed.
Cc: Rob Clark
Fixes: 70c272004f72 ("gallium/util: libunwind support")
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/Makefile.am | 1 +
src/gallium/auxiliary/util/u_debug_stack.c | 3 +++
Hi,
On 04.04.2017 14:10, Luke Kenneth Casson Leighton wrote:
On Tue, Apr 4, 2017 at 11:04 AM, Eero Tamminen
wrote:
anyway, apologies: nobody whose applications are affected by this
really has a clue where the *actual* bug is so i am escalating it down
the chain of library dependencies, making
https://bugs.freedesktop.org/show_bug.cgi?id=100580
Bug ID: 100580
Summary: Adding control flow unreachable at runtime in a GLSL
shader leads to completely different image
Product: Mesa
Version: git
Hardware: Other
https://bugs.freedesktop.org/show_bug.cgi?id=100580
Hugues Evrard changed:
What|Removed |Added
URL||https://github.com/mc-imper
https://bugs.freedesktop.org/show_bug.cgi?id=100580
Hugues Evrard changed:
What|Removed |Added
Summary|Adding control flow |Adding unreachable "return"
Hi,
On 05.04.2017 13:11, J Karanje, Kedar wrote:
Could someone please send a link to a comprehensive document
on enabling the various DEBUG levels within mesa, I’ve already tried :
https://www.mesa3d.org/debugging.html , however this just mentions
MESA_DEBUG (which only dumps errors) ,
On Wed, Apr 5, 2017 at 8:25 AM, Emil Velikov wrote:
> From: Emil Velikov
>
> Honour the LIBUNWIND_CFLAGS and include the header only where needed.
Please drop the part other than the Makefile.am hunk..
I'm about to need libunwind.h included in the header file.
BR,
-R
> Cc: Rob Clark
> Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=100580
Hugues Evrard changed:
What|Removed |Added
URL|https://github.com/mc-imper |https://github.com/mc-imper
https://bugs.freedesktop.org/show_bug.cgi?id=100580
--- Comment #2 from Hugues Evrard ---
See: https://github.com/mc-imperial/shader-compiler-bugs/issues/70
Steps to Reproduce:
---
0. Note: this bug is experienced on an AMD GPU (tested on Tonga, see
below for more
https://bugs.freedesktop.org/show_bug.cgi?id=100580
Hugues Evrard changed:
What|Removed |Added
CC||h.evr...@imperial.ac.uk
--
You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=100580
--- Comment #3 from Hugues Evrard ---
Created attachment 130691
--> https://bugs.freedesktop.org/attachment.cgi?id=130691&action=edit
Archive with files to reproduce
--
You are receiving this mail because:
You are the assignee for the bug.
Y
Hello,
I would like to ask what are the proposed projects for Gsoc 2017.
Specifically I want to know if someone proposed something to the Driconf
replacement idea.
Can anyone point me out?
Thanks in advance.
PS: I'm not elegible to the program, so please, don't reply saying that the
subscript
Cc: 13.0 17.0
Signed-off-by: Alex Deucher
---
include/pci_ids/radeonsi_pci_ids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/pci_ids/radeonsi_pci_ids.h
b/include/pci_ids/radeonsi_pci_ids.h
index f4139ea..1058682 100644
--- a/include/pci_ids/radeonsi_pci_ids.h
+++ b/include/pci_i
Am 05.04.2017 um 15:46 schrieb Alex Deucher:
Cc: 13.0 17.0
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
---
include/pci_ids/radeonsi_pci_ids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/pci_ids/radeonsi_pci_ids.h
b/include/pci_ids/radeonsi_pci_ids.h
index f
On 5 April 2017 at 12:00, Juan A. Suarez Romero wrote:
> Several files are missed in their proper EXTRA_DIST Makefile.am. And thus
> `make
> distcheck` fails.
>
> These commits fix it.
>
> I've split them in 3 because the missing files are in different sections. But
> I
> can squash them in just
Hello,
This is the second proposal for a rewrite of mesa website.
The last proposal have some problems (still available here:
http://mesa.jeanhertel.com.br/):
* Use of big libraries like Twitter Bootstrap for the CSS;
* The design was focusing more on a blog-style instead of a documen
From: Emil Velikov
Introduce a stub to anv_gem_stub.c that matches the anv_gem.c one.
Otherwise we may get link-time errors, when building the tests.
Cc: Jason Ekstrand
Cc: Vinson Lee
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100574
Signed-off-by: Emil Velikov
---
src/intel/vulk
On Wed, 2017-04-05 at 14:51 +0100, Emil Velikov wrote:
> On 5 April 2017 at 12:00, Juan A. Suarez Romero wrote:
> > Several files are missed in their proper EXTRA_DIST Makefile.am. And thus
> > `make
> > distcheck` fails.
> >
> > These commits fix it.
> >
> > I've split them in 3 because the mi
On 5 April 2017 at 12:36, Jean Hertel wrote:
> Hello,
>
>
> This is the second proposal for a rewrite of mesa website.
>
>
> The last proposal have some problems (still available here:
> http://mesa.jeanhertel.com.br/):
>
> Use of big libraries like Twitter Bootstrap for the CSS;
> The design was
https://bugs.freedesktop.org/show_bug.cgi?id=100569
Aaron Watry changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
1 - 100 of 199 matches
Mail list logo
