ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
ids1024[m] has quit [Server closed connection]
ids1024[m] has joined #dri-devel
kunal_10185[m] has quit [Server closed connection]
kunal_10185[m] has joined #dri-devel
<jessica_24>
emersion: not exactly, but (correct me if i'm wrong) iirc generally to blend layers we'd have to convert all layers to the same color space
<jessica_24>
that being said, I think a more important question would be wouldn't we be losing data if we have to truncate the RGB323232 value?
<jessica_24>
for example, if the user passes in a nonstandard color value (ex. color_fill_value { .r=0xff, .g = 0xf1, .b=0x12}), but the hw only supports rgb444, wouldn't that cause unexpected output due to truncation?
warpme____ has quit []
apinheiro has quit [Quit: Leaving]
jkrzyszt has quit [Remote host closed the connection]
<DemiMarie>
Does anyone know anything about the PAT hacks used in i915? i915 is known to misbehave on some platforms if the PAT is not the default, such as under Xen PV. I filed https://gitlab.freedesktop.org/drm/intel/-/issues/7648 for that.
pcercuei has quit [Quit: dodo]
Company has quit [Quit: Leaving]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
reductum has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
yuq825 has quit [Ping timeout: 480 seconds]
reductum is now known as the_sea_peoples
the_sea_peoples is now known as reductum
reductum has left #dri-devel [#dri-devel]
dliviu has quit [Read error: No route to host]
dliviu has joined #dri-devel
yuq825 has joined #dri-devel
camus has joined #dri-devel
slattann has joined #dri-devel
fxkamd has quit []
lina has joined #dri-devel
the_sea_peoples has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
the_sea_peoples has quit [Quit: WeeChat 2.8]
aravind has joined #dri-devel
the_sea_peoples has joined #dri-devel
kts has joined #dri-devel
agd5f has joined #dri-devel
<agd5f>
anyone know why I would get a connection refused from OFTC from my new ISP? Do they block certain hosts or something? My new ISP does not appear to be blocking the ports.
<Nyaa>
No idea, I had to use tor because I was getting connection timed out trying to connect directly
<Nyaa>
tor address is oftcnet6xg6roj6d7id4y4cu6dchysacqj2ldgea73qzdagufflqxrid.onion if you need it
<airlied>
agd5f: using ssl?
<agd5f>
airlied, yeah. non-SSL doesn't work either
<Nyaa>
yeah i tried both 6697 and 9999 myself for TLS and it just wouldn't connect
<Nyaa>
probably poorly configured antispam, especially given an increasing number of ISPs have been moving towards using CGNAT on their ipv4 networks
<airlied>
agd5f: ipv6?
<Nyaa>
ISP shares one IP across 10000 people and one of them spams a network, there goes your IRC
<airlied>
Lynne: were you looking at h265 btw?
<airlied>
Lynne: btw newer amd gpus can support separate dpb, I've just added support for that and it seems to work
<agd5f>
airlied, not sure
<Nyaa>
oh speaking of decoders, anyone know how difficult hybrid vp8 decoding is to implement for stuff like polaris
<Nyaa>
under windows, vp8 decoding is hardware accelerated, or at least used to be, haven't used windows in years lol
<airlied>
Nyaa: no idea, not sure what pieces of the hw it can use
<Nyaa>
it does something with shaders/3d hardware
<Nyaa>
but that's about all i know
<agd5f>
Nyaa, it's probably not something worth doing. too much CPU/GPU ping ponging
<Nyaa>
it uses significantly less resources than cpu vp8 decoding
<Nyaa>
at least CPU resources lol
<Nyaa>
oh it's vp8 and vp9 not just vp8, but looks like AMD dropped it in newer versions of the windows drivers
<Nyaa>
ahh, they only implemented support for VP9 profile 0 apparently and adding profile 2 [which pretty much everything nowadays uses] was effort so they dropped support entirely instead
<Nyaa>
i do wonder how they did it though, maybe similar techniques could be used to (partially) accelerate av1 on older hardware too
<agd5f>
Nyaa, same way we did it for MPEG1/2 support in mesa I think.
JohnnyonFlame has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
<Nyaa>
hmmm, I'm trying to build mesa 18.0.0 and getting ERROR: compiler.links got unknown keyword arguments "extra_args"
<Nyaa>
anyone have any idea why it would be doing that?
<Nyaa>
[I'm trying to track down when an issue started happening, 23.0.0-git, 22.0.0, 21.0.0, 20.0.0, and 19.0.0 are all broken]
<Nyaa>
ah, my meson version is too new
luben has joined #dri-devel
bgs has joined #dri-devel
fab has joined #dri-devel
Daanct12 has joined #dri-devel
Daanct12 has quit []
Guest630 has quit [Remote host closed the connection]
luben has quit [Read error: Connection reset by peer]
dreda has joined #dri-devel
dreda is now known as Guest1098
<Nyaa>
alright after editing some meson.build files I have 18.0.0 building
<Nyaa>
hopefully 18 works because i have a feeling 17 will be even more annoying to build 😅
srslypascal has quit [Quit: Leaving]
rmckeever has quit [Quit: Leaving]
srslypascal has joined #dri-devel
srslypascal is now known as Guest1099
srslypascal has joined #dri-devel
srslypascal is now known as Guest1100
srslypascal has joined #dri-devel
<DemiMarie>
<Nyaa> "ahh, they only implemented..." <- Maybe the hardware did not support it?
<airlied>
bugs from community members as opposed to customers
<DemiMarie>
Customers of who?
<Nyaa>
DemiMarie, also i suspect it's much more likely that they just did not want to spend the money having their dev team make other vp9 modes work
<DemiMarie>
Nyaa: do they support it in newer hardware?
<Nyaa>
ye in the separate hardware decoder, but that is different from hybrid decoding, which uses gpu hardware to offload parts of video decoding
Guest1101 has quit [Ping timeout: 480 seconds]
<Nyaa>
[also, since they have dedicated hardware in newer cards, it would make even more sense from a business standpoint for them to not bother with older cards so that people are more likely to buy newer ones]
<DemiMarie>
I see
<DemiMarie>
airlied: Who would be paying customers in this context?
<Nyaa>
noooo, 18.0.0 didn't work either
<Nyaa>
looks like 17.0.0 does not use meson, does anyone know where the documentation on building pre-meson versions of mesa are?
<Nyaa>
oh it's in the repository itself
<Nyaa>
oh it just uses autoconf lol
dcz_ has joined #dri-devel
mvlad has joined #dri-devel
fab has quit [Quit: fab]
V has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
luben has joined #dri-devel
heat has joined #dri-devel
bgs has quit [Remote host closed the connection]
aravind has quit [Read error: Connection reset by peer]
aravind has joined #dri-devel
V has joined #dri-devel
sgruszka has joined #dri-devel
danvet has joined #dri-devel
fab has joined #dri-devel
frieder has joined #dri-devel
rasterman has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
tursulin has joined #dri-devel
frieder has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
V has quit [Ping timeout: 480 seconds]
V has joined #dri-devel
lynxeye has joined #dri-devel
rgallaispou has joined #dri-devel
swalker_ has joined #dri-devel
warpme____ has joined #dri-devel
swalker_ is now known as Guest1109
swalker__ has joined #dri-devel
V has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
Guest1109 has quit [Ping timeout: 480 seconds]
V has joined #dri-devel
V has quit [Ping timeout: 480 seconds]
slattann has quit [Ping timeout: 480 seconds]
<Nyaa>
RV380 should report 512 instructions, not 64, shouldn't it?
<Nyaa>
shader instruction limit
Daanct12 has joined #dri-devel
fab_ has joined #dri-devel
fab has quit [Read error: No route to host]
fab_ is now known as Guest1113
jkrzyszt has quit [Remote host closed the connection]
<Nyaa>
I suspect that's an oversight, early R300 cards only did 64 while later ones did 512
V has joined #dri-devel
MajorBiscuit has joined #dri-devel
maxzor has joined #dri-devel
devilhorns has joined #dri-devel
slattann has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
frieder has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
slattann has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
V has quit [Remote host closed the connection]
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
Guest1113 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
yuq825 has quit []
<Lynne>
airlied: nice, didn't know navi21 did that, the decoder performed similarly to older decoders
<Lynne>
yeah, I got distracted and did some polishing to the shared vulkan code
<Lynne>
I'll finish h265 tonight
Daanct12 has quit [Remote host closed the connection]
luben has quit [Remote host closed the connection]
fab has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
fab has joined #dri-devel
yuq825 has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
fab has quit [Quit: fab]
devilhorns has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
gawin has joined #dri-devel
<gawin>
@Nyaa from where you got 512? I know there where small changes from Khan (agp) to rv370/rv380(pcie), but iirc it was mostly about HyperZ
<Nyaa>
gawin, I found places saying that Shader Model 2.0b were supported by RV380, but looking further there's a lot of conflicting info
<Nyaa>
2.0b requires supporting at least 512 instructions
devilhorns has joined #dri-devel
<Nyaa>
anyway you popped in before i posted my question on gitlab so i'll copy and paste it here lol
<Nyaa>
> Looking closer, I am finding mixed info about RV380's limitations, would it be possible to just test the card itself to find out its actual capabilities? Would not be the first time I've seen a manufacturer's own publications be incorrect.
<Nyaa>
gawin, IIRC, they source info from the [windows] drivers themselves, and that particular chip emulates vertex shaders in software, so it could be likely those drivers fake the available count such that software checking will still use vertex shaders
<Nyaa>
that 2 could be the number of cores on said system's CPU, given it would have likely been paired with an Athlon 64-FX
kts has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
<DavidHeidelberg[m]>
r300 generation has amazing abilities fake it's abilities on CPU :D
<Nyaa>
or possibly, it was autofilled from more generic info about RS480
* DavidHeidelberg[m]
crying in rs690
<Nyaa>
I think it would probably be best just testing my RV380 itself to see its capabilities, I just do not know how to do that
<Nyaa>
it'll either work with more than 64 instructions or it won't, then there will not be any question if it supports over 64 or not
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<gawin>
iirc it's "max_alu_insts", but to say if it's working correctly you would need to test with CTS (loop unrolling)
<Nyaa>
alright, oh and could the broken 3d be outside of mesa? I tested down to 11.0.0 and it was still broken, 10.0.0 requires libxml2-python2 and i've been having trouble getting that to compile
<gawin>
there's a chance it was always broken, but at one point apps started using this functionality. with nv30 bugs started appearing when kde moved from 4 to 5
<gawin>
with kernel I'm not able to help (haven't touched yet)
JohnnyonFlame has joined #dri-devel
<Nyaa>
I have not done kernel stuff in a few years so that would suck if it was there
<Nyaa>
i wonder if it might work under ppc instead of ppc64
<MrCooper>
Nyaa: the screenshots look unlikely for it to be outside of Mesa; but I was already struggling against that kind of issue on a PowerBook some two decades ago, so not surprising if it broke a long time ago
<Nyaa>
I remember it working around 2009ish though
<Nyaa>
ok i got libxml2 working, 10.0.0 build going now
yuq825 has left #dri-devel [#dri-devel]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
fxkamd has joined #dri-devel
Guest1135 has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
fab has quit [Read error: Connection reset by peer]
Nyaaori has joined #dri-devel
Nyaa has quit [Remote host closed the connection]
Nyaaori has quit []
Nyaa has joined #dri-devel
<ajax>
huh. when did the intel ddx turn off merge requests?
<agd5f>
gawin, Nyaa none of of the pre-r6xx integrated GPUs had vertex shaders
Haaninjo has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
flto has quit [Remote host closed the connection]
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
flto has joined #dri-devel
gawin has joined #dri-devel
Guest1135 has quit []
<pendingchaos>
am I correct in thinking that NIR's b2i(true)/b2f(true) evaluate to UINT32_MAX with 32-bit booleans?
aravind has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
off^ has quit [Ping timeout: 480 seconds]
<pendingchaos>
nvm, I misread NIR's constant folding
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
MajorBiscuit has quit [Ping timeout: 480 seconds]
maxzor has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
devilhorns has quit []
off^ has joined #dri-devel
djbw has joined #dri-devel
Duke`` has joined #dri-devel
Duke`` has quit []
Duke`` has joined #dri-devel
fxkamd has quit []
ybogdano has joined #dri-devel
pixelcluster_ has quit []
pixelcluster has joined #dri-devel
<tomeu>
karolherbst: what do you think of lowering num_workgroups in rusticl in the same way you did for work_dim?
<karolherbst>
tomeu: send patches. I doubt any driver is doing that in hardware, do they?
<tomeu>
don't know of any!
<karolherbst>
If all driver lower it, I can always enable it in rusticl
<tomeu>
well, I checked freedreno, and they don't lower to load_uniform, but do what ends up being basically the same
<karolherbst>
thought hat's the local one
<tomeu>
oh, I will also need that one :)
<karolherbst>
yeah.. wrote that for v3d
<tomeu>
so basically, if no HW implement it in silicon/fw, it is considered fine to lower it in rusticl as it won't be slower?
kts_ has joined #dri-devel
srslypascal is now known as Guest1146
srslypascal has joined #dri-devel
airlied has quit [Ping timeout: 480 seconds]
<karolherbst>
yes
kts_ has quit []
<karolherbst>
the local size is something _some_ hardware does have though
<karolherbst>
but yeah.. generally I'm fine with lowering in rusticl, because it's really not that much work as you see :D
<karolherbst>
I just kind of prefer of also adding the check if it's actually used by the kernel and I think I've done that for work_dim
<tomeu>
yeah, from what I have seen, doing this in drivers is quite more code
<tomeu>
yep
<tomeu>
now I just need to learn rust :p
airlied has joined #dri-devel
airlied_ has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
<Lynne>
airlied: yup, seems to work, however are you sure there isn't meant to be a special case if the client decides to use layered refs anyway?
Guest1146 has quit [Ping timeout: 480 seconds]
<Lynne>
it still works if I force layered refs
Nyaa has quit [Remote host closed the connection]
Nyaa has joined #dri-devel
kts has joined #dri-devel
swalker__ has quit [Remote host closed the connection]
fab has joined #dri-devel
frieder has quit [Remote host closed the connection]
tursulin has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
<jekstrand>
tomeu, karolherbst: I don't know of any driver that does in hardware, either. Intel doesn't and neither does NVIDIA.
<jekstrand>
tomeu, karolherbst: The primary reason not to do that lowering in st/mesa for GL is because of indirect dispatch where we need to get the workgroup size from the indirect buffer somehow. On Intel, we bind it as a UBO. In NVK, we're writing it directly into the push constant area (NVIDIA constant buffers are weird).
tzimmermann has quit [Quit: Leaving]
gouchi has joined #dri-devel
<karolherbst>
ahh yeah.. makes sense
<jekstrand>
But CL doesn't have any indirect dispatch stuff so no need.
<DavidHeidelberg[m]>
Shouldn't be zink-freedreno-a630-traces rather named zink-turnip-a630-traces ?
<DavidHeidelberg[m]>
the underlying layer is vulkan -> turnip
<jekstrand>
probably
<jekstrand>
That would be less confusing, IMO
<DavidHeidelberg[m]>
I'm stresstesting it now, but I'll sent MR later.
<DavidHeidelberg[m]>
anholt: I see you used -tu for turnip, do you think I should follow that for rename or rather change it too to turnip? (imho if it's because of short field for job name, I'll try to send some patch to gitlab)
<anholt_>
DavidHeidelberg[m]: :shrug: don't care. turnip is src/freedreno/vulkan, the CI files are deqp-freedreno-*, freedreno is the overall name of the project.
luc4 has joined #dri-devel
maxzor has joined #dri-devel
<DavidHeidelberg[m]>
If you don't care, I would vote for turnip, to differentiate gl and vk
<DavidHeidelberg[m]>
if robclark agrees ofc :)
<anholt_>
actually, -1 for the rename, because when you look at the job name it helps lead you to traces-freedreno.yml
<DavidHeidelberg[m]>
btw. I think I have split debug info now, but my favorite crashing trace on zink+turnip doesn't want to crash
<anholt_>
which would be why I named it that way
<DavidHeidelberg[m]>
oh, ok. Make sense
* robclark
shouldn't be allowed to name things :-P
<DavidHeidelberg[m]>
:D
<anholt_>
how big would the test drivers be if we did -g1 and dropped the stripping, I wonder.
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
dviola has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
junaid has joined #dri-devel
<airlied>
Lynne: yeah layers should work fine if the image views are correct
gpiccoli has quit [Quit: Bears...Beets...Battlestar Galactica]
gpiccoli has joined #dri-devel
luc4 has joined #dri-devel
V has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
digetx has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
junaid_ has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
<DavidHeidelberg[m]>
anholt_: what I have to look into now is that with `-g3` and `-gsplit-dwarf` I'm still getting 200M vs 40M libs
<DavidHeidelberg[m]>
anholt_: but imho -gsplit-dwarf should be solution to our all debugging issues (regarding to size, if it'll work correctly)
<anholt_>
well, since this was prompted by zink backtraces from apitrace, you're planning on pulling down the split debug in all the traces jobs?
<anholt_>
so, splitting just means that we're not pulling it down for non-traces
nchery has joined #dri-devel
<DavidHeidelberg[m]>
it would make sense distribute debug stuff aside for everything? (since we generate it at for example mesa-arm64; libs -> s3; debug just to artifacts)
mvlad has quit [Remote host closed the connection]
dcz_ has quit [Ping timeout: 480 seconds]
junaid__ has joined #dri-devel
<DavidHeidelberg[m]>
anholt_: I think we could live without other parts with debug info, since if we expect Mesa to fail, with Mesa debug symbols it could (?) be enough to see what's happening. I'm still waiting for reproducing the crash from apitrace, I'll be able to tell more after
junaid___ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
<anholt_>
without core files from CI (which we don't have), it's going to be hard to construct a setup where a dev can actually use the split debug info.
<DavidHeidelberg[m]>
anholt_: in my branch I added export of coredump into artifacts; but since then it didn't crashed :D
<DavidHeidelberg[m]>
if you targeting the last-stage jobs, --force-manual always worked for me
junaid__1 has joined #dri-devel
junaid__1 has quit [Remote host closed the connection]
<Lynne>
airlied: updated my repo again, quite a bit of refactoring
nchery has quit [Remote host closed the connection]
pcercuei has quit [Read error: No route to host]
nchery has joined #dri-devel
<Lynne>
hevc not quite there yet, still some TODOs and unknowns
<airlied>
Lynne: i think i frames might work in the driver
junaid___ has quit []
alyssa has joined #dri-devel
<alyssa>
Any convention when to use debug_printf vs mesa_logd?
junaid__ has quit [Ping timeout: 480 seconds]
junaid_ has quit [Ping timeout: 480 seconds]
junaid has quit [Ping timeout: 480 seconds]
<alyssa>
(A coworker has a WIP patch that fopen's and fprintf's info. He agreed that wasn't a good approach for upstream but when I looked for prior art upstream I found both debug_printf and mesa_logd in use.)
gouchi has quit [Remote host closed the connection]
<jessica_24>
hey robclark, I asked emersion earlier about this, but also wanted to know your thoughts on it too -- if the user always passes in an RGB323232 color_fill value for all formats, wouldn't we run into a data loss issue if we end up truncating that value to fit formats with smaller depth?
<Lynne>
airlied: segfault in radv_CmdDecodeVideoKHR
<robclark>
jessica_24: I think that is better than the inverse problem, isn't it? Ie. the hw has some fixed limit in the colors it could represent.. we don't want the uabi to constrain the hw (but the inverse problem is one we have to live with regardless)
<emersion>
jessica_24: that's the whole point of using 4*32
<emersion>
or 3*32
<emersion>
pick something large enough that covers all hw
<emersion>
a superset of all available formats
<airlied>
Lynne: ouch
rmckeever has joined #dri-devel
<alyssa>
i see your RGB323232
<alyssa>
and give you RGB332
<alyssa>
it's very efficient, yes.
nchery has quit [Ping timeout: 480 seconds]
gawin has quit [Quit: Konversation terminated!]
<jessica_24>
robclark, emersion: I understand that this is to cover all formats and prevent the uabi from constraining hw, but would we not be able to avoid data loss if user was able to tell driver a specific format (or at least a specific bpc) and pass in a color_fill value that fits said format/depth?
<emersion>
jessica_24: what is the use-case here?
<emersion>
do you have user-space that needs it?
<emersion>
pekka and I think that it's not useful
<Nyaa>
so like, i built mesa 10.0.0 and get an undefined symbol glGetString error, anyone know why?
nchery has joined #dri-devel
<jessica_24>
emersion: I'm referring to cases when user passes in a non-standard color that can be expressed in a higher depth, but not in a lower depth (something like 0xF1F2F3 in RGB888 which would be truncated into 0xFFF in RGB444). Would this not count as unexpected output since the resulting color would technically not be the same as the color user is
<jessica_24>
trying set?
<robclark>
it is the same color within the precision the hw supports, if rgb444 was what the hw supported
<robclark>
sounds like the question is should we expose the # of bits of precision hw supports for solid fill to userspace?
<robclark>
I'm not sure if there is a good reason but something like that could be added later if needed
<emersion>
jessica_24: blending is already subject to rounding etc
<emersion>
the IGT tests for blending have a tolerance
<alyssa>
graphics is imprecise
<alyssa>
our whole industry is about calculating wrong results quickly
<alyssa>
how many mesa drivers are known to be unsound by design?
<alyssa>
the answer may shock you
<jekstrand>
hey, now. :P
ishitatsuyuki has quit [Quit: No Ping reply in 180 seconds.]
ishitatsuyuki has joined #dri-devel
fab has quit [Quit: fab]
Duke`` has quit [Ping timeout: 480 seconds]
* Nyaa
is unsure how she'll continue testing older versions with things not running at all
glennk has quit [Read error: Connection reset by peer]
glennk has joined #dri-devel
<abhinav__>
robclark emersion sorry catching up a bit late on the discussion on solid fill, so the plan is that the driver will check what's the post-blend format and convert the solid fill color passed down from usermode accordingly? So lets say
<abhinav__>
the hw blends in ABGR8888 Vs the user-mode will always pass the solid fill color in ARGB32323232 format, the driver will truncate the channels to 8 bit and also change the packing order to match the hw blend space right?
<emersion>
yea
<abhinav__>
emersion sg, understood
<glennk>
robclark, tricky scenario: solid fill color and an opaque plane filled with the same color placed side by side - will there be a visible seam? will one side be dithered and the other not?
luc4 has quit []
<robclark>
I don't _think_ we have a scenario where the hw supports solid fill with less precision than scanout plane
<emersion>
that's an interesting point
<emersion>
the precision of the scanout engine and blending space would be good to know for color mgmt, i think
<emersion>
(maybe pekka mentioned this already)
Company has quit [Quit: Leaving]
Cyrinux has quit []
<robclark>
I guess abhinav__ or jessica_24 could confirm, but I think this is input pre-blending (ie. taking the place of scanout input) so blending would work normally. If for some reason the hw had lower precision for solid fill than scanout (which I assume is unlikely) then maybe we'd want to expose that limitation to userspace
<glennk>
say the opaque plane is rgb565 and background fill is rgba8888, ideally user space would want to specify a truncated color value to avoid a seam
Cyrinux has joined #dri-devel
genpaku has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
genpaku has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
<abhinav__>
glennk this is input pre-blending , so the plane itself works in a solid fill color mode
<abhinav__>
so it would be seamless
<abhinav__>
and will be just like blending two layers
<abhinav__>
so this isnt background fill but plane's solid fill color
<glennk>
abhinav__, its the same issue as placing two layers with different color precision side by side