https://bugs.freedesktop.org/show_bug.cgi?id=89148
Stefan Dösinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=89148
--- Comment #13 from Stefan Dösinger ---
The thing that seems to trigger the sRGB correction is the fact that the
destination texture has an sRGB internal. If I change it to GL_RGBA8 I get the
expected result.
The format of the source RB doesn'
https://bugs.freedesktop.org/show_bug.cgi?id=89148
--- Comment #12 from Marek Olšák ---
r300g doesn't do sRGB conversion for MSAA resolves. It always interprets the
textures as linear and only averages the samples.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=89148
--- Comment #11 from Stefan Dösinger ---
Attachment 113802 fixes the invalid CS / crash and my test program now reads a
color. However, sRGB color correction seems to be applied at some stage. Note
that the test program is not using GL_ARB_frame
https://bugs.freedesktop.org/show_bug.cgi?id=89148
Marek Olšák changed:
What|Removed |Added
Attachment #113719|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=89148
--- Comment #9 from Stefan Dösinger ---
No more segfaults, but it still has a rejected CS:
[129870.605179] [drm:r100_cs_track_check] *ERROR* [drm] Buffer too small for
color buffer 0 (need 8387584 have 524288) !
[129870.605186] [drm:r100_cs_tra
https://bugs.freedesktop.org/show_bug.cgi?id=89148
--- Comment #8 from Marek Olšák ---
I'm pretty sure the CS parser errors were caused by random garbage emitted by
r300g. The driver doesn't expect an sRGB format in the framebuffer, which only
seems to happen with glBlitFramebuffer.
--
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=89148
--- Comment #7 from Stefan Dösinger ---
I'll try it in the next two days. If the workaround doesn't work I'll try to
get the log Alex asked for.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part
https://bugs.freedesktop.org/show_bug.cgi?id=89148
--- Comment #6 from Marek Olšák ---
Created attachment 113719
--> https://bugs.freedesktop.org/attachment.cgi?id=113719&action=edit
workaround
Can you test this patch? Note that GL_ARB_framebuffer_sRGB is unsupported.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=89148
--- Comment #5 from Alex Deucher ---
Created attachment 113620
--> https://bugs.freedesktop.org/attachment.cgi?id=113620&action=edit
add some debugging output
Can you apply this kernel patch and attach your kernel log output when you hit
the e
https://bugs.freedesktop.org/show_bug.cgi?id=89148
--- Comment #4 from Stefan Dösinger ---
Created attachment 113562
--> https://bugs.freedesktop.org/attachment.cgi?id=113562&action=edit
Test program
This program reproduces the result. As a 32 bit binary it generates the same
type 1 command t
https://bugs.freedesktop.org/show_bug.cgi?id=89148
--- Comment #3 from Stefan Dösinger ---
My semi-educated guess would be that the multisample resolve blit sets the size
wrong. That would explain why out of the many glGetTexImage calls we're doing
this is the only one that fails.
Time to write
https://bugs.freedesktop.org/show_bug.cgi?id=89148
--- Comment #2 from Alex Deucher ---
Type 1 packets shouldn't be emitted at all and none of the user mode drivers
emit them. I suspect either the command stream is getting corrupted somewhere
or there is a prior packet count getting set wrong.
https://bugs.freedesktop.org/show_bug.cgi?id=89148
--- Comment #1 from Stefan Dösinger ---
Note that the texture is never used as a source or destination in a regular
draw. It is specified with glTexImage2D, but the data pointer is NULL, and
glTexSubImage2D is never used. It is only filled with
https://bugs.freedesktop.org/show_bug.cgi?id=89148
Bug ID: 89148
Summary: r300g: Kernel rejected CS in Wine d3d multisample test
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: nor
15 matches
Mail list logo
