Hi,
I am playing with llvm/clang v3.2 and mesa.
It's annoying to see these hundreds of warnings...
clang: warning: argument unused during compilation: '-fno-builtin-memcmp'
NOTE: '-fno-builtin-memcmp' is a gcc-specific compiler-flag.
I have done here a brutal solution, maybe someone else h
bed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/ea04208c/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/dfe3588e/attachment.html>
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
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>
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
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
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
On 01/15/2013 06:50 PM, Lucas Stach wrote:
> Am Dienstag, den 15.01.2013, 17:53 +0800 schrieb Mark Zhang:
>> On 01/15/2013 12:05 AM, Thierry Reding wrote:
>>> Add support for the B and C planes which support RGB and YUV pixel
>>> formats and can be used as overlays or hardware cursor.
>>
>> I think
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
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>
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
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>
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>
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
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
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>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/25b3104f/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>
TML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/e3456115/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=59492
smoki changed:
What|Removed |Added
Attachment #73223|text/plain |image/png
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=59492
--- Comment #7 from smoki ---
Supertuxkart game use irlicht engine and ECM_DIFFUSE_AND_AMBIENT command for
the material color, which use vertex color for both diffuse and ambient light.
That irlicht command is actualy glColorMaterial (GL_FRONT_
https://bugs.freedesktop.org/show_bug.cgi?id=59492
--- Comment #6 from smoki ---
Created attachment 73226
--> https://bugs.freedesktop.org/attachment.cgi?id=73226&action=edit
tcl
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=59492
--- Comment #5 from smoki ---
Created attachment 73224
--> https://bugs.freedesktop.org/attachment.cgi?id=73224&action=edit
tcl
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=59492
--- Comment #4 from smoki ---
Created attachment 73223
--> https://bugs.freedesktop.org/attachment.cgi?id=73223&action=edit
swtcl
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=59492
--- Comment #3 from smoki ---
Created attachment 73222
--> https://bugs.freedesktop.org/attachment.cgi?id=73222&action=edit
swtcl
--
You are receiving this mail because:
You are the assignee for the bug.
__
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
> >> wrote:
> >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
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>
On Fri, Jan 18, 2013 at 12:44 AM, Brian Paul wrote:
> 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 regist
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,
- Sedat -
[1] http://cgit.freedesktop.org/mesa/mesa/commit/?id=
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=54133
--- Comment #6 from Ash ---
I am using kernel 3.7.2-201.fc18.x86_64 (Fedora 18) and no libdrm_radeon and am
also experiencing this problem. Problem not present in Fedora 17.
--
You are receiving this mail because:
You are the assignee for the b
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/d25e29cc/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/546d8237/attachment.html>
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,
> -
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
https://bugs.freedesktop.org/show_bug.cgi?id=59492
--- Comment #2 from Roland Scheidegger ---
(In reply to comment #1)
> So default command like
>
> glColorMaterial (GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE)
>
> never worked quite right on tcl.
How did you arrive at this conclusion?
You co
From: Ville Syrj?l?
The AVI infoframe is able to inform the display whether the source is
sending full or limited range RGB data.
As per CEA-861 [1] we must first check whether the display reports the
quantization range as selectable, and if so we can set the approriate
bits in the AVI inforfram
From: Ville Syrj?l?
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
v2: s/quantzation/quantization/ in the comment
Reviewed-by: Paulo Zanoni
Signed-off-by:
From: Ville Syrj?l?
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 [1] guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise
From: Ville Syrj?l?
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limi
Third attempt at handling the RGB quantization range for HDMI and DP.
Changes since the last time:
- Addressed all of Paulo's review comments.
I think this is ready to go in, unless someone complains loudly.
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,
- Sedat -
[1] http
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/77c82471/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 Ubuntu/precise
AM
Hi Dave
More important fixes for 3.9:
- error_state improvements to help debug the new scanline wait code added
for gen6+ - bug reports started popping up :( patch from Chris Wilson.
- fix a panel power sequence confusion between the eDP and lvds detection
code resulting in black screens - reg
https://bugs.freedesktop.org/show_bug.cgi?id=58033
--- Comment #10 from Chris Rankin ---
(In reply to comment #9)
> Could you please attach a screenshot showing the issue?
Sorry, the corruption is not showing up which I press the "Print Screen"
button. I shall attempt to describe instead:
Imagi
On Thu, Jan 17, 2013 at 10:16:46AM -0200, Paulo Zanoni wrote:
> Hi
>
> 2013/1/16 :
> > From: Ville Syrj?l?
> >
> > The AVI infoframe is able to inform the display whether the source is
> > sending full or limited range RGB data.
> >
> > As per CEA-861 we must first check whether the display repo
On 01/15/2013 12:06 AM, Thierry Reding wrote:
> All the necessary support bits like .mode_set_base() and VBLANK are now
> available, so page-flipping case easily be implemented on top.
>
> Signed-off-by: Thierry Reding
[...]
> +
> +static int tegra_dc_page_flip(struct drm_crtc *crtc, struct drm_f
https://bugs.freedesktop.org/show_bug.cgi?id=58033
--- Comment #9 from Marek Olšák ---
Could you please attach a screenshot showing the issue?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-dev
On 01/15/2013 12:05 AM, Thierry Reding wrote:
> The sequence for replacing the scanout buffer is much shorter than a
> full mode change operation so implementing this callback considerably
> speeds up cases where only a new framebuffer is to be scanned out.
>
> Signed-off-by: Thierry Reding
> ---
I noticed that bsp, vp and ppp had no interrupt handler after investigating why
15% of my cpu time went to interrupts.
nouveau was silent about it, but it should be an error since we have no way of
acking in that case.
Signed-off-by: Maarten Lankhorst
---
fwiw, the interrupt was 10, the exi
https://bugs.freedesktop.org/show_bug.cgi?id=58033
--- Comment #8 from Chris Rankin ---
Still broken as of git HEAD:
commit ca39c0f94a4e3cc25b6cc9507fb729b85140733a
Author: Ian Romanick
Date: Wed Jan 16 15:34:49 2013 -0800
mesa/es3: Don't check dimensions in _mesa_es3_error_check_format_
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
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
On Thu, Jan 17, 2013 at 9:42 AM, Jani Nikula
wrote:
> On Fri, 11 Jan 2013, 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 ve
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 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
>>
On 01/16/2013 07:53 PM, Lucas Stach wrote:
> Am Mittwoch, den 16.01.2013, 19:10 +0800 schrieb Mark Zhang:
>> I'm testing the pageflip & vblank change on cardhu. Seems the HDMI
>> doesn't work(LVDS only is OK). I'll let you know if I get something.
>>
> Just to provide another data point: I'm runnin
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
Hi
2013/1/16 :
> From: Ville Syrj?l?
>
> Add a new "Automatic" mode to the "Broadcast RGB" range property.
> When selected the driver automagically selects between full range and
> limited range output.
>
> Based on CEA-861 guidelines, limited range output is selected if the
> mode is a CEA mode
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 vi
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #40 from Thomas Rohloff ---
(In reply to comment #39)
> Does it do the same thing without the patch?
It has random crashes without, too, yes. But way less frequent. In fact I had
to revert that patch to be able to use my desktop for
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
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://bugs.freedesktop.org/show_bug.cgi?id=58659
--- Comment #20 from Bryan Quigley ---
This last patch (0001-drm-radeon-exclude-system-placement-when-validating)
creates a full Xorg freeze:
Form xorg.log:
[ 207.780] (WW) RADEON(0): flip queue failed: Invalid argument
[ 207.781] (WW) RADEON
https://bugs.freedesktop.org/show_bug.cgi?id=2377
--- Comment #9 from smoki ---
Created attachment 73194
--> https://bugs.freedesktop.org/attachment.cgi?id=73194&action=edit
ums and mesa 7.5.2 r200 render
But overal, it is not quite correct but polys renders better now then it was
with UMS.
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
Hi
2013/1/16 :
> From: Ville Syrj?l?
>
> The RGB color range select bit on the DP/SDVO/HDMI registers
> disappeared when PCH was introduced, and instead a new PIPECONF bit
> was added that performs the same function.
>
> Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
> it in
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
>> wrote:
>> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
>> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf
>>
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #39 from Alexandre Demers ---
(In reply to comment #38)
> (In reply to comment #37)
> > This patch might help:
>
> I applied it to a 3.8-rc3 kernel and while I didn't see the message spam
> till now the GPU crashes extremely often (s
On Fri, 11 Jan 2013, 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.
Yes, count me in,
Jani.
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
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
>>
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
https://bugs.freedesktop.org/show_bug.cgi?id=2377
--- Comment #8 from smoki ---
I was tested your patch from bug 57842 when you posted it there, but as i
remember many random mesa demos i tried started to segfault with it.
--
You are receiving this mail because:
You are the assignee for the b
Hi
2013/1/16 :
> From: Ville Syrj?l?
>
> The AVI infoframe is able to inform the display whether the source is
> sending full or limited range RGB data.
>
> As per CEA-861 we must first check whether the display reports the
> quantization range as selectable, and if so we can set the approriate
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
Hi
2013/1/16 :
> From: Ville Syrj?l?
>
> drm_rgb_quant_range_selectable() will report whether the monitor
> claims to support for RGB quantization range selection.
>
> The information can be found in the CEA Video capability block.
Looks correct (checked against the spec, did not really test).
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 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: Alex Deucher
1440x900 (native) monitor contains a bogus 1400x1050@75Hz
mode in the standard timings and fails to flag the first
detailed mode as preferred. As such, X picks 1400x1050@75Hz
which fails to display.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=59211
Signed-off-by: Ale
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
>>
On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote:
> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf
> wrote:
> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf
> >> wrote:
> >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf
https://bugs.freedesktop.org/show_bug.cgi?id=2377
--- Comment #7 from Roland Scheidegger ---
Looks to me like the offsets for the stipple pattern are wrong.
These are set in r200UpdateViewportOffset - which has no callers. I noted this
in bug 57842, and tried to address it there though the patch
On Thu, Jan 17, 2013 at 12:36 AM, Aaron Plattner
wrote:
> Can I consider this a Reviewed-by?
Essentially it was just a drive-by bikeshed ;-) I think it'd be good
if Maarten takes a look at this and checks whether it complies with
his massive prime/dma_buf rework to use fences and ticketing
reser
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #38 from Thomas Rohloff ---
(In reply to comment #37)
> This patch might help:
I applied it to a 3.8-rc3 kernel and while I didn't see the message spam till
now the GPU crashes extremely often (so often that this might be the case I'
https://bugs.freedesktop.org/show_bug.cgi?id=59521
--- Comment #2 from Laurent carlier ---
Of course, lib32-libtxc_dxtn is installed:
$ pacman -Qs lib32-libtxc_dxtn
local/lib32-libtxc_dxtn 1.0.1-3
Texture compression library for Mesa (32-bit)
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=59521
--- Comment #1 from Alex Deucher ---
If the game uses compressed textures, make sure you have libtxc-dxtn installed.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-d
https://bugs.freedesktop.org/show_bug.cgi?id=59521
Priority: medium
Bug ID: 59521
Assignee: dri-devel@lists.freedesktop.org
Summary: [Serious Sam 3] Missing textures with R600g
Severity: normal
Classification: Unclassified
OS
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
> >> wrote:
> >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=58659
--- Comment #19 from Jerome Glisse ---
Updated patch
http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch
Still weird that you point to same commit and first patch did not solve it.
--
You are
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
>> wrote:
>> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
>> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf
>>
From: Ville Syrjälä
The AVI infoframe is able to inform the display whether the source is
sending full or limited range RGB data.
As per CEA-861 [1] we must first check whether the display reports the
quantization range as selectable, and if so we can set the approriate
bits in the AVI inforfram
From: Ville Syrjälä
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
v2: s/quantzation/quantization/ in the comment
Reviewed-by: Paulo Zanoni
Signed-off-by:
From: Ville Syrjälä
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 [1] guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise
From: Ville Syrjälä
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limi
Third attempt at handling the RGB quantization range for HDMI and DP.
Changes since the last time:
- Addressed all of Paulo's review comments.
I think this is ready to go in, unless someone complains loudly.
___
dri-devel mailing list
dri-devel@lists.fr
1 - 100 of 127 matches
Mail list logo
