On Sat, Feb 16, 2019 at 2:27 AM Yang Tsao <yang@xxxxxxxxx> wrote:
>
> Thx for your reply.
> Chromium OS is running based DRM driver. There is no X server frame work. I modified nv50/nv50_formats.c.
>
> And there also a few code related the display format:
> nv50_surface.c
> Function nv50_2d_format:
> I add:
>
> ———————————
> switch (format) {
> case PIPE_FORMAT_R8G8B8X8_UNORM:
> return G80_SURFACE_FORMAT_RGBX8_UNORM;
> break;
> case PIPE_FORMAT_R8G8B8A8_UNORM:
> return G80_SURFACE_FORMAT_RGBA8_UNORM;
> break;
> default:
> break;
> }
I don't understand why that was necessary. All 4 of RGBX8, RGBA8,
BGRX8, BGRA8 appear to be in NV50_ENG2D_SUPPORTED_FORMATS, so that
should fall under the
if ((id >= 0xc0) && (NV50_ENG2D_SUPPORTED_FORMATS & (1ULL << (id - 0xc0))))
return id;
logic. And if they weren't, the 2d engine wouldn't be happy if you
handed it unknown formats.
> ———————————
> Nv50_blit.h
>
> ———————————
> Function nv50_2d_format_supported
>
> Function nv50_2d_src_format_faithful
>
> ———————————————
>
> My question is : why only support
> The format which id bigger than 0xc0 ?
>
> (id >= 0xc0) && (mask & (1ULL << (id - 0xc0)))
Well, the masks are just like that... we define, for nv50:
#define NV50_ENG2D_SUPPORTED_FORMATS 0xff0843e080608409ULL
#define NV50_ENG2D_NOCONVERT_FORMATS 0x0008402000000000ULL
#define NV50_ENG2D_LUMINANCE_FORMATS 0x0008402000000000ULL
#define NV50_ENG2D_INTENSITY_FORMATS 0x0000000000000000ULL
#define NV50_ENG2D_OPERATION_FORMATS 0x060001c000608000ULL
But the actual enum values are like
#define G80_SURFACE_FORMAT_RGBA32_FLOAT 0x000000c0
#define G80_SURFACE_FORMAT_RGBA32_SINT 0x000000c1
#define G80_SURFACE_FORMAT_RGBA32_UINT 0x000000c2
etc
So ... we just subtract 0xc0 to have the capability masks fit into
64-bit integers. IMO it's a bit of a premature optimization, but it's
way more like I'll screw something up when undoing it than just
leaving it alone. (Why did NVIDIA choose to start their hardware
format enums at 0xc0? No clue. But it's what the HW expects...)
Hope this helps,
-ilia
>
>
> > On 24 Nov 2018, at 12:20 PM, Ilia Mirkin <imirkin@xxxxxxxxxxxx> wrote:
> >
> > On Fri, Nov 23, 2018 at 11:00 PM Yang Tsao <yang@xxxxxxxxx> wrote:
> >>
> >> Hi, guys:
> >> I’m a developer of FydeOS. We porting ChromiumOS to amd64 and arm platforms. Now, I’m woking on porting android environment to Nvidia graphic cards. I have experience to port android to Vmware(SVGA).
> >> I found two display formats were not supported to display in nouveau driver: PIPE_FORMAT_R8G8B8A8_UNORM, PIPE_FORMAT_R8G8B8X8_UNORM. Which are defined at nv50/nv50_formats.c line: 130,131.
> >>
> >> C4(A, R8G8B8A8_UNORM, RGBA8_UNORM, R, G, B, A, UNORM, A8B8G8R8, IB),
> >> F3(A, R8G8B8X8_UNORM, RGBX8_UNORM, R, G, B, xx, UNORM, A8B8G8R8, TB),
> >>
> >> I want the last params to be “TD” or “ID” (support PIPE_BIND_DISPLAY_TARGET) , to support android. I modified these code, but got display issues and kernel issue:
> >
> > That's generally fine (IB -> ID, TB -> TD), but you might want to flip
> > the BGRA formats to not have the display bits. Some winsys's get upset
> > if you have both RGBA and BGRA ordering though. (The reason that we
> > prefer BGRA8 on X is largely legacy.)
> >
> >> [ 93.313995] nouveau 0000:01:00.0: gr: DATA_ERROR 0000009c [] ch 5 [007f6c6000 RenderThread[5395]] subc 0 class a097 mthd 15f0 data 002c0014
> >> [ 93.314082] nouveau 0000:01:00.0: gr: DATA_ERROR 0000009c [] ch 5 [007f6c6000 RenderThread[5395]] subc 0 class a097 mthd 15f0 data 002d0016
> >> [ 93.314112] nouveau 0000:01:00.0: gr: DATA_ERROR 0000009c [] ch 5 [007f6c6000 RenderThread[5395]] subc 0 class a097 mthd 15f0 data 002d0018
> >> [ 93.314215] nouveau 0000:01:00.0: gr: DATA_ERROR 0000009c [] ch 5 [007f6c6000 RenderThread[5395]] subc 0 class a097 mthd 15f0 data 002d001a
> >> [ 93.314244] nouveau 0000:01:00.0: gr: DATA_ERROR 0000009c [] ch 5 [007f6c6000 RenderThread[5395]] subc 0 class a097 mthd 15f0 data 002d001c
> >> [ 93.314272] nouveau 0000:01:00.0: gr: DATA_ERROR 0000009c [] ch 5 [007f6c6000 RenderThread[5395]] subc 0 class a097 mthd 15f0 data 002d001e
> >> [ 93.314301] nouveau 0000:01:00.0: gr: DATA_ERROR 0000009c [] ch 5 [007f6c6000 RenderThread[5395]] subc 0 class a097 mthd 15f0 data 002e0020
> >> [ 93.314325] nouveau 0000:01:00.0: gr: DATA_ERROR 0000009c [] ch 5 [007f6c6000 RenderThread[5395]] subc 0 class a097 mthd 15f0 data 002e0022
> >
> > I don't think this is related. Although I'm a bit puzzled as to what
> > this means. This is from index element submission (VB_ELEMENT_U16).
> > There's no real way to have a data error there... perhaps it think
> > it's out of bounds, or something else is not configured properly. This
> > could happen if there's multi-threaded rendering going on -- please
> > ensure that only a single thread ever calls into nouveau at any given
> > time in a process.
> >
> > Cheers,
> >
> > -ilia
>
_______________________________________________
Nouveau mailing list
Nouveau@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/nouveau
