<lygstate>
jekstrand: How about disable usage of __attribute__((__const__)) when clang compiler used unconditionally, or just disable it for util_cpu_detect only?
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
Vin[m] has joined #dri-devel
Duke`` has joined #dri-devel
jasuarez has joined #dri-devel
kts has joined #dri-devel
kts has quit []
YuGiOhJCJ has joined #dri-devel
bmodem has joined #dri-devel
bmodem has quit []
kts has joined #dri-devel
markus is now known as degasus
lemonzest has joined #dri-devel
danvet has joined #dri-devel
lygstate has quit [Remote host closed the connection]
macromorgan is now known as Guest7662
macromorgan has joined #dri-devel
minecrell has joined #dri-devel
MatrixTravelerbot[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Guest7662 has quit [Ping timeout: 480 seconds]
shoragan has joined #dri-devel
tleydxdy has joined #dri-devel
tzimmermann has joined #dri-devel
frieder has joined #dri-devel
thellstrom has joined #dri-devel
frieder has quit [Remote host closed the connection]
mlankhorst_ is now known as mlankhorst
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
frieder has joined #dri-devel
jkrzyszt has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
lygstate has joined #dri-devel
robertfoss[m] has joined #dri-devel
tursulin has joined #dri-devel
xantoz has quit [Read error: Connection reset by peer]
xantoz has joined #dri-devel
lygstate_ has joined #dri-devel
lygstate is now known as Guest7672
lygstate_ is now known as lygstate
Guest7672 has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
heftig has joined #dri-devel
MajorBiscuit has joined #dri-devel
MrCooper_ is now known as MrCooper
<MrCooper>
emersion pinchartl: FWIW, even with "real" FBs there's no 100% guarantee that the "real" commit will succeed after a test commit did, due to time of test vs time of use; so user-space always needs to be prepared to handle the "real" commit failing
<emersion>
hm, no?
<emersion>
at least it should never fail with a validation error
<MrCooper>
yes :)
<MrCooper>
it could fail e.g. with ENOMEM though
<MrCooper>
e.g. because the BOs couldn't be pinned
<emersion>
yeah, runtime errors are allowed, but validation errors are not
jfalempe has joined #dri-devel
<danvet>
MrCooper, at least for single FB use ENOMEM is imo also a driver bug of not filterting that out
<danvet>
i.e. if you allow fb bigger than half of vram (minus some fudge) it's kinda silly
<MrCooper>
how could it filter that out? It would require pinning already at test commit time (to avoid time of test vs time of use), which would bring obvious issues of its own
opotin has joined #dri-devel
Guest7614 is now known as jani
jani has quit []
jani has joined #dri-devel
jani is now known as Guest7675
Guest7675 has quit []
jani_ has joined #dri-devel
jani_ is now known as jani
jani has quit []
jani has joined #dri-devel
gnustomp[m] has joined #dri-devel
mauld_ has quit []
mvlad has joined #dri-devel
pixelcluster has joined #dri-devel
mauld has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
ralf1307[theythem][m] has joined #dri-devel
<danvet>
MrCooper, just reject it add addfb time when you try to create an fb for more than half of vram?
<danvet>
or vram minus whatever is pinned by the driver permanently
<MrCooper>
that's not the only reason ENOMEM can happen
<danvet>
oh sure, hence my limiter
<MrCooper>
anything can happen between the test and real commits
<danvet>
what I meant is that just because ENOMEM can happen doesn't mean you should punt all ENOMEM checking to commit time
<MrCooper>
or between creating the FB and the real commit, for that matter
<danvet>
imo if there's just no way an fb can be used reasonably then it should be rejected early
<MrCooper>
danvet: I agree that makes sense, but it still can't provide 100% guarantee
<danvet>
agreed
JohnnyonFlame has quit [Ping timeout: 480 seconds]
jekstrand[m] has joined #dri-devel
ramacassis[m] has joined #dri-devel
nchery has joined #dri-devel
unrelentingtech has joined #dri-devel
luc4 has joined #dri-devel
<tzimmermann>
MrCooper, danvet: in my experience, you can't have fbs larger than 1/3 of the vram size. even on single-plane hardware. that is because if you pin a small fb at the beginning of vram (e.g., fbdev) and a large one right next to it (e.g., 1st weston frame), the next large fb (e.g., 2nd weston frame) can still fail if the vram is small.
narmstrong__ has quit []
narmstrong has joined #dri-devel
<tzimmermann>
AFAICT on a 16 MiB vram, fbdev with 1024*768 and westong at fullhd (both with 32-bit color) should trigger this error
anholt__ has quit [Remote host closed the connection]
linkmauve has joined #dri-devel
eyearesee has joined #dri-devel
YaLTeR[m] has joined #dri-devel
halfline[m] has joined #dri-devel
masush5[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
hasebastian[m] has joined #dri-devel
rasterman has joined #dri-devel
LaughingMan[m] has joined #dri-devel
znullptr[m] has joined #dri-devel
Haaninjo has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
Dylanger has joined #dri-devel
FireBurn has quit [Read error: Connection reset by peer]
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
JohnnyonFlame has joined #dri-devel
fab has joined #dri-devel
fab has quit [Quit: fab]
gawin has joined #dri-devel
thellstrom has joined #dri-devel
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
cengiz_io has joined #dri-devel
Guest7579 has quit []
DragoonAethis has joined #dri-devel
camus has quit [Remote host closed the connection]
kts has quit [Remote host closed the connection]
camus has joined #dri-devel
gbelgurr has joined #dri-devel
<pinchartl>
MrCooper: that's fine, I'm not looking for a way to guarantee that 100% of the test commits will work properly when turned into real commits :-)
<pinchartl>
it would be great if that problem could be solved, sure, but I don't need it
<pinchartl>
what I however need is a way to test parameters related to plane composition
dv__ has quit []
<pinchartl>
andI don't think we should prevent making that possible because we can't solve all the other problems in the world :-)
dv_ has joined #dri-devel
<pinchartl>
danvet: ever thought about how we could support test commits with dummy BOs ?
<danvet>
addfb TEST_ONLY flag?
<pinchartl>
(or any other mechanism to allow testing everything not related to BOs without having to allocate real BOs first)
<danvet>
random idea invented out of thin air right now
<danvet>
and I'm still recovering from being out of service last week, so don't trust anything I say :-)
<pinchartl>
yeah I suppose that could work
kts has joined #dri-devel
<danvet>
I mean it's not perfect, if you have stuff like nv12 and one bo needs to be on one memory bank
<danvet>
and the other plane on the other
<danvet>
then that wont catch that
<pinchartl>
in the core I think it would be fine
<danvet>
but also afaik we never managed to set that up
<pinchartl>
we can drop some tests (mostly the BO != NULL tests) at commit check time when the FB is created with TEST_ONLY
<danvet>
pinchartl, I think the only challenge is making the right call for drm_fb->obj pointers
<danvet>
should those be NULL and we update helpers to be able to cope (per-driver opt-in required)
<pinchartl>
one challenge will be to ensure that drivers won't crash if they get a null BO when they expect a real one
<danvet>
or should it be a dummy object which just fails when we try to commit (before we go into driver code)
<danvet>
which could perhaps avoid the per-driver opt-in
<pinchartl>
dummy BOs may be better, with ops that fail instead of crashing
<danvet>
since then we'd only need to audit atomic_check code, and 90% of that really is generic helper stuff
<danvet>
yeah
<danvet>
we could do a dma-buf imported bo
<danvet>
which always fails in ->get_sg
<danvet>
and a special drm_gem_object_is_dummy() check in case we have drivers which would get confused by that in their atomic_check code
pcercuei has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
chema has joined #dri-devel
nchery has quit [Remote host closed the connection]
tonyk has joined #dri-devel
mripard has joined #dri-devel
kunal_10185[m] has joined #dri-devel
nchery has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
karolherbst_ is now known as karolherbst
pcercuei has joined #dri-devel
zamundaaa[m] has joined #dri-devel
colemickens has joined #dri-devel
zehortigoza has joined #dri-devel
mbrost has joined #dri-devel
sdutt has joined #dri-devel
hch12907 has joined #dri-devel
luc4 has quit [Ping timeout: 480 seconds]
mbrost has quit [Read error: Connection reset by peer]
Andy[m] has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
arisu has joined #dri-devel
<gawin>
do traces from traces-db require some preprocessing before use?
sysescool has quit [Remote host closed the connection]
Mis012[m] has joined #dri-devel
luc4 has joined #dri-devel
sysescool has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
caef^ has joined #dri-devel
ybogdano has joined #dri-devel
sdutt has quit []
rgallaispou has quit [Read error: Connection reset by peer]
frieder has quit [Remote host closed the connection]
<sysescool>
Hello, guys. I build and install mesa with llvmpipe, and the nvidia graphic card is disabled. I learn some command such `glxinfo -B`, `prime-select query`, `inxi -G`... and search lots of in google, but still don't know how to enable my nvidia graphic card. Will you help me? I will offer more logs and more results of command. Thank you so much.
<JoniSt>
sysescool: Which graphics card exactly?
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<sysescool>
NVIDIA GP106 [GeForce GTX 1060 3GB]
<JoniSt>
Hmm... What kernel driver is loaded for it?
caef^ has quit [Ping timeout: 480 seconds]
<JoniSt>
You'll need to load nouveau but I'm not sure if its Pascal support is particularly good yet
<sysescool>
I install nvidia-driver-510 in the APP(Software & Updates -> Additional Drivers)
Duke`` has quit [Ping timeout: 480 seconds]
<JoniSt>
Well yeah, there's your problem. You can't use Mesa with the proprietary kernel driver. You either have to use the entire proprietary driver stack (nvidia driver + nvidia userspace, no Mesa), or the entire open driver stack (nouveau+Mesa)
<JoniSt>
If you want features, use nvidia-driver-510, if you want openness, use Mesa
<JoniSt>
You can't have both
<JoniSt>
(Well okay, you can have both, but only with Intel and AMD)
thellstrom has quit [Quit: thellstrom]
<emersion>
*only with everybody except NVIDIA ;)
<JoniSt>
Yeah ;)
<sysescool>
So, I should choose "Using X.Org X server -- Nouveau display driver from xserver-xorg-video-nouveau(open source)". Right?
<pixelcluster>
huh, llvmpipe doesn't get along with proprietary nvidia installed at the same time?
<RSpliet>
llvmpipe == software rendering
<sysescool>
yes, llvmpipe == software rendering.
<JoniSt>
llvmpipe does but not the accelerated driver. And yeah, sysescool: You have to install that
<sysescool>
when I open some games, fps is very very low.
<sysescool>
Thank you a lot, JoniSt, Let me try and connect to you later.
<JoniSt>
Maybe soon(tm) we'll have good Mesa support with NV too, but only Turing and later, and it also depends on the exact size of the galaxybrain.jpg of the Mesa devs
<JoniSt>
No problem, and good luck! :)
sysescool has quit [Remote host closed the connection]
<JoniSt>
If that nvidia kernel driver source drop ever gets upstreamed, I vote for its module name being "envy", by the way
<zmike>
JoniSt: btw congrats your MR landed
<zmike>
thanks for tackling that
<JoniSt>
I saw it, thank you very much! :)
sysescool has joined #dri-devel
Duke`` has joined #dri-devel
<sysescool>
I come back
<sysescool>
good news: when I log in on my desktop, there is no rendering error. bad news: try some games, fps still very very low....
<sysescool>
After `inxi -G`, the result changed:
<JoniSt>
sysescool: As far as I know, there is no reclocking support for Pascal cards yet in nouveau. So the GPU is stuck at its lowest (idle/2D) clock speed.
<sysescool>
dmesg: snapd-desktop-i[2466]: segfault at 0 ip 00007f315520d364 sp 00007ffd567113e8 error 4 in libglib-2.0.so.0.6400.6[7f31551e3000+9a000]
cwfitzgerald[m] has joined #dri-devel
<sysescool>
is it related with this?
<JoniSt>
Oops, looks like snapd isn't happy. It's totally unrelated, though. Check if the word "nouveau" appears in your kernel log at all
<sysescool>
grep nouveau and nothing.
<JoniSt>
Okay, then check what files are in /etc/modprobe.d
<sysescool>
I find there is a file called "disable-nouveau.conf"
<sysescool>
lol
<JoniSt>
Oops! :P
<JoniSt>
Yeah, delete that, then rebuild your initramfs again, reboot.
<JoniSt>
Looks like the nvidia driver didn't clean up after itself when it got uninstalled.
<tleydxdy>
it's a blessing it didn't nuke the system already
<RSpliet>
FTR: there is a nouveau IRC channel called #nouveau on OFTC. Hate to be a grinch, but I suspect that that is the preferred place to chat about getting nouveau to work (#dri-devel is supposed to be dev discussion I believe)
<JoniSt>
Yeah, that's also true. But I guess it's solved by now :)
<sysescool>
Auh, I have to say, Sorry, before I install nvidia-driver I create this file as tutorial to disable nouveau....
<JoniSt>
Well, stuff like that happens :P
sysescool has quit [Remote host closed the connection]
<sysescool>
the fps in game still 20, before we install nouveau is about 10-15 QAQ
<JoniSt>
Like I said, nouveau lacks reclocking support. The GPU is stuck at its lowest (idle) speed. If you want performance, you will in fact have to use the nvidia driver and not Mesa, unfortunately. Though I think we have annoyed dri-devel enough now, if you need more help, we should go over to the nouveau channel
bmodem has joined #dri-devel
<sysescool>
no matter how, thank you a lot.
<JoniSt>
No problem. :)
tomba has joined #dri-devel
bmodem has quit []
gawin has quit [Remote host closed the connection]
zzoon2627thholiday[m] has joined #dri-devel
linearcannon has quit [Ping timeout: 480 seconds]
bwidawsk has joined #dri-devel
luc4 has quit [Ping timeout: 480 seconds]
cengiz_io_ has joined #dri-devel
DPA has joined #dri-devel
jewins has joined #dri-devel
cengiz_io has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<linkmauve>
alyssa: I’m looking forward to your conversion, I once attempted to rewrite GALLIUM_HUD to use Nir instead of TGSI, in order to train for Grover, but never achieved something useful. Your examples will probably help me finish that.
<alyssa>
linkmauve: :-)
<alyssa>
nice timing, you have a script or something? :p
tursulin has quit [Ping timeout: 480 seconds]
<jekstrand>
lygstate: Ugh... Yeah, I guess we need to disable it for at least a few LLVM versions.
<jekstrand>
robclark: Does freedreno do direct 64-bit pointer access for UBOs/SSBOs in the shader or does it go through descriptors?
<jekstrand>
I'm seeing lots of global_ir3 intrinsics so I assume you use a pointer-like thing
<alyssa>
jekstrand: Brave to assume a driver has just one strategy ;)
<jekstrand>
alyssa: I know better than to make that assumption. I worked for Intel.
<alyssa>
:-D
<alyssa>
anv is the king of "how many ways can we load memory?", right?
<lygstate>
jekstrand: I found it's not working up-to clang 14, clang11-clang14 are verified not working... some one said clang-trunk working, but I am not verified that, https://github.com/llvm/llvm-project/issues/56993
<jekstrand>
lygstate: Yeah, I saw your issue on github. That's nasty.
<jekstrand>
alyssa: Yeah... it really is.
<alyssa>
still need a strategy for asahi there...
<lygstate>
lygstate: So may I disable it for clang totally, after that issue fixes, I can add more exact guard for it
<linkmauve>
alyssa, just poezio’s /tell command. :)
<alyssa>
linkmauve: ah
<alyssa>
the hardware just gives us uniforms, commands to load uniforms from memory, and preamble shaders that can write uniforms
<alyssa>
mapping to API constructs is our problem :D
<lygstate>
jekstrand: I am talking to you, sorry
<robclark>
jekstrand: older generations implement UBOs as load_global.. newer things have descriptors
<jekstrand>
lygstate: Yeah, I think that's the best plan for now. Good work digging that up.
<jekstrand>
robclark: Ok, neat.
<jekstrand>
robclark: Is there anything that doesn't live in descriptor buffers besides render targets?
<robclark>
vbo, index buffers
<jekstrand>
robclark: Sure.
<robclark>
well all the things that aren't images/ubos/ssbos/textures
<jekstrand>
robclark: What HW does that start at? Everything being in buffers.
<robclark>
so it is only ubo's where there is generational difference
<robclark>
iirc we started using descriptors for that on a5xx.. I don't quite remember what a4xx supported offhand
<robclark>
a3xx was defn loader to `ldg`
<jekstrand>
robclark: That's good enough
* jekstrand
debates adding Vivante for completeness....
<alyssa>
Silly question -- how do I unnominate a patch from stable?
<alyssa>
Root caused #7025 to my mistakenly cc'ing a patch to stable that wasn't necessary and that actually hosed everything
<alyssa>
(The bug fixed there only became possible to hit due to an IR change that wasn't backported)
<alyssa>
I think just reverting it from 22.1.5 and wherever else it landed would fix things
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<linkmauve>
Hmm, Weston seems to leave planes’ COLOR_RANGE property to limited range, and while I don’t see anything obviously wrong wouldn’t it usually be better for most screens to set it to full range?
<linkmauve>
Also, since there is no automatic value like in connectors’ Broadcast RGB, are compositors expected to set both? If so to which value?
<linkmauve>
How can one discover which range is better for a given connector?
<linkmauve>
For instance on my laptop’s eDP screen full range definitely looks better, while on this random HDMI TV both look exactly the same.
gbelgurr has quit [Ping timeout: 480 seconds]
<emersion>
COLOR_RANGE is a plane prop
<emersion>
"Broadcast RGB" is a non-standard Intel connector prop
<emersion>
COLOR_RANGE only affects YUV FBs
<linkmauve>
Makes sense.
<linkmauve>
Thanks. :)
<emersion>
it would be nice to have a standard prop for "Broadcast RGB"
rasterman has quit [Quit: Gettin' stinky!]
<linkmauve>
It’s a bit sad how no convention has been adopted for properties, there are SCREAMING_SNAKE_CASE ones, Intel Extension ones, kebab-case, and space separated lowercase ones.
<emersion>
yeah, almost a meme at this point
<linkmauve>
Is there a property configuring whether to force 4:2:0 or 4:4:4 for a connector?
<emersion>
we try to convince designers for new props to find a new standard
<emersion>
and it works! we have vrr_capable now
<linkmauve>
xD
<emersion>
which came with VRR_ENABLED, of course
<linkmauve>
Wat.
* alyssa
is struggling to get the Mali proprietary drivers working on a test linux board
<alyssa>
this is surreal
<alyssa>
I understand why Panfrost has users now....
<emersion>
i don't think there's such a prop. maybe max bpc, but that wouldn't be a guarantee
<emersion>
it would be useful to have for color management purposes
<linkmauve>
It’s already set to its max, 12.
<linkmauve>
Oh interesting, my Kaby Lake only exposes HDR_OUTPUT_METADATA on the two DisplayPort connectors.
<linkmauve>
Not on HDMI.
<linkmauve>
(I have no physical DisplayPort port.)
<linkmauve>
(Although I do have two USB-C ports, this one can carry DisplayPort right?)
<alyssa>
No graphics drivers could possibly be this hard to get to render..... anything
<airlied>
alyssa: isn't that the business model?
<airlied>
charge for support :-), and everyone needs support
<alyssa>
airlied: good riddance
doras has joined #dri-devel
eukara has quit []
<jenatali>
There we go, Matrix finally reconnected
Ella[m] has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
bluepenquin has joined #dri-devel
bluepenquin is now known as Guest7735
nchery is now known as Guest7736
nchery has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
go4godvin has joined #dri-devel
go4godvin is now known as Guest7740
Guest7736 has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
mmind00 has quit [Remote host closed the connection]
mmind00 has joined #dri-devel
zf has quit [Read error: Connection reset by peer]
zf has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
mvlad has quit [Remote host closed the connection]
kallisti5[m] has joined #dri-devel
fab has joined #dri-devel
linearcannon has joined #dri-devel
<Frogging101>
How do I wait for a compute shader to finish after calling radv_unaligned_dispatch?
<pixelcluster>
just like any other dispatch
<Frogging101>
Which is how? :)
<pixelcluster>
do you want to wait on GPU (like VkMemoryBarrier) or on CPU?
alyssa has quit [Quit: leaving]
<Frogging101>
On the GPU, I think. Basically I need the CS to finish before the next commands I emit will run
<Frogging101>
CS = compute shader
<pixelcluster>
as far as I can tell from reading the source you'd be calling radv_barrier like you would call vkCmdPipelineBarrier2
cleverca22[m] has joined #dri-devel
<Frogging101>
alright I'll look at that. I saw that earlier but wasn't sure if it was what I wanted
<airlied>
Frogging101: are you using a dst as src in a new operation?
cengiz_io has joined #dri-devel
kusma has joined #dri-devel
cengiz_io_ has quit [Ping timeout: 480 seconds]
<Frogging101>
airlied: In the CopyImageToBuffer case I have to wait for the compute shader to finish writing to the buffer before I do the fixup copy. In the CopyBufferToImage case waiting is not required because the unaddressable image pixels won't be written to by the compute shader (but when writing to a buffer instead of an image, they will). That's what AMDVLK's comments say on the matter,