On 2017-01-07 15:46, Marek Olšák wrote:
>
> -The filters can be toggled per-app via driconf, or per-session via the
> -corresponding environment variables.
> +The filters can be via the corresponding environment variables.
>
I think you have missed a word here.
Jacek
___
This was causing crashes in The Talos Principle, on a pipeline without
a fragment shader stage.
Signed-off-by: Jacek Konieczny
---
This was my attempt to fix The Talos Principle on Vulkan on Intel Haswell, the
problem described in https://bugs.freedesktop.org/show_bug.cgi?id=94831
I don't
On 2016-03-12 19:21, Jason Ekstrand wrote:
>> > Haswell should still work just fine if
>> > you're on a 4.4 kernel, but we really should make it detect the command
>> > parser version and do something intelligent.
>>
>> I am confused now… Should it 'work just fine' without this hack on 4.4,
>> or i
On 2016-03-12 17:58, Jason Ekstrand wrote:
> There is a bug report that's tracking this regression:
> https://bugs.freedesktop.org/show_bug.cgi?id=94468
>
> In the meantime, a workaround is comment out:
> genX(cmd_buffer_config_l3)(cmd_buffer, false);
> in src/intel/vulkan/genX
On 2016-03-12 11:59, Jacek Konieczny wrote:
> Hi,
>
> I have been playing with Vulkan API and using the Mesa Intel Vulkan
> driver from the 'vulkan' branch.
>
> Recent driver upgrade has broken my, previously working code, causing
> massive flickering and graph
Hi,
I have been playing with Vulkan API and using the Mesa Intel Vulkan
driver from the 'vulkan' branch.
Recent driver upgrade has broken my, previously working code, causing
massive flickering and graphical artifacts.
git bisect have shown, that this is the breaking change:
commit 7ebbc3946ae9
On 2016-03-01 10:10, Martin Peres wrote:
On 29/02/16 20:48, Jason Ekstrand wrote:
On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert mailto:galib...@pobox.com>> wrote:
Ok, I can tell you that 3DSTATE_DEPTH_BUFFER and
3DSTATE_STENCIL_BUFFER seem perfectly correct (assuming the gem
add
Hi,
Even if it is unfinished, this probably should not be that inconsistent:
anv_GetPhysicalDeviceFeatures() in anv_device.c:
.pipelineStatisticsQuery = true,
anv_CreateQueryPool() in anv_query.c:
case VK_QUERY_TYPE_PIPELINE_STATISTICS:
return VK_ERROR_INCOMPATI
On 2016-02-27 19:58, Jason Ekstrand wrote:
>
>
> On Sat, Feb 27, 2016 at 5:47 AM, Jacek Konieczny <mailto:jaj...@jajcus.net>> wrote:
>
> The same handle returned by all vkCreateSemaphore() calls confuses
> validation layers:
>
>
> From the
On 2016-02-27 19:32, Kenneth Graunke wrote:
> On Saturday, February 27, 2016 2:47:22 PM PST Jacek Konieczny wrote:
>> The same handle returned by all vkCreateSemaphore() calls confuses
>> validation layers:
>>
>> SEMAPHORE(ERROR): object: 0x1 type: 5 location: 1443 m
The same handle returned by all vkCreateSemaphore() calls confuses
validation layers:
SEMAPHORE(ERROR): object: 0x1 type: 5 location: 1443 msgCode: 0: vkQueueSubmit:
Semaphore must not be currently signaled or in a wait state
Signed-off-by: Jacek Konieczny
---
src/intel/vulkan/anv_device.c
11 matches
Mail list logo
