On 14/03/17 03:27 PM, Matt Turner wrote:
> On Mon, Mar 13, 2017 at 11:11 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 14/03/17 03:13 AM, Matt Turner wrote:
>>> On Mon, Mar 13, 2017 at 2:04 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>>>>
On 14/03/17 03:13 AM, Matt Turner wrote:
> On Mon, Mar 13, 2017 at 2:04 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 03/03/17 11:53 AM, Michel Dänzer wrote:
>>> On 03/03/17 03:38 AM, Matt Turner wrote:
>>>
>>>> Putting mesa-announce@ in Bcc
On 03/03/17 11:53 AM, Michel Dänzer wrote:
> On 03/03/17 03:38 AM, Matt Turner wrote:
>> On Wed, Mar 1, 2017 at 7:44 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>>> P.S. It would be better to put the mesa-announce list only in Bcc on
>>> this kind of e-mails
lib/gallium/r300_dri.so
> ee2e5c4dc84001e99f54a6ddb8a5ee88 lib/gallium/swrast_dri.so
> ee2e5c4dc84001e99f54a6ddb8a5ee88 lib/gallium/virtio_gpu_dri.so
> ee2e5c4dc84001e99f54a6ddb8a5ee88 lib/gallium/vmwgfx_dri.so
>
> they're identical. I don't recall any of the proposed "mega dri
he mesa-dev discussion explaining these particular reverts)
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
pport is sufficiently terrible that
> softfloat may end up being a better plan. Also, I wouldn't be surprised
> if, at some point in the future, some hardware engineer decides they can
> save a bunch of power on low-power parts if they delete the fp64
> hardware. Since we ship desktop GL on
ting .dir-locals.el files in the
tree. If any of those files match the Linux kernel coding style as well,
it would be good to make them all consistent one way or another.
Please add a corresponding .editorconfig file as well.
--
Earthling Michel Dänzer | http://w
On 06/03/17 01:03 PM, Timothy Arceri wrote:
> From: Marek Olšák <marek.ol...@amd.com>
Both patches are
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
: Test 'eviction after overflow with MAX_SIZE=1M' failed: Expected=2,
Actual=1
FAIL glsl/tests/cache-test (exit status: 1)
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X dev
ons or suggestions - be that about the current patch
> queue or otherwise, please go ahead.
Consider backporting 0f53404565b9ef9da9d7022b5732463acd496742 for
https://bugs.freedesktop.org/100028 .
P.S. It would be better to put the mesa-announce list only in Bcc on
this kind of e-mails, to prev
le symbol definitions] and non-obvious - I
> had to do a double-take how things work atm.
>
> So follow the libradeon.la approach and put common libraries in
> TARGET_RADEON_COMMON
>
> Fixes: 936f5407a7d ("gallium/radeon: Add libamd_common.a to TARGET_LIB_DEPS
> also for r60
ures elsewhere due to multiple definitions of
libamd_common.a symbols.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-d
From: Michel Dänzer <michel.daen...@amd.com>
Fixes build failure with --enable-opencl --enable-xvmc:
make[4]: Entering directory
'/home/daenzer/src/mesa-git/mesa/build-amd64/src/gallium/targets/xvmc'
CXXLDlibXvMCgallium.la
../../../../src/gallium/drivers/r600/.libs/l
On 27/02/17 09:20 PM, Marek Olšák wrote:
> On Mon, Feb 27, 2017 at 10:57 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 25/02/17 01:56 PM, Timothy Arceri wrote:
>>> On 24/02/17 21:02, Marek Olšák wrote:
>>>> On Fri, Feb 24, 2017 at 3:18 AM, Timothy Arcer
ollision?
>>>>
>>>>
>>>> You should stop playing your game which will be rendering incorrectly
>>>> and by a lotto ticket.
>>>>
>>>>> Shouldn't we store the whole key as well?
>>>>
>>>>
>>>> Sure I
ng LLVM statically though.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing
skip loading from cache.
UE4 Elemental Demo and Unigine Valley run smoothly for the first time
(at least from the second time ;)! \o/
No piglit regressions. This patch is
Tested-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | htt
i < prog->NumShaders; i++) {
>_mesa_glsl_compile_shader(ctx, prog->Shaders[i], false, false, true);
> }
>
This fixes the piglit crashes I was getting with
MESA_GLSL_CACHE_ENABLE=1. The series is
Tested-by: Michel Dänzer <michel.daen..
On 23/02/17 03:44 PM, Michel Dänzer wrote:
> On 22/02/17 06:05 AM, Marek Olšák wrote:
>> From: Marek Olšák <marek.ol...@amd.com>
>>
>> This fixes:
>> vdpauinfo: ../lib/CodeGen/TargetPassConfig.cpp:579: virtual void
>> llvm::TargetPassConfig::ad
_import_context@make current, single process
so this appears unsafe for apps which call fork().
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
On 22/02/17 07:58 PM, Nicolai Hähnle wrote:
> On 22.02.2017 07:23, Michel Dänzer wrote:
>> On 22/02/17 12:45 PM, Timothy Arceri wrote:
>>>
>>> +get_disk_shader_cache
>>> +^
>>> +
>>> +Returns a pointer to driver-specif
ct pipe_screen *screen);
> };
Drivers which don't support an on-disk shader cache don't set this
callback in the first place, right? :) (Just a suggestion for
improvement before landing this patch, not a blocker, no need to resend)
--
Earthling Michel Dänzer |
On 20/02/17 07:15 PM, Edward O'Callaghan wrote:
> The name has become a little misleading now that it applies
> to both r600g and radeonsi.
>
> V.2: Michel Dänzer - R600_DEBUG must continue to work.
>
> Signed-off-by: Edward O'Callaghan <funfunc...@folklore1984.net>
hader_cache(pipe->screen);
You probably want to guard this by
if (pipe->screen->get_disk_shader_cache)
otherwise you'd need to make sure that every driver sets
pipe_screen::get_disk_shader_cache.
Speaking of which, you probably need to add a get_disk_shader_cache
implementation to all the wrapp
On 20/02/17 05:42 PM, Edward O'Callaghan wrote:
> The name has become a little misleading now that it applies
> to both r600g and radeonsi.
R600_DEBUG must continue to work.
Making RADEON_DEBUG work as well may be a good idea though.
--
Earthling Michel
On 17/02/17 06:01 PM, Eero Tamminen wrote:
> Hi,
>
> On 10.02.2017 02:59, Michel Dänzer wrote:
>> On 09/02/17 10:50 PM, Emil Velikov wrote:
>>> On 9 February 2017 at 08:07, Michel Dänzer <mic...@daenzer.net> wrote:
>>>> From: Michel Dänzer <michel.dae
On 14/02/17 11:09 PM, Marek Olšák wrote:
> On Tue, Feb 14, 2017 at 3:05 PM, Emil Velikov <emil.l.veli...@gmail.com>
> wrote:
>> On 13 February 2017 at 03:24, Michel Dänzer <mic...@daenzer.net> wrote:
>>> On 10/02/17 08:27 PM, Marek Olšák wrote:
>>>> O
ppy with that, I'm not
holding it up.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
ht
bug which caused incorrect machine
code to be generated.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
n.
>>>>>>>>
>>>>>>> s/force_glsl_compat_version/do_not_cap_glsl_compat_version/
>>>>>>
>>>>>>
>>>>>>
>>>>>> I would prefer force_glsl_compat_version.
>>>>>
tithread_makecurrent,
or at least get a significant benefit from it?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@
On 13/02/17 05:17 PM, Michel Dänzer wrote:
> On 11/02/17 08:01 AM, Grazvydas Ignotas wrote:
>> They cause regressions on little endian.
>>
>> Fixes: 172bfdaa9e ("r300g: add support for PIPE_FORMAT_x8R8G8B8_*")
>> Bugzilla: https://bugs.freedesktop.or
ported regression:
> + * https://bugs.freedesktop.org/show_bug.cgi?id=98869 */
> +if (PIPE_ENDIAN_NATIVE != PIPE_ENDIAN_BIG)
> +return format;
Is there any reason to believe that whatever issue this avoids couldn't
happen on big endian hosts as well?
--
Earthling
y for online multiplayer.
OTOH the game itself has now been fixed to no longer run into the
problem, and I suspect most users will probably get the game update
before any future Mesa stable release.
--
Earthling Michel Dänzer | http://www.amd.com
Libre so
On 09/02/17 10:50 PM, Emil Velikov wrote:
> On 9 February 2017 at 08:07, Michel Dänzer <mic...@daenzer.net> wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> Drop all -m*, -W*, -O*, -g* and -f* flags, with the exception of
>> -fno-rtti, which must
From: Michel Dänzer <michel.daen...@amd.com>
Drop all -m*, -W*, -O*, -g* and -f* flags, with the exception of
-fno-rtti, which must be used if it's part of the llvm-config --cxxflags
output. We don't want LLVM to dictate the flags we use, and it can even
cause build failures, e.g. i
er, but the generated code can be very
different depending on whether the change in question is present or not.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
On 06/02/17 03:48 PM, Yu, Qiang wrote:
>
> Dose this mean if the amdgpu_dri.so is compatible with GBM DRI backend,
> it will also compatible with libGL.so and xserver libglx.so (do these use
> same loader/DRI-ABI as GBM DRI backend)?
Yes, they do.
--
Earthling M
on level via the drirc mechanism.
> Also not sure if the ABI is stable for different mesa versions?
Yes, it's backwards compatible, i.e. older driver binaries can work with
newer loader versions.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software en
even all downstreams ship a single package with all libdrm*
headers is irrelevant. That package also contains all the libdrm_*.pc
files, so Vinson's patch works as intended either way.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthu
From: Michel Dänzer <michel.daen...@amd.com>
vram_size is supposed to be the total amount of VRAM that can be used by
userspace, which corresponds to the TTM VRAM manager size (which is
normally the full amount of VRAM, but can be just the visible VRAM when
DMA can't be used for BO mig
From: Michel Dänzer <michel.daen...@amd.com>
The kernel driver reports correct values now.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/ga
hes to
handle possible future larger values correctly.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesk
y see you and Mark CCd. I see now that there are capitals in there
> addresses as used by you - I got their addresses from other mails to
> me/list which were not capitalised - bah.
FWIW, case doesn't matter in e-mail addresses.
--
Earthling Michel Dänzer | http://www.a
On 25/01/17 07:34 PM, Yu, Qiang wrote:
>> From: Michel Dänzer <mic...@daenzer.net>
>> On 24/01/17 12:36 PM, Qiang Yu wrote:
>>> Third-party can put their backend to a directory configured with
>>> '--with-gbm-backenddir' and create a /etc/gbm.conf.d/*.conf fi
On 26/01/17 08:07 PM, Christian König wrote:
> Am 26.01.2017 um 12:01 schrieb Samuel Pitoiset:
>> On 01/26/2017 03:45 AM, Michel Dänzer wrote:
>>> On 25/01/17 11:19 PM, Samuel Pitoiset wrote:
>>>
>>>> I would like to approach the problem by reducing the amou
From: Michel Dänzer <michel.daen...@amd.com>
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
Not sure if PropagateAttrs should be set to true or false. Setting it to
true because clang SVN r293097 does so for CUDA, and there are no piglit
quick_cl regressions with radeon
On 25/01/17 11:19 PM, Samuel Pitoiset wrote:
> On 01/25/2017 03:56 AM, Michel Dänzer wrote:
>> On 25/01/17 12:05 AM, Marek Olšák wrote:
>>> On Tue, Jan 24, 2017 at 2:17 PM, Christian König
>>> <deathsim...@vodafone.de> wrote:
>>>> Am 24.01.2017 um 11:44
yone okay with that? I'm a
little worried it might cause problems, but I can't come up with a
specific scenario now, and maybe it can be addressed if and when it
causes a problem in practice.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
On 24/01/17 07:38 PM, Nicolai Hähnle wrote:
> On 24.01.2017 11:34, Samuel Pitoiset wrote:
>> On 01/24/2017 11:31 AM, Nicolai Hähnle wrote:
>>> On 24.01.2017 11:25, Samuel Pitoiset wrote:
>>>> On 01/24/2017 07:39 AM, Michel Dänzer wrote:
>>>>>
uel Pitoiset wrote:
>>>>> On 01/24/2017 11:31 AM, Nicolai Hähnle wrote:
>>>>>> On 24.01.2017 11:25, Samuel Pitoiset wrote:
>>>>>>> On 01/24/2017 07:39 AM, Michel Dänzer wrote:
>>>>>>>> On 24/
On 24/01/17 07:18 PM, Nicolai Hähnle wrote:
> On 24.01.2017 07:39, Michel Dänzer wrote:
>> On 24/01/17 05:44 AM, Samuel Pitoiset wrote:
>>> Useful when debugging applications which map too much VRAM.
>>
>> Is the number of mapped buffers really useful, as opposed
GTT, does it? Also, even the
total size of mappings of BOs currently in VRAM doesn't directly reflect
the pressure on the CPU visible part of VRAM — only the BOs which are
actively being accessed by the CPU contribute to that.
--
Earthling Michel Dänzer | http://www.amd.
ts, so if the VDPAU format doesn't
match the window visual, PresentPixmap will "work" but the result will
have incorrect colours.
Other than that, looks good to me.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On 19/01/17 02:23 AM, Nayan Deshmukh wrote:
> On Wed, Jan 18, 2017 at 9:21 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 19/01/17 12:27 AM, Nayan Deshmukh wrote:
>>> PresentPixmap only works if the pixmap depth matches the window
>>> depth, otherwise it
Even if the depths match, the result won't look correctly
if the VDPAU RGB component order doesn't match the X11 one. So
technically this actually needs to check the window's visual instead of
just the depth (though in practice I think all X11 visuals use the same
RGB component order).
--
Ear
On 18/01/17 06:47 PM, Christian König wrote:
> Am 18.01.2017 um 09:25 schrieb Michel Dänzer:
>> On 17/01/17 09:55 PM, Christian König wrote:
>>> Module: Mesa
>>> Branch: master
>>> Commit: 15bfdea99c7b487d2c38d6dd7b88fb44810ef75a
>>> URL:
>>
all back to the old method
otherwise.
If this takes significant effort, maybe just revert the commit for now.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
> + templ->height0 == 1 ||
> + /* Assume that the linear alignment has to be 64 texels. */
> + (templ->width0 > 32 &&
> + templ->height0 <= 4))
> return RADEON_SURF_MODE_LINEAR
rame count passes a threshold?
Or are you thinking of something else?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
he kernel driver doesn't catch it but pretends that it works.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lis
On 11/01/17 05:13 PM, Nayan Deshmukh wrote:
> On Wed, Jan 11, 2017 at 12:44 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
>>> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>>>>
On 10/01/17 06:53 PM, Nayan Deshmukh wrote:
> On Sat, Jan 7, 2017 at 12:42 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 06/01/17 05:50 AM, Andy Furniss wrote:
>>> Christian König wrote:
>>>> Am 04.01.2017 um 18:13 schrieb Nayan Deshmukh:
>>>
at userspace is only notified of a vertical blank period
when it's already over, so it doesn't get a chance to do anything inside
the vertical blank period.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
On 09/01/17 08:08 PM, Christian König wrote:
> Am 09.01.2017 um 11:58 schrieb Marek Olšák:
>> On Mon, Jan 9, 2017 at 7:25 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>>> On 09/01/17 03:13 PM, Michel Dänzer wrote:
>>>> On 07/01/17 11:46 PM, Marek Olšák wrot
On 09/01/17 03:13 PM, Michel Dänzer wrote:
> On 07/01/17 11:46 PM, Marek Olšák wrote:
>> From: Marek Olšák <marek.ol...@amd.com>
>>
>> ~/.drirc is created by the driconf tool (GPL license) and it overrides
>> system drirc settings and can't be changed by Me
mending its use), not the ~/.drirc file. This is throwing out the
proverbial baby with the bathwater. Fix the problem instead.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_
> I guess that may not count as an issue with these patches as such if
> xorg/xf86-video-amdgpu can work around, but it's a very noticeable
> regression until that happens.
Somebody should track down why the buffers sent for presentation in
ffer_object@fbo-depthtex and some of the tests in
spec@arb_fragment_program(_shadow) with radeonsi and llvmpipe, because
prog->sh.data == NULL.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_
On 16/12/16 08:22 PM, Nicolai Hähnle wrote:
> On 16.12.2016 10:52, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> Only copy/memset the pointers that actually need to be.
>>
>> Signed-off-by: Michel Dänzer <michel.daen...
From: Michel Dänzer <michel.daen...@amd.com>
Remove currently bound sampler states from the hash table before pruning
entries from the hash table, so currently bound states cannot
accidentally be deleted by the pruning.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
From: Michel Dänzer <michel.daen...@amd.com>
Preparation for following changes, no functional change intended.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/auxiliary/cso_cache/cso_context.c | 33 +++
1 file changed, 18 insertions(+),
From: Michel Dänzer <michel.daen...@amd.com>
It turned out to be slightly more complicated than I'd expected, but I
think I've found a good solution with low (hopefully insignificant)
additional overhead. In fact, thanks to the optimization in patch 3, the
overhead may be slightly
From: Michel Dänzer <michel.daen...@amd.com>
If info->nr_samplers > ctx->nr_fragment_samplers_saved, the assignment
would prevent cso_single_sampler_done from unbinding the no longer used
samplers from the driver, which could result in use-after-free. This is
probably unl
From: Michel Dänzer <michel.daen...@amd.com>
Only copy/memset the pointers that actually need to be.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/auxiliary/cso_cache/cso_context.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
From: Michel Dänzer <michel.daen...@amd.com>
This reverts commit 6dc96de303290e8d1fc294da478c4f370be98dea. No longer
necessary with the previous change.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/auxiliary/cso_cache/cso_cache.c | 4 +---
1 file changed,
From: Michel Dänzer <michel.daen...@amd.com>
Preparation for following changes, no functional change intended.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/auxiliary/cso_cache/cso_cache.h | 1 +
src/gallium/auxiliary/cso_cache/cso_context.c | 1 +
2 file
On 07/12/16 07:16 PM, Nicolai Hähnle wrote:
> On 07.12.2016 08:50, Michel Dänzer wrote:
>> On 06/12/16 10:24 PM, Marek Olšák wrote:
>>> On Mon, Dec 5, 2016 at 10:05 AM, Michel Dänzer <mic...@daenzer.net>
>>> wrote:
>>>> On 03/12/16 05:38 AM, Marek O
On 08/12/16 12:02 AM, Roland Scheidegger wrote:
> The bug in llvm has been fixed, can you confirm lp_test_format passes again?
Yep, it does, thanks!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa an
On 08/12/16 11:53 AM, Pierre-Loup A. Griffais wrote:
> On 12/07/2016 06:13 PM, Michel Dänzer wrote:
>> On 08/12/16 09:59 AM, Rob Clark wrote:
>>> +author again.. no idea why list keeps loosing extra cc's..
>>
>> Mailman removes addresses from Cc which are subscribed
On 08/12/16 09:59 AM, Rob Clark wrote:
> +author again.. no idea why list keeps loosing extra cc's..
Mailman removes addresses from Cc which are subscribed to the list and
have "Avoid duplicate copies of messages?" enabled in the list
Subscription Options.
--
Earthling
On 07/12/16 07:16 PM, Nicolai Hähnle wrote:
> On 07.12.2016 08:50, Michel Dänzer wrote:
>> On 06/12/16 10:24 PM, Marek Olšák wrote:
>>> On Mon, Dec 5, 2016 at 10:05 AM, Michel Dänzer <mic...@daenzer.net>
>>> wrote:
>>>> On 03/12/16 05:38 AM, Marek O
On 06/12/16 10:24 PM, Marek Olšák wrote:
> On Mon, Dec 5, 2016 at 10:05 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 03/12/16 05:38 AM, Marek Olšák wrote:
>>> From: Marek Olšák <marek.ol...@amd.com>
>>>
>>> This fixes random ra
ed now.
Yep, it's fixed, thanks!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedeskt
ot;but"? It still works up to max_vertices with your fix, right? Anyway,
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
t-git/piglit/tests/util/piglit-framework-gl/piglit_winsys_framework.c:73
#24 0x77b1de9c in piglit_gl_test_run (argc=2, argv=0x7fffe6b8,
config=0x7fffe580) at
/home/daenzer/src/piglit-git/piglit/tests/util/piglit-framework-gl.c:203
#25 0x5555b04c in main (argc=2, argv=0x7
al, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro [13]
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev m
On 03/12/16 01:31 AM, Emil Velikov wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
>
> Analogous to previous commit
>
> Cc: Michel Dänzer <michel.daen...@amd.com>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
> ---
> src/gal
sh *hash = _cso_hash_for_type(sc, type);
>
>
If I understand correctly, this means that the maximum cache size
effectively isn't enforced for sampler states? Wouldn't it be better
instead to add code which prevents currently bound states from being
deleted fro
From: Michel Dänzer <michel.daen...@amd.com>
Without this, the X server may accumulate stale Present event contexts
if a client creates and destroys multiple swapchains using the same
window.
v2: Based on Chris Wilson's review:
* Use xcb_present_select_input_checked so that protocol
here any point in having the PIPE_CAP_QUERY_DMABUF_MODIFIERS cap, vs
just testing if pipe_screen->get_modifiers_for_format != NULL ?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_
make[1]: *** [lp_test_format] Error 1
make[1]: Leaving directory
'/home/daenzer/src/mesa-git/mesa/build-amd64/src/gallium/drivers/llvmpipe'
Makefile:1424: recipe for target 'check-am' failed
make: *** [check-am] Error 2
make: Leaving directory
'/home
only Nicolai's Reviewed-by
tag on patch 3.
> Sorry for breaking it so badly. Testing SI on GBM apparently wasn't enough.
No worries, shit happens. :)
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Me
From: Michel Dänzer <michel.daen...@amd.com>
For symmetry with surf_drm_to_winsys.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/winsys/radeon/drm/radeon_drm_surface.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/w
From: Michel Dänzer <michel.daen...@amd.com>
Fixes valgrind warnings about using uninitialized memory when starting X.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/winsys/radeon/drm/radeon_drm_surface.c | 31 +++---
1 file changed, 21 inser
From: Michel Dänzer <michel.daen...@amd.com>
Fixes spurious assertion failure in surf_level_drm_to_winsys when
starting X, due to processing a miplevel which was never initialized.
Fixes: e9c76eeeaa67 ("gallium/radeon: remove radeon_surf_level::pitch_bytes")
Signed-off-b
From: Michel Dänzer <michel.daen...@amd.com>
Fixes valgrind warnings about surf_ws->flags being uninitialized while
starting X.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/gallium/winsys/radeon/drm/radeon_drm_surface.c | 2 +-
1 file changed, 1 insertion
On 02/11/16 04:43 PM, Chris Wilson wrote:
> On Wed, Nov 02, 2016 at 04:16:55PM +0900, Michel Dänzer wrote:
>> On 02/11/16 04:13 PM, Chris Wilson wrote:
>>> On Wed, Nov 02, 2016 at 10:09:26AM +0900, Michel Dänzer wrote:
>>>> On 22/10/16 07:00 PM, Chris Wi
On 02/11/16 04:13 PM, Chris Wilson wrote:
> On Wed, Nov 02, 2016 at 10:09:26AM +0900, Michel Dänzer wrote:
>> On 22/10/16 07:00 PM, Chris Wilson wrote:
>>> This applies a synchronisation point to GetBuffers() such that binding a
>>> texture-from-pixmap its ren
t;
> - (*pdraw->psc->driScreen->swapBuffers)(pdraw, 0, 0, 0, flush);
> + (*pdraw->psc->driScreen->swapBuffers)(pdraw, 0, 1, 0, flush);
Shouldn't this depend on the drawable's current swap interval?
--
Earthling Michel Dänzer | http:/
501 - 600 of 2182 matches
Mail list logo
