the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/c7452517/attachment.html>
TML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/e3456115/attachment.html>
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/136bb9c0/attachment-0001.html>
On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf
wrote:
> On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote:
>> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf
>> wrote:
>> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote:
>> >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf
>>
From: Alex Deucher
1440x900 (native) monitor contains a bogus 1400x1050 at 75Hz
mode in the standard timings and fails to flag the first
detailed mode as preferred. As such, X picks 1400x1050 at 75Hz
which fails to display.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=59211
Signed-off-b
On 2013.01.17 at 12:55 -0500, Jerome Glisse wrote:
> On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf
> wrote:
> > On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote:
> >> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf
> >> wrote:
> >> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote
From: Michel D?nzer
Very similar to Evergreen, but slightly different rules for tile / slice
alignment. Fortunately, these map quite naturally onto the previous fixes for
linear aligned layout on SI.
2D tiling still needs more work here and possibly in the kernel.
Signed-off-by: Michel D?nzer
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/25b3104f/attachment.html>
On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
> Actually, the code path affected by your patch is not executed in UMS mode
> at all. Notice that radeon_cs_parser_fini is only called from
> radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c).
>
> The equivalent of the fix you ar
On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf
wrote:
> On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote:
>> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf
>> wrote:
>> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote:
>> >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf
>>
One more fix on top. Just a revert of the bo placement patch that has
been causing corruption for a number of people.
Revert "drm/radeon: do not move bo to different placement at each cs"
This reverts commit d025e9e2b890db679f1246037bf65bd4be512627.
This causes corruption for a numb
pplied it yesterday and I
haven't seen any difference.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/787696e4/attachment-0001.html>
On 2013.01.17 at 13:28 -0500, Jerome Glisse wrote:
> On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf
> wrote:
> > On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote:
> >> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf
> >> wrote:
> >> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote
ith UMS.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/5fae454c/attachment.html>
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/05ef76dc/attachment.html>
This might be responsible for the bad r300g MSAA performance results
on Phoronix. I have no other explanation.
There is an optimization in r300g which forces the VRAM domain for
non-staging CB and DB only. Other than that, VRAM|GTT is the default
for all textures and GTT is the default for all buf
https://bugzilla.kernel.org/show_bug.cgi?id=52491
--- Comment #15 from Bruno Jacquet 2013-01-17 19:26:36 ---
(In reply to comment #14)
> Better to try this patch instead first :
> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch
With this
for more than 5 minutes
again.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/dd2d4bf8/attachment.html>
Hi,
I experience a strange problem, I don't know whether
it's a feature or a bug, and if it's a bug, where.
I have a Radeon HD6570. A monitor via DVI and an LCD TV
via HDMI are connected. Fedora 18/x86_64 is installed on
the computer. (Previously it was F17, F16 and F14.)
When playing videos via
On Fri, Jan 11, 2013 at 09:27:03PM +0100, Laurent Pinchart wrote:
> Would anyone be interested in meeting at the FOSDEM to discuss the Common
> Display Framework ? There will be a CDF meeting at the ELC at the end of
> February, the FOSDEM would be a good venue for European developers.
We are in
ns in _mesa_es3_error_check_format_and_type
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/307edf70/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/dfe3588e/attachment.html>
bed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/ea04208c/attachment.html>
On 01/17/2013 02:14 PM, Sedat Dilek wrote:
> Hi
>
> I am playing again with llvm/clang v3.2 and patches I adapted from
> LLVMLinux project.
>
> I wanted to test my new toolchain before doing a rough testing of the
> mainline Linux-kernel.
>
> I decided to build the latest mesa-8.0.5 as I am on Ubun
On 01/17/2013 04:23 PM, Sedat Dilek wrote:
> Hi,
>
> with the following patchset (13 patches) I was able to build
> mesa-8.0.5 with LLVM v3.2.
>
> There is one big fat patch called "gallivm,draw,llvmpipe: Support
> wider native registers." [1] which makes backporting hard.
> Jose?
>
> Regards,
> -
parser->chunks[.].kpage[.] is not always kmalloc-ed
by the parser initialization, so parser_fini should
not try to kfree it if it didn't allocate it.
This patch fixes a kernel oops that can be provoked
in UMS mode.
Upstream commit-id: a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e
Tested on stable 3.7
Hi
I am playing again with llvm/clang v3.2 and patches I adapted from
LLVMLinux project.
I wanted to test my new toolchain before doing a rough testing of the
mainline Linux-kernel.
I decided to build the latest mesa-8.0.5 as I am on Ubuntu/precise
AMD64 here by making me and my build-deps happy
101 - 127 of 127 matches
Mail list logo
