https://bugs.freedesktop.org/show_bug.cgi?id=73528
Priority: medium
Bug ID: 73528
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Deferred lighting in Second Life causes system hiccups
and screen flickering
Severity: major
Classification: Unclassified
OS: Linux (All)
Reporter: sonichedgehog_hyperblast00(a)yahoo.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/DRI/R600
Product: Mesa
I compiled Mesa with libdrm from their GIT repositories (10.1, commit
2dc35a619c50139d07ad96fc4dfe456e5811c84e). I started up the Second Life viewer
through it (Kokua x64, 3.6.12.30743, Dec 12 2013 05:51:00) and logged in.
Upon enabling Advanced Lighting Model from Preferences - Graphics, the system
froze and the screen started flickering, turning black then recovering every
few seconds. The scene also got covered in pink pixels, meaning it also failed
to render correctly. I was barely able to move the mouse pointer and shut the
viewer down. Once I did, everything returned to normal.
This does not happen with Mesa 9.2.3, and other Graphics options in the viewer
work fine (like "Basic shaders" or "Atmospheric shaders"). Shadows were
disabled and likely not a cause.
If someone has Second Life, please try the deferred lighting system under the
10.1 development version of Mesa. Currently, I don't have any more information
on the problem apart from having experienced the described symptoms.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=36782
Summary: textures on Earth in Celestia contain pixels from
other windows
Product: Mesa
Version: 7.10
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/R600
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: acelists(a)atlas.sk
Created an attachment (id=46261)
--> (https://bugs.freedesktop.org/attachment.cgi?id=46261)
See the blue dotted band around the planet - it is a window titlebar.
Textures on the planet Earth are rendered garbled with data pixel taken from
other windows (programs), probably taken from released GPU memory. Note it only
happens on Earth. The garbled texture is not the planet surface one, but it is
the clouds layer. That is loaded from a file that is 1024x512.
It does not happen when lowres textures are selected. Then a 128x64px file is
used for the clouds.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=71461
Bug ID: 71461
Summary: monitor doesn't get detected after boot
Product: Drivers
Version: 2.5
Kernel Version: 3.13.5
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-dri(a)kernel-bugs.osdl.org
Reporter: tom.ty89(a)gmail.com
Regression: No
My card is Radeon HD5850.
The result might varies between different boot. Either the screens would not be
detected at all or they seem to be detected with a non-optimal resolution (in
console, while gdm shows a broken screen)
If a monitor is connected before boot, others can get detected correctly
afterwards.
If only one monitor is connected, turning it off can make the signal lost.
Reboot or suspend/resume (after turning it on again) can bring the signal back.
(Yet dpms would cause no problem at all)
The only way to reproduce the problem if DVI is involved is to disconnect it
physically, otherwise only powering off the monitor is required. My guess is
DVI detects display with a different mechanism.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66977
Priority: medium
Bug ID: 66977
Assignee: dri-devel(a)lists.freedesktop.org
Summary: get_num_groups not supported by libclc
Severity: trivial
Classification: Unclassified
OS: Linux (All)
Reporter: jcharest(a)gmail.com
Hardware: All
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
Created attachment 82499
--> https://bugs.freedesktop.org/attachment.cgi?id=82499&action=edit
Here is the patch to call the appropriate intrinsic
Currently libclc does not support get_num_groups on r600 so it will give out an
error when used in an opencl kernel.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=56659
Priority: medium
Bug ID: 56659
Assignee: dri-devel(a)lists.freedesktop.org
Summary: DRI_PRIME: triangle, rendering inside of which occurs
with a noticeable delay
Severity: normal
Classification: Unclassified
OS: All
Reporter: runetmember(a)gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: XOrg CVS
Component: DRM/Radeon
Product: DRI
Created attachment 69414
--> https://bugs.freedesktop.org/attachment.cgi?id=69414&action=edit
Example of artifact
Hello!
Please look at attached screenshot - there is triangle where we still see part
of old frame, that was displayed on screen few frames before. I doesn't sure
about terminology, but from my point of view looks like rendering in this
triangle is lag behind rest of the screen.
This issue happen for me only for applications launched with enabled offloading
rendering (DRI_PRIME=1). It's reproducible not only in "Left 4 Dead 2" but also
in other applications. Even in Chromium (if you launch it with
"--ignore-gpu-blacklist" option that enabled hardware rendering on Mesa, and
"DRI_PRIME=1" that enable offloading rendering) display same artifact
(triangle) while scrolling pages. Also you may notice this artifact in
glxgears, if you you run it in fullscreen mode.
Software:
Kubuntu 12.10 x86_64 updated from Xorg Edgers PPA.
Mesa: 9.1~git20121029.00e6819e
libdrm-radeon1: git20121025.bc494b31
xserver-xorg-video-radeon: git20120928.e8cb0b72
xserver-xorg-core: 1.13.0+git20120920.70e57668
Enabled or disabled V-Sync in KWin settings doesn't make the difference.
Enabled or disabled V-Sync in game settings doesn't make the difference.
Screenshot taken with stock Kubuntu kernel (3.5.0-17). With 3.7rc3 kernel issue
still reproducible, but just a bit less noticeable.
Hardware:
Acer Aspire 7560G laptop,
AMD APU A8-3500M with integrated Radeon HD 6620G (SUMO)
Discrete AMD Radeon HD 6650M (TURKS)
"xrandr --listproviders" output:
Providers: number : 2
Provider 0: id: 138 cap: 0xd, Source Output, Source Offload, Sink Offload
crtcs: 2 outputs: 3 associated providers: 1 name:radeon
Provider 1: id: 85 cap: 0xd, Source Output, Source Offload, Sink Offload crtcs:
6 outputs: 0 associated providers: 1 name:radeon
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66384
Priority: medium
Bug ID: 66384
Assignee: dri-devel(a)lists.freedesktop.org
Summary: VDPAU playback hangs when moving window between xrandr
monitors
Severity: normal
Classification: Unclassified
OS: All
Reporter: mgorny(a)gentoo.org
Hardware: Other
Status: NEW
Version: unspecified
Component: Drivers/Gallium/r600
Product: Mesa
I'm running live xorg/mesa with Radeon HD5450. I have two monitors connected
and set up side-by-side using xrandr like the following:
$ xrandr --output VGA-0 --mode 1280x960 --right-of DVI-0
Now, when I play a movie using mplayer2 with VDPAU driver and move the movie
onto second monitor without pausing it first, the playback hangs for a minute
or two. Then it resumes like nothing happened, no messages neither on console
nor in dmesg.
What's interesting is that it seems to happen only after moving half of the
window. If I have it partially on both monitors, it plays back fine. After the
hang it plays fine again, and if I then move it back to the first monitor, it
again hangs after moving half of it.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=53118
Bug #: 53118
Summary: Rendering error in unigine heaven when
GL_ARB_shader_bit_encoding is used.
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r600
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: thomas.lindroth(a)gmail.com
Created attachment 65111
--> https://bugs.freedesktop.org/attachment.cgi?id=65111
screenshot
Textures are rendered incorrectly in unigine heaven on latest git drivers with
kernel 3.5.0 when shaders are set to high and ambient occlusion is on. The
problem is fixed when exporting
MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_bit_encoding"
Hardware is juniper.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=74329
Priority: medium
Bug ID: 74329
Assignee: dri-devel(a)lists.freedesktop.org
Summary: Please expose OES_texture_float and
OES_texture_half_float on the ES3 context
Severity: minor
Classification: Unclassified
OS: Linux (All)
Reporter: org.freedesktop(a)io7m.com
Hardware: All
Status: NEW
Version: 10.0
Component: Drivers/DRI/R600
Product: Mesa
Hello.
Original discussion on mailing list:
http://lists.freedesktop.org/archives/mesa-users/2014-February/000761.html
Essentially, for the purposes of testing code in an ES3 context as it would be
run on an ES2 context (that is, taking the paths the code would take based on
the extensions present on ES2), it would be nice if the ES3 context exposed
OES_texture_float and OES_texture_half_float.
The current ES3 context on this hardware exposes GL_EXT_texture_rg and
GL_EXT_color_buffer_float, and can therefore definitely support
OES_texture_float and OES_texture_half_float. All that would (apparently) be
required would be for floating point textures to be specified in an ES2
compatible manner (with format and internalformat set to GL_RED|GL_RG, and type
set to GL_FLOAT).
--
You are receiving this mail because:
You are the assignee for the bug.