Bug 84145 - UE4: Realistic Rendering Demo render blue
Summary: UE4: Realistic Rendering Demo render blue
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-21 21:15 UTC by smoki
Modified: 2014-09-26 06:03 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
before (64.24 KB, image/jpeg)
2014-09-21 21:16 UTC, smoki
Details
after (77.36 KB, image/jpeg)
2014-09-21 21:16 UTC, smoki
Details
borked.jpg (72.57 KB, image/jpeg)
2014-09-24 06:25 UTC, smoki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description smoki 2014-09-21 21:15:45 UTC
Bisected to d82bd7eb060cf2fbb7282da38f28f6e7ea705e12
 
 mesa/st: add ARB_texture_view support
 
 Before and after screenshots attached, happens in today git too.
Comment 1 smoki 2014-09-21 21:16:17 UTC
Created attachment 106624 [details]
before
Comment 2 smoki 2014-09-21 21:16:47 UTC
Created attachment 106625 [details]
after
Comment 3 Marek Olšák 2014-09-21 22:14:34 UTC
Where can I download the demo?
Comment 4 Andy Furniss 2014-09-21 22:36:22 UTC
(In reply to comment #3)
> Where can I download the demo?

https://wiki.unrealengine.com/Linux_Demos
Comment 5 smoki 2014-09-22 05:53:17 UTC
 Yeah that is the link, you can choose Vehicle Game that is also affected.

 Even before this it does not render correctly, it was mostly like nonexistent NightDay map + some corruption outside :D If you don't aware off you can try all three maps, by changing config with those i think:

 https://docs.unrealengine.com/latest/INT/Resources/Showcases/RealisticRendering/index.html#availablemaps

 But OK that is another bug ;)
Comment 6 Michel Dänzer 2014-09-22 05:57:32 UTC
Ilia, any ideas?
Comment 7 Tapani Pälli 2014-09-22 07:46:02 UTC
IMO this not a Mesa core bug as the demo renders correctly on Intel.
Comment 8 Michel Dänzer 2014-09-22 08:32:07 UTC
(In reply to comment #7)
> IMO this not a Mesa core bug as the demo renders correctly on Intel.

We're also using the 'Mesa core' component for Gallium state tracker bugs. The bisected commit only changes state tracker code, no driver specific code.
Comment 9 Tapani Pälli 2014-09-22 09:11:44 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > IMO this not a Mesa core bug as the demo renders correctly on Intel.
> 
> We're also using the 'Mesa core' component for Gallium state tracker bugs.
> The bisected commit only changes state tracker code, no driver specific code.

ok cool
Comment 10 Ilia Mirkin 2014-09-22 14:02:36 UTC
(In reply to comment #6)
> Ilia, any ideas?

Oh neat. I was seeing that render blue as well, but was assuming it was due to some spill errors that I had only semi-fixed.

The interesting thing to note is that the commit in question doesn't actually enable ARB_texture_view on any driver, just sets the stage for it.

My guess is that it's due to the st_format.c hunk, but I can't imagine why. Oh hrm. Perhaps this hunk, I can't remember what that did, but it seems potentially dodgy:

@@ -970,7 +971,10 @@ st_GetTexImage(struct gl_context * ctx,
     * - Luminance alpha must be returned as (L,0,0,A).
     * - Intensity must be returned as (I,0,0,1)
     */
-   src_format = util_format_linear(src->format);
+   if (stObj->surface_based)
+      src_format = util_format_linear(stObj->surface_format);
+   else
+      src_format = util_format_linear(src->format);
    src_format = util_format_luminance_to_red(src_format);
    src_format = util_format_intensity_to_red(src_format);
Comment 11 Michel Dänzer 2014-09-24 02:36:44 UTC
(In reply to comment #10)
> Oh hrm. Perhaps this hunk, I can't remember what that did, but it seems
> potentially dodgy:

Reverting that doesn't fix it for me.
Comment 12 Ilia Mirkin 2014-09-24 02:37:54 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > Oh hrm. Perhaps this hunk, I can't remember what that did, but it seems
> > potentially dodgy:
> 
> Reverting that doesn't fix it for me.

With haagch's help on IRC, I think I worked it out -- 3d textures are messing things up, since they don't have layers. The st_cb_fbo.c hunk needs to take that into account, and perhaps some of the rest of the patch too.
Comment 13 Ilia Mirkin 2014-09-24 02:57:52 UTC
Untested, but I think this should help:

diff --git a/src/mesa/state_tracker/st_atom_texture.c b/src/mesa/state_tracker/st_atom_texture.c
index aa5be61..b48b739 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -223,7 +223,7 @@ static unsigned last_level(struct st_texture_object *stObj)
 
 static unsigned last_layer(struct st_texture_object *stObj)
 {
-   if (stObj->base.Immutable)
+   if (stObj->base.Immutable && stObj->pt->array_size > 1)
       return MIN2(stObj->base.MinLayer + stObj->base.NumLayers - 1,
                   stObj->pt->array_size - 1);
    return stObj->pt->array_size - 1;
diff --git a/src/mesa/state_tracker/st_cb_fbo.c b/src/mesa/state_tracker/st_cb_fbo.c
index 470ab27..c06f002 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -451,7 +451,7 @@ st_update_renderbuffer_surface(struct st_context *st,
    }
 
    /* Adjust for texture views */
-   if (strb->is_rtt) {
+   if (strb->is_rtt && resource->array_size > 1) {
       struct gl_texture_object *tex = strb->Base.TexImage->TexObject;
       first_layer += tex->MinLayer;
       if (!strb->rtt_layered)
diff --git a/src/mesa/state_tracker/st_texture.c b/src/mesa/state_tracker/st_texture.c
index c84aa45..2cd95ec 100644
--- a/src/mesa/state_tracker/st_texture.c
+++ b/src/mesa/state_tracker/st_texture.c
@@ -263,7 +263,8 @@ st_texture_image_map(struct st_context *st, struct st_texture_image *stImage,
    if (stObj->base.Immutable) {
       level += stObj->base.MinLevel;
       z += stObj->base.MinLayer;
-      d = MIN2(d, stObj->base.NumLayers);
+      if (stObj->pt->array_size > 1)
+         d = MIN2(d, stObj->base.NumLayers);
    }
 
    z += stImage->base.Face;
Comment 14 smoki 2014-09-24 06:18:04 UTC
 Tried both patches, neither does not fix the bug.
Comment 15 Ilia Mirkin 2014-09-24 06:19:35 UTC
(In reply to comment #14)
>  Tried both patches, neither does not fix the bug.

Which patches are "both patches"? Can you confirm whether http://patchwork.freedesktop.org/patch/34010/ has any effect on your issue?
Comment 16 Benjamin Bellec 2014-09-24 06:20:28 UTC
How do you run these UE4 demo ?
Comment 17 smoki 2014-09-24 06:25:36 UTC
Created attachment 106762 [details]
borked.jpg

(In reply to comment #15)
> (In reply to comment #14)
> >  Tried both patches, neither does not fix the bug.
> 
> Which patches are "both patches"?

 Comment 10 and  Comment 13... separete of course. 
 
> Can you confirm whether
> http://patchwork.freedesktop.org/patch/34010/ has any effect on your issue?

 That one also does not work, only colors is different now - see attachment.
Comment 18 Christoph Haag 2014-09-24 14:20:25 UTC
Weird.

Mesa git master + *only* the last patch did fix it for me.
Comment 19 smoki 2014-09-24 15:07:44 UTC
(In reply to comment #18)
> Weird.
> 
> Mesa git master + *only* the last patch did fix it for me.

 Weird or not, doublechecked and it does not work for me :). Previosly patched with 45b104e0a228595142ed4bc62bbc8948100b9325 and now on top of 2f7714e0717250c6737accc6c8259c6d9107fd6e again picture stay like in Comment 17
Only llvm is few days old here, but it worked with it when i bisected this... who knows lets build llvm :)
Comment 20 smoki 2014-09-24 15:10:22 UTC
 Oh my it worked :), it is about s3tc i removed lib so picture is without s3tc :D https://bugs.freedesktop.org/attachment.cgi?id=106762 

 So yeah, it is fixed for me too.
Comment 21 Ilia Mirkin 2014-09-26 06:03:37 UTC
I've pushed this out. Thanks for bisecting and testing!

commit 9d2e298dd4159651323cac54dbc43527e7fd6d16
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Wed Sep 24 00:58:07 2014 -0400

    mesa/st: NumLayers is only valid for array textures


bug/show.html.tmpl processed on Jan 16, 2017 at 21:47:12.
(provided by the Example extension).