- Nov 06, 2012
-
-
Marek Olšák authored
-
- Nov 05, 2012
-
-
Dave Airlie authored
typo, Reported-by: mareko on irc Signed-off-by: Dave Airlie <airlied@redhat.com>
-
- Oct 26, 2012
-
-
Marek Olšák authored
The calculation led to the number 8192, which is too high. Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
- Oct 24, 2012
-
-
Andreas Boll authored
radeon_cs_gem.c:333:13: warning: 'cs_gem_dump_bof' defined but not used [-Wunused-function] Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
- Oct 16, 2012
-
-
Alex Deucher authored
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
- Oct 14, 2012
-
-
Rob Clark authored
If we have valid timings, we can at least set width/height to *something*, which is I think at least less confusing than always seeing width/height of zero. At least modeprint and modetest seem to expect width/height to mean something. Signed-off-by: Rob Clark <rob@ti.com>
-
- Oct 09, 2012
-
-
Rob Clark authored
Signed-off-by: Rob Clark <rob@ti.com>
-
Vincent Penquerc'h authored
Signed-off-by: Rob Clark <rob@ti.com>
-
- Oct 08, 2012
-
-
Daniel Stone authored
We don't want to build libdrm tests with Cairo support under Poky, since they're never used and also cause a build loop from libdrm -> cairo -> mesa-dri -> libdrm. To avoid variance in build results, introduce a --disable-cairo-tests switch. Signed-off-by: Daniel Stone <daniel@fooishbar.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
- Oct 07, 2012
-
-
Chris Wilson authored
intel_bufmgr_gem.c: In function 'drm_intel_bo_gem_export_to_prime': intel_bufmgr_gem.c:2477:6: warning: unused variable 'ret' [-Wunused-variable] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
commit 92fd0ce4 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Aug 31 11:16:53 2012 +0200 intel: properly test for HAS_LLC missed slightly and in effect had no effect on the outcome of checking whether the kernel/chipset supported LLC. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- Oct 06, 2012
-
-
Marek Olšák authored
This allows texturing with depth-stencil buffers directly without the copy to CB. The separate miptree description for stencil is added, because the stencil mipmap offsets are not really depth offsets/4 (at least for the texture units). Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
Marek Olšák authored
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
- Oct 03, 2012
-
-
Marek Olšák authored
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
-
- Sep 17, 2012
-
-
Jesse Barnes authored
-
- Sep 15, 2012
-
-
Kristian Høgsberg authored
It's the same situation as flink and we need take the same precautions. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
-
- Sep 13, 2012
-
-
Jesse Barnes authored
Just some PCI ID stuff to enable the right features.
-
- Sep 07, 2012
-
-
Marcin Ślusarz authored
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
-
- Sep 06, 2012
-
-
Another corner case that isn't well-explained yet. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
-
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
-
- Sep 05, 2012
-
-
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
-
- Sep 01, 2012
-
-
Simona Vetter authored
If the kernel supports the test, we need to check the param. Copy&pasta from the above checks that only look at the return value. Interesting how much one can get such a simple interface wrong. Issue created in commit 151cdcfe Author: Eugeni Dodonov <eugeni.dodonov@intel.com> Date: Tue Jan 17 15:20:19 2012 -0200 intel: query for LLC support Patch even claims to have fixed this in v2, but is actually unchanged from v1. Reported-by: Xiang, Haihao <haihao.xiang@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- Aug 24, 2012
-
-
Jakob Bornecrantz authored
And hasn't been in a long while. Reviewed-by: Zack Rusin <zackr@vmware.com> Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
-
Marek Olšák authored
-
Marek Olšák authored
I am not sure whether this is needed, but better be safe than sorry.
-
Marek Olšák authored
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
-
- Aug 23, 2012
-
-
Víctor Manuel Jáquez Leal authored
omap_drm.h uses data type defined in stdint.h, but that header was not included. omap_drm.h includes drm.h as a local file when it is part of the compiler c flags. This two issues are fixed. New code can include omap_drm.h alone. Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com> Signed-off-by: Rob Clark <rob@ti.com>
-
- Aug 14, 2012
-
-
Dave Airlie authored
this adds radeon version of the prime import/export support. Signed-off-by: Dave Airlie <airlied@redhat.com>
-
- Aug 13, 2012
-
-
Kenneth Graunke authored
Otherwise pad appears uninitialized and valgrind grumbles. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
-
- Aug 11, 2012
-
-
Signed-off-by: Marek Olšák <maraeo@gmail.com>
-
Marek Olšák authored
-
Marek Olšák authored
-
- Aug 10, 2012
-
-
Emma Anholt authored
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
-
Emma Anholt authored
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
-
Emma Anholt authored
It warns about totally sensible things done in intel_decode.c. I've never seen this warn do anything useful, and apparently I was the one to introduce it when I added the giant pile of warning flags back in 2008. Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
-
- Aug 09, 2012
-
-
Marek Olšák authored
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
-
Marek Olšák authored
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
-
Marek Olšák authored
If we don't need stencil, don't allocate it. If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth. v2: actually do it correctly Reviewed-by: Christian König <christian.koenig@amd.com>
-
Marek Olšák authored
Setting those flags has no effect anywhere else. Reviewed-by: Christian König <christian.koenig@amd.com>
-