gouchi has quit [Remote host closed the connection]
linkmauve has joined #dri-devel
<tzimmermann>
sravn, hi. do you have more comments on v2 of the mgag200 patchset?
icecream95 has joined #dri-devel
saurabh_1 has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
jkrzyszt has joined #dri-devel
MajorBiscuit has joined #dri-devel
lynxeye has joined #dri-devel
apinheiro has joined #dri-devel
saurabh_1 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
pcercuei has joined #dri-devel
Haaninjo has joined #dri-devel
kts has joined #dri-devel
vliaskov has joined #dri-devel
fahien has joined #dri-devel
<sravn>
tzimmermann: I looked brifly at the updated path for inti of DAC values and thought "meeh", and did not add more thought to it. Jocelyn already reviewed so it is good to go in IMO
<tzimmermann>
lol
<sravn>
tzimmermann: When I have your attention... I am slowly starting to work on the DRM driver for the Atmel LCDC IP.
<tzimmermann>
can i help?
<sravn>
It has It has only native BGR565 support and I want to add conversion to XBGR8888. So I need somehow to have a framebuffer that usersapce can write to, and then another framebuffer that LCDC can read from
<sravn>
The LCDC reads for normal (system) memory, there is no dedicated VRAM.
<sravn>
Are there any drivers that does something similar I can look at?
macromorgan is now known as Guest5529
<sravn>
Also, I am not sure if I shall go for vram helpers and shadow planes or something else?
macromorgan has joined #dri-devel
<tzimmermann>
system memory isn't much different from vram here. you simply have to allocated it and point the controller to the right address
<tzimmermann>
for examples, we have virtio, which does something similar
<tzimmermann>
it takes gem buffers and renders them to system memory
<tzimmermann>
sorry, not virtio. it's vkms
<sravn>
Super, I will take a look at vkms and see if I can make sense out of it.
<tzimmermann>
but in terms of code, simpledrm might be closer to your needs
<sravn>
simpledrm added to the list of drivers to look at. Thanks!
<tzimmermann>
you wont need vram helpers (which should be deprecated anyway). you should definately use shadow-plane helpers
rkanwal has joined #dri-devel
<sravn>
By the way, I wanted so add support for coversion to XRGB8888, not XBGR8888.
<tzimmermann>
sravn, i guess your driver will blit the GEM buffer to the device's video buffer. the closest helper is drm_fb_blit_toio(). unfortunately, it only supports iomem as output
<tzimmermann>
that might become a problem. as a quick solution, you could add a new function drm_fb_blit() that does take care of the conversion to system memory
Guest5529 has quit [Ping timeout: 480 seconds]
<tzimmermann>
it will all be unified somewhen
<javierm>
sravn: drivers/gpu/drm/solomon/ssd130x.c also exposes a XRGB8888 but natively reads a monochrome buffer converted with drm_fb_xrgb8888_to_mono()
<javierm>
and uses DRM_GEM_SHMEM_DRIVER_OPS
<tzimmermann>
javierm, ah, i see
<javierm>
sravn: so maybe some bits from that driver may also be useful to you
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
<tzimmermann>
javierm, geert has recently added fbdev support for <8-bit color modes. have you tried them with your driver?
<javierm>
tzimmermann: yes I know, reviewed some of the patches. I've it in my TODO list but didn't play with that yet
<javierm>
would be nice as perf improvement for fbcon but probably not much for user-space since quite likely XRGB8888 will still be needed in most cases
saurabhg has joined #dri-devel
<javierm>
tzimmermann: I also have in my TODO to convert to look at converting the driver to use the atomic helpers as you suggested
adarshgm has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
rkanwal has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, converting drivers to atomic helpers?
<tzimmermann>
oh, got it
<tzimmermann>
the regular ones
<javierm>
tzimmermann: yup
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
heat has joined #dri-devel
kts has joined #dri-devel
sagar_ has quit [Remote host closed the connection]
toolchains has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
fahien1 has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
fahien1 is now known as fahien
JohnnyonF has quit [Ping timeout: 480 seconds]
itoral has quit []
tobe has joined #dri-devel
imre has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
adarshgm has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
nchery has quit [Read error: Connection reset by peer]
sdutt has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
camus has quit []
CME_ has quit [Ping timeout: 480 seconds]
devilhorns has joined #dri-devel
rkanwal has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<jekstrand>
zmike: How do I make lavapipe dump the NIR and LLVM?
<zmike>
GALLIVM_DEBUG=ir ?
<jekstrand>
LP_DEBUG=fs seems to maybe work?
<zmike>
yea that'll dump it as it gets to llvmpipe
<graphitemaster>
I'd love to see a GL backend for DRI lol.
<jekstrand>
And... it's very different. :-/
<jekstrand>
zmike: How do I make it dump the NIR inside llvmpipe?
<zmike>
add printfs around the bottom of lp_bld_nir.c
<jekstrand>
got it
probablymoony has joined #dri-devel
moony has quit [Read error: Connection reset by peer]
<jekstrand>
Bah! The NIR is identical
<zmike>
the presence of variables and other things can affect gallivm behavior even if the output of the nir is the same
<jekstrand>
Yeah, but in lp_build_nir_llvm, it's identical, including which variables are declared
<jekstrand>
Unless a variable decoration is different that we're not printing
<jekstrand>
Shader info is the same, too
<jekstrand>
except for subgroup_size but that's fine, lavapipe ignores that
devilhorns has quit [Remote host closed the connection]
<jenatali>
jekstrand: What's the problem / difference you're seeing?
<jekstrand>
Multiview breaks
anujp has quit [Ping timeout: 480 seconds]
<jekstrand>
Specifically, it's only rendering to the first view
<jenatali>
Ah fun
<jenatali>
That's a feature I probably get to implement pretty soon for GL and Dozen
<hikiko>
hello, I am trying to build 32-bit mesa and I've created a cross file according to the documentation but when I run meson setup I realize I am missing some i386 libraries and I need to install them. Current error is "meson.build:1337:4: ERROR: C shared or static library 'atomic' not found" but I've installed libatomic1 and libatomic1:i386 any idea which library/package this could be?
rasterman has joined #dri-devel
devilhorns has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
alyssa has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
<jekstrand>
Seems to be a difference in clip planes, maybe?
tzimmermann has quit [Quit: Leaving]
sdutt has quit []
sdutt has joined #dri-devel
Duke`` has joined #dri-devel
tlwoerner_ has quit []
tlwoerner has joined #dri-devel
CME has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
devilhorns has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost_ has quit []
nchery has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
rkanwal has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<jekstrand>
Yup, it thinks it writes clip/cull
<jekstrand>
Found it. Was lowering clip/cull before dead_variables
<jekstrand>
And GLSLang likes to insert unused clip/cull vars. Woo!
heat has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
jewins has joined #dri-devel
kts has joined #dri-devel
jkrzyszt has joined #dri-devel
<dcbaker>
hikiko: is there a libatomic1-dev:i386 package? usually that means you're missing `libatomic.so` and only have the `libatomic.so.X.Y.Z`
gouchi has joined #dri-devel
iive has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
<hikiko>
dcbaker, there wasn't, the libatomic.so was in another package: lib32gcc-*-dev (where * the version number) I finally managed to find it and fix it, and now the only error I can't understand is: meson.build:1668:4: ERROR: "Pkg-config binary for machine 1 not found. Giving up." because pkg-config is installed and I think that I shouldn't need a 32bit version isn't it?
<dcbaker>
You need a pkg-config that searches the lib32 prefixes
<dcbaker>
debian provides one I think, or you can wrap the main pkg-config with a shell script that sets PKG_CONFIG_LIBDIR to the 32 bit paths
idr has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
abws has joined #dri-devel
toolchains has joined #dri-devel
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
srslypascal has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
ngcortes has joined #dri-devel
rkanwal has joined #dri-devel
srslypascal has joined #dri-devel
abws has quit [Quit: abws]
fahien has quit [Quit: fahien]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
<jekstrand>
Can clip/cull distance be XFB outputs?
<jekstrand>
airlied: Maybe. Still seems like a shader key thing to me.
<jekstrand>
Typically, shader_info is for things that come in through the compile path.
<jekstrand>
Like from GLSL or SPIR-V
<airlied>
yeah didn't fit there either, so maybe rasterizer makes more sense
toolchains has joined #dri-devel
* airlied
will leave it in rast state then I think
<jekstrand>
It's not like llvmpipe doesn't already have the world's largest shader key. ¯\_(ツ)_/¯
<airlied>
it's also a static value per API usually
<airlied>
so won't actually end up changing enough to create variants
<jekstrand>
Yup
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
<Kayden>
Yeah...that seems reasonable
toolchains has quit [Ping timeout: 480 seconds]
<Kayden>
Is it -actually- static based on the API? if so, you could probably just set it in the variant key directly, and not bother sticking it in rasterizer state
heat has quit [Remote host closed the connection]
<jekstrand>
Or that
<airlied>
won't that only work if we lowered it in the state tracker?
<airlied>
so in theory the bit has to be combined with the depth buffer format
<airlied>
since you have to implicitly clamp for UNORM formats
<airlied>
its just d32 formats that need the api flag
<Kayden>
ah
tobe has quit [Remote host closed the connection]
* airlied
assumes some hw just does it implicitly so doing it in the shader would be pointless
<Kayden>
how is this different than not setting depth_clamp and depth_clip_near and depth_clip_far in rasterizer state?
<airlied>
you can still set depth clamps outside the 0..1 range
<airlied>
just not with GL
<Kayden>
ah
<Kayden>
so I guess you need to replace clip_halfz with something fancier, yeah
<jekstrand>
If it has to be combined with the output format, that seems even more like a key thing.
pcercuei has quit [Quit: dodo]
<airlied>
it's also annoying around clear colors etc
<jekstrand>
Yeah
<airlied>
since you have z24unorm, but get a clear color outside that range with the extensions, and still have to clamp it at some point
<jekstrand>
yeah
sdutt has quit [Remote host closed the connection]
ybogdano has quit [Remote host closed the connection]
sdutt has joined #dri-devel
ybogdano has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
lstrano has quit [Remote host closed the connection]